On 08/09/2011 08:17 PM, Scott Wood wrote: > On 08/09/2011 09:43 AM, Robin Holt wrote: >> In working with the socketcan developers, we have come to the conclusion >> the fsl-flexcan device tree bindings need to be cleaned up. >> The driver does not depend upon any properties other than the required >> properties >> so we are removing the file. > > That is not the criterion for whether something should be expresed in > the device tree. It's a description of the hardware, not a Linux driver > configuration file. If there are integration parameters that can not be > inferred from "this is FSL flexcan v1.0", they should be expressed in > the node. > > Removing the binding altogether seems extreme as well -- we should have > bindings for all devices, even if there are no special properties.
Yes, of course. The commit message misleading. We do not intend to remove the binding but just a few unused and confusing properties. Concerning the compatible string, Freescale introduced for the Flexcan on the P1010 "fsl,flexcan-v1.0". That's not the usual convention also because the v1.0 if for the PowerPC cores only, I assume, but we have ARM cores as well. If we need to distinguish I think we should use: "fsl,p1010-flexcan", "fsl,flexcan" Do you agree? >> Additionally, the p1010*dts files are not >> following the standard for node naming in that they have a trailing -v1.0. > > What "standard for node naming"? There's nothing wrong with putting a > block version number in the compatible string, and it looks like the > p1010 dts files were following the binding document in this regard. It > is common practice when the block version is publicly documented but > there's no register it can be read from at runtime. See above. Furthermore I must admit, that the bindings shown up mainline Linux have never been presented on any mailing list. Wolfgang. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev