Re: [PATCH 1/2] update crypto node definition and device tree instances

[Kim Phillips <kim.phillips@freescale.com>]

On Fri, 30 May 2008 23:28:38 +0200
Segher Boessenkool <segher@kernel.crashing.org> wrote:

> Nice cleanup!  Just one thing...
> 
> > +    - compatible : Should contain entries for all compatible SEC 
> > versions,
> > +      high to low, e.g., "fsl,sec2.1", "fsl,sec2.0"
> 
> *All* compatible versions?  That's not really correct -- for
> example that would include *future* versions!

ok, so 'backward compatible'..

> The first entry should describe the exact device version.  If
> there are more entries, they should be for device versions where
> the driver for that device version can be reasonably expected to
> do something useful with this newer device (reduced functionality,
> perhaps).  Listing *all* compatible devices is a) infeasible,
> b) not useful, and c) insane :-)
> 
> Say you have a 3.3 device, and all 3.x devices have the same
> programming interface; also, the 2.x interface works with reduced
> functionality, and 1.x isn't useful at all; in that case, you would
> list 3.3, 3.0, 2.0.  The driver that knows about 3.x would probe
> for 3.0, while an older driver would probe for 2.0.  The driver
> doesn't need to probe for 3.3, since devices implementing 3.3
> should show they are compatible with 3.0 (and the binding should
> say they should show this).
> 
All the driver has to do to turn on a particular feature is call
of_device_is_compatible with the version string of the h/w version that
introduces that feature.  In the above case, a driver wanting to use
e.g., hardware ICV checking, would have to check for 2.1 and 3.x instead
of just 2.1.

> Also, the binding should explicitly list all defined compatible
> entries (and what they mean), not just give a few examples.
> 
I'm not sure I understand; a lot of the differences between the SEC
versions are miniscule feature bits scattered across the programming
model.

Kim