From: Meador Inge <meador_inge@mentor.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: linuxppc-dev@lists.ozlabs.org,
devicetree-discuss@lists.ozlabs.org, "Blanchard,
Hollis" <Hollis_Blanchard@mentor.com>
Subject: Re: [RFC] MPIC Bindings and Bindings for AMP Systems
Date: Wed, 05 Jan 2011 16:20:48 -0600 [thread overview]
Message-ID: <4D24EEC0.2020909@mentor.com> (raw)
In-Reply-To: <20101223223325.GK20384@angua.secretlab.ca>
On 12/23/2010 04:33 PM, Grant Likely wrote:
> This argument has been rehashed many times, but it basically comes
> down to compatible values should ideally be anchored to a real
> implemented device, not to a family of devices, or to an unversioned
> specification.
>
> In practise, the implementation doesn't actually look any different
> except that the 'reference' version specifies a specific
> implementation instead of a generic name. To use a concrete example,
> if there are two parts using this MPIC, like the freescale p2040 and
> p4080, and say for argument that the p2040 was implemented first, then
> the compatible values would look like:
>
> for the p2040: compatible = "fsl,p2040-msgr";
> for the p4080: compatible = "fsl,p4080-msgr", "fsl,p2040-msgr";
>
> and the driver could simply bind on "fsl,p2040-msgr" to work with both
> chips. So, instead of an arbitrary "fsl,mpic-msgr" string,
> "fsl,p2040-msgr" is used as the baseline value and there is no
> ambiguity about which part it describes.
>
> If the p4080 is actually subtly different from the p2040, then
> it would not claim compatibility with the former and the driver can
> match against either string; adapting its behaviour as necessary.
Thanks for the explanation. I see now that there is a warning note in
'http://www.devicetree.org/Device_Tree_Usage' about this case. Perhaps
a "best practices" guide for writing bindings might be useful as well.
I would be happy to contribute to that, but I am still learning the best
practices :)
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
WARNING: multiple messages have this Message-ID (diff)
From: Meador Inge <meador_inge-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
"Blanchard,
Hollis"
<Hollis_Blanchard-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
Subject: Re: [RFC] MPIC Bindings and Bindings for AMP Systems
Date: Wed, 05 Jan 2011 16:20:48 -0600 [thread overview]
Message-ID: <4D24EEC0.2020909@mentor.com> (raw)
In-Reply-To: <20101223223325.GK20384-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org>
On 12/23/2010 04:33 PM, Grant Likely wrote:
> This argument has been rehashed many times, but it basically comes
> down to compatible values should ideally be anchored to a real
> implemented device, not to a family of devices, or to an unversioned
> specification.
>
> In practise, the implementation doesn't actually look any different
> except that the 'reference' version specifies a specific
> implementation instead of a generic name. To use a concrete example,
> if there are two parts using this MPIC, like the freescale p2040 and
> p4080, and say for argument that the p2040 was implemented first, then
> the compatible values would look like:
>
> for the p2040: compatible = "fsl,p2040-msgr";
> for the p4080: compatible = "fsl,p4080-msgr", "fsl,p2040-msgr";
>
> and the driver could simply bind on "fsl,p2040-msgr" to work with both
> chips. So, instead of an arbitrary "fsl,mpic-msgr" string,
> "fsl,p2040-msgr" is used as the baseline value and there is no
> ambiguity about which part it describes.
>
> If the p4080 is actually subtly different from the p2040, then
> it would not claim compatibility with the former and the driver can
> match against either string; adapting its behaviour as necessary.
Thanks for the explanation. I see now that there is a warning note in
'http://www.devicetree.org/Device_Tree_Usage' about this case. Perhaps
a "best practices" guide for writing bindings might be useful as well.
I would be happy to contribute to that, but I am still learning the best
practices :)
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
next prev parent reply other threads:[~2011-01-05 22:20 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-23 6:51 [RFC] MPIC Bindings and Bindings for AMP Systems Meador Inge
2010-12-23 18:56 ` Grant Likely
2010-12-23 18:56 ` Grant Likely
2010-12-23 21:49 ` Meador Inge
2010-12-23 22:33 ` Grant Likely
2010-12-23 22:33 ` Grant Likely
2011-01-03 19:51 ` Scott Wood
2011-01-05 21:58 ` Meador Inge
2011-01-05 22:09 ` Scott Wood
2011-01-05 22:09 ` Scott Wood
2011-01-05 22:49 ` Blanchard, Hollis
2011-01-05 22:49 ` Blanchard, Hollis
2011-01-05 23:07 ` Scott Wood
2011-01-06 21:52 ` Blanchard, Hollis
2011-01-06 21:52 ` Blanchard, Hollis
2011-01-07 15:48 ` Grant Likely
2011-01-07 15:48 ` Grant Likely
2011-01-07 16:00 ` Blanchard, Hollis
2011-01-07 16:00 ` Blanchard, Hollis
2011-01-07 16:44 ` Grant Likely
2011-01-07 16:44 ` Grant Likely
2011-01-07 20:30 ` Blanchard, Hollis
2011-01-07 20:30 ` Blanchard, Hollis
2011-01-07 20:57 ` Scott Wood
2011-01-07 20:57 ` Scott Wood
2011-01-05 22:20 ` Meador Inge [this message]
2011-01-05 22:20 ` Meador Inge
2011-01-04 20:14 ` Blanchard, Hollis
2011-01-04 20:14 ` Blanchard, Hollis
-- strict thread matches above, loose matches on Subject: below --
2010-12-23 5:58 Meador Inge
2011-01-03 20:22 ` Scott Wood
2011-01-03 20:22 ` Scott Wood
2011-01-04 23:52 ` Meador Inge
2011-01-04 23:52 ` Meador Inge
2011-01-05 0:13 ` Scott Wood
2011-01-05 0:13 ` Scott Wood
2011-01-05 21:19 ` Meador Inge
2011-01-06 2:58 ` Meador Inge
2011-01-06 2:58 ` Meador Inge
2011-01-06 20:10 ` 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=4D24EEC0.2020909@mentor.com \
--to=meador_inge@mentor.com \
--cc=Hollis_Blanchard@mentor.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=linuxppc-dev@lists.ozlabs.org \
/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.