On Mon, 30 Jun 2008 23:19:05 +0200 Segher Boessenkool <[EMAIL PROTECTED]> wrote:
> >>>> Also, these made-up names make you do more work: you'll need to > >>> > >>> who said they were made up? > >> > >> I did. These names do not refer to some physical part you can buy. > > > > right, they refer to devices in multiple physical parts you can buy. > > Part-you-can-buy documentation clearly indicates the SEC version in > > that part, in the form "SEC X.Y", i.e, it's not something made up > > that's not already in freescale documentation. > > Yes. As a side note, since there are multiple devices that contain > e.g. a sec-1.0, it would be prudent to describe the exact incarnation > in the device tree, like "mpc8272-sec" or something, in either "model" but 'fsl,sec-X.Y' /does/ describe the exact incarnation, whereas 'fsl,mpc8349-sec' /does not/. "fsl,mpc8349-sec' might mean the SEC 2.1 or the SEC 2.4, it depends on the revision of the mpc8349. > or "compatible", just in case a problem shows up with one of them. I thought 'model' was superseded by 'compatible'; that's why it's taken out here, along with device_type. > >>>> write up a binding for them, explaining exactly what a 1.0 device > >>>> etc. is (or at least point to documentation for it). If you use > >>>> a name that refers to some device that people can easily google > >>>> for documentation, you can skip this (well, you might need to > >>>> write a binding anyway; but at least you won't have to explain > >>>> what the device _is_). > >>> > >>> documentation is available in the usual places, and it specifically > >>> points out which SEC version it references. > >> > >> I can't find a manual online for "freescale sec"; googling > >> for "freescale sec-1.0" finds a manual for the PowerQUICC I; > >> is that the right one? I don't know, so the binding needs > >> to explain it to me. > > > > the binding shouldn't be responsible for google's shortcomings > > The binding needs to describe what device it is for. I am a stupid > user, just like most users, so if the binding doesn't tell me I turn > to google. Don't blame them for not finding it; the binding should > have told me in the first place! Again, I don't see how google's results are pertinent in this discussion. The fact that Freescale doesn't publish a separate SEC manual is not what this patch is trying to address. btw, the title for the binding is: g) Freescale SOC SEC Security Engines Is that what you are looking for? If not, what precisely? a list of all the parts? There's an SEC in every mpc8[35]xxE! > >>> Plus, as I mentioned > >>> before, a lot of the differences between the SEC versions are > >>> miniscule > >>> feature bits scattered across the programming model. > >> > >> I don't see how this is relevant, sorry. > >> > > I'm under the impression that listing the differences (assuming they're > > easily obtainable) would lead to unnecessary b-w-of bloat. > > The binding at a minimum should describe how to identify each > unique version from the device tree, no matter how miniscule > those differences are. Just a specific "compatible" value will > do. I'm at a loss; isn't that what this patch does? > > I don't know what google does; I'd search freescale documentation > > directly. > > Or the binding could just bloody say what it is talking about in the > first place, heh. Again, I'm at a loss here. Can you give a specific example of what you're looking for here? > Anyway, how about we do something constructive? If you still want to > use "fsl,sec-N.M" names, that's fine with me. Each specific device > tree needs to still say which exact device it contains, so an entry > would look like e.g. > > compatible = "fsl,mpc8272-sec", "fsl,sec-3.0"; > > and the driver can just probe for "fsl,sec-3.0" if it doesn't need > to know about the exact version; but it _can_ use it if it _does_ > need to know. Currently the driver matches on "fsl,sec2.0", and if needs be, will call of_device_is_compatible with the version number that introduces the feature it wants to implement. Kim _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
