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

On Sun, 29 Jun 2008 01:37:12 +0200
Segher Boessenkool [off-list ref] wrote:

quoted

I'm really don't like "fsl,sec1.0" or any of the variants as a
compatible property either because it can easily be abused (it's not
anchored to a specific physical part so the meaning can shift over
time); but that is another argument and it is well documented in other
email threads  
(http://thread.gmane.org/gmane.linux.ports.ppc64.devel/38977/ 
focus=39147)

Also, these made-up names make you do more work: you'll need to

who said they were made up?

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.  Plus, as I mentioned
before, a lot of the differences between the SEC versions are miniscule
feature bits scattered across the programming model. 

Using actual model names also reduces the namespace pollution
(hopefully Freescale will not create some other MPC8272 device
ever, so "fsl,mpc8272-whatever" will never be a nice name to
use for any other device; OTOH, it's likely that Freescale will
create some other device called "SEC" (there are only so many
TLAs, after all), so "fsl,sec-n.m" isn't as future-proof.

I doubt that; the SEC has been around for about a decade now and that
hasn't happened.  The SEC is on par with the TSEC ethernet controller
as far as this goes.

Kim