quoted

quoted

quoted

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.

quoted

quoted

quoted

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.

quoted

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.

quoted

quoted

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