All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.