netdev - Re: [PATCH 5/5] [powerpc] Fix up fsl-flexcan device tree binding.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4E418B39.6040408@grandegger.com>
Date:	Tue, 09 Aug 2011 21:32:09 +0200
From:	Wolfgang Grandegger <wg@...ndegger.com>
To:	Scott Wood <scottwood@...escale.com>
CC:	Robin Holt <holt@....com>, Marc Kleine-Budde <mkl@...gutronix.de>,
	U Bhaskar-B22300 <B22300@...escale.com>,
	netdev@...r.kernel.org, socketcan-core@...ts.berlios.de,
	PPC list <linuxppc-dev@...ts.ozlabs.org>,
	"Devicetree-discuss@...ts.ozlabs.org" 
	<Devicetree-discuss@...ts.ozlabs.org>
Subject: Re: [PATCH 5/5] [powerpc] Fix up fsl-flexcan device tree binding.

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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html