From: Wolfgang Grandegger <wg@grandegger.com>
To: Scott Wood <scottwood@freescale.com>
Cc: netdev@vger.kernel.org,
"Devicetree-discuss@lists.ozlabs.org"
<Devicetree-discuss@lists.ozlabs.org>,
U Bhaskar-B22300 <B22300@freescale.com>,
socketcan-core@lists.berlios.de, Robin Holt <holt@sgi.com>,
PPC list <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
Date: Tue, 09 Aug 2011 21:32:09 +0200 [thread overview]
Message-ID: <4E418B39.6040408@grandegger.com> (raw)
In-Reply-To: <4E4179CB.6030101@freescale.com>
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.
WARNING: multiple messages have this Message-ID (diff)
From: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
To: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"Devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
<Devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
Subject: Re: [PATCH 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
Date: Tue, 09 Aug 2011 21:32:09 +0200 [thread overview]
Message-ID: <4E418B39.6040408@grandegger.com> (raw)
In-Reply-To: <4E4179CB.6030101-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
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.
next prev parent reply other threads:[~2011-08-09 19:32 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-09 14:43 [Patch 0/5] [flexcan/powerpc] Add support for powerpc flexcan (freescale p1010) -V9 Robin Holt
2011-08-09 14:43 ` Robin Holt
2011-08-09 14:43 ` [PATCH 1/5] [flexcan] Remove #include <mach/clock.h> Robin Holt
2011-08-09 14:43 ` Robin Holt
2011-08-09 14:43 ` [PATCH 2/5] [flexcan] Abstract off read/write for big/little endian Robin Holt
2011-08-09 14:43 ` Robin Holt
2011-08-09 14:43 ` [PATCH 3/5] [flexcan] Add of_match to platform_device definition Robin Holt
2011-08-09 14:43 ` Robin Holt
2011-08-09 14:43 ` [PATCH 4/5] [powerpc] Add flexcan device support for p1010rdb Robin Holt
2011-08-09 14:43 ` Robin Holt
2011-08-09 14:43 ` [PATCH 5/5] [powerpc] Fix up fsl-flexcan device tree binding Robin Holt
2011-08-09 14:43 ` Robin Holt
2011-08-09 18:17 ` Scott Wood
2011-08-09 18:17 ` Scott Wood
2011-08-09 18:45 ` Robin Holt
2011-08-09 18:45 ` Robin Holt
2011-08-09 19:13 ` Scott Wood
2011-08-09 19:13 ` Scott Wood
2011-08-09 19:13 ` Scott Wood
2011-08-09 19:49 ` Wolfgang Grandegger
2011-08-09 19:49 ` Wolfgang Grandegger
2011-08-09 19:58 ` Scott Wood
2011-08-09 19:58 ` Scott Wood
2011-08-09 19:58 ` Scott Wood
2011-08-09 20:59 ` Robin Holt
2011-08-09 20:59 ` Robin Holt
2011-08-10 14:52 ` Kumar Gala
2011-08-10 14:52 ` Kumar Gala
2011-08-10 16:16 ` Robin Holt
2011-08-10 16:16 ` Robin Holt
2011-08-09 19:32 ` Wolfgang Grandegger [this message]
2011-08-09 19:32 ` Wolfgang Grandegger
2011-08-09 20:11 ` Scott Wood
2011-08-09 20:11 ` Scott Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E418B39.6040408@grandegger.com \
--to=wg@grandegger.com \
--cc=B22300@freescale.com \
--cc=Devicetree-discuss@lists.ozlabs.org \
--cc=holt@sgi.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=netdev@vger.kernel.org \
--cc=scottwood@freescale.com \
--cc=socketcan-core@lists.berlios.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.