[PATCH v2] update crypto node definition and device tree instances

[Segher Boessenkool]

>>>> 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"
or "compatible", just in case a problem shows up with one of them.

>>>> 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!

> (that hit is correct, btw).

Okay, cool.

>> Going from SoC name -> SEC version is easy, but the other way around
>> not so.
>>
>> Anyway, minor stuff.
>
> sounds like you're pointing out a lack of "SEC versions guide"
> documentation of Freescale..

Yes, that would have helped.

>>> 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 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.


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.


Segher