On Fri, 30 May 2008 23:28:38 +0200 Segher Boessenkool <[EMAIL PROTECTED]> 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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
