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

[Kim Phillips]

On Sun, 29 Jun 2008 01:37:12 +0200
Segher Boessenkool <segher at kernel.crashing.org> wrote:

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