Devicetree
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
To: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: Yoder Stuart-B08248
	<B08248-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Subject: Re: RFC: proposal to extend the open-pic interrupt specifier definition
Date: Sun, 17 Jan 2010 00:06:37 -0700	[thread overview]
Message-ID: <fa686aa41001162306x7c4e3dedy196409a4c8420e35@mail.gmail.com> (raw)
In-Reply-To: <4B4E0AC7.7090502-KZfg59tc24xl57MIdRCFDg@public.gmane.org>

On Wed, Jan 13, 2010 at 11:02 AM, Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> Grant Likely wrote:
>> It's not worth toying with.  Just create a new compatible value for this
>> new binding and be done with
>> it.  When a driver gets modified to handle the new behaviour, then it
>> can be also changed to bind against the new compatible value too.
>
> I agree that a new compatible is warranted from a theoretical perspetive,
> though from a practical compatibility perspective one should consider the
> odds of something breaking because old code chokes on the new bits, versus
> the old code not recognizing the new compatible and thus not binding the
> device at all.

Letting old drivers bind against new bindings that aren't actually the
same isn't good practice and leaves little recourse if we really do
need to differentiate between them in the future.  Teaching the
current driver to match against the new value is a one line change.
Choosing a new compatible value is so inexpensive, trivial, and safe
that I think it is a no-brainer decision.

> Is there any interest in standardizing this with a new compatible, or should
> it be FSL-only?

Instead of trying to come up with a new "generic/standard" compatible
value, just adopt the name of the first part to use the new binding as
the standard compatible value.  If the binding catches on then great,
new parts will just claim compatibility with the old.  If it does not,
then we won't have wasted time trying to predict the future and
wrangling about what a so-called generic binding should look like.

So, instead of trying to do something like the following for, say, a
future 16 core version of the p4080:

compatible = "fsl,p4160-mpic", 'open-pic-enhanced";

Do this instead:

compatible = "fsl,p4160-mpic", "fsl,p4080-mpic"

This also has the advantage of the meaning of a fsl,p4080-mpic
compatible device is grounded in some real piece of hardware, not in
something made up who's definition can change over time.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

  parent reply	other threads:[~2010-01-17  7:06 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-05 23:28 RFC: proposal to extend the open-pic interrupt specifier definition Yoder Stuart-B08248
     [not found] ` <9696D7A991D0824DBA8DFAC74A9C5FA30590506E-ofAVchDyotYzzZk0BCvKg5jmvxFtTJ+o0e7PPNI6Mm0@public.gmane.org>
2010-01-07  0:50   ` David Gibson
2010-01-07  3:33     ` RFC: proposal to extend the open-pic interrupt specifierdefinition Yoder Stuart-B08248
     [not found]       ` <9696D7A991D0824DBA8DFAC74A9C5FA305987E61-ofAVchDyotYzzZk0BCvKg5jmvxFtTJ+o0e7PPNI6Mm0@public.gmane.org>
2010-01-07  4:55         ` David Gibson
2010-01-07 11:17           ` [Power.org:parch] " Sethi Varun-B16395
2010-01-07 17:18           ` Scott Wood
     [not found]             ` <4B46176F.2040600-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2010-01-13  6:04               ` Grant Likely
     [not found]                 ` <fa686aa41001122204w3ce1a31m7debe52a4b5d4fc7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-01-13 14:19                   ` Yoder Stuart-B08248
     [not found]                     ` <9696D7A991D0824DBA8DFAC74A9C5FA305988946-ofAVchDyotYzzZk0BCvKg5jmvxFtTJ+o0e7PPNI6Mm0@public.gmane.org>
2010-01-13 14:27                       ` Grant Likely
     [not found]                         ` <fa686aa41001130627g7ed3bd46p6ac50631576d89ef-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-01-13 17:23                           ` Scott Wood
     [not found]                             ` <4B4E01A8.5070509-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2010-01-17  7:13                               ` Grant Likely
     [not found]                                 ` <fa686aa41001162313u28ef0fb4s328ebc25bf5e551f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-01-18 17:44                                   ` Scott Wood
2010-01-07 17:39           ` Yoder Stuart-B08248
     [not found]             ` <9696D7A991D0824DBA8DFAC74A9C5FA305987F94-ofAVchDyotYzzZk0BCvKg5jmvxFtTJ+o0e7PPNI6Mm0@public.gmane.org>
2010-01-13  6:16               ` Grant Likely
2010-01-08  1:02     ` [Power.org:parch] Re: RFC: proposal to extend the open-pic interrupt specifier definition Benjamin Herrenschmidt
2010-01-12 18:17   ` Segher Boessenkool
     [not found]     ` <50433.84.105.60.153.1263320254.squirrel-JorI+TVEvZrY24RiXHRV3ti2O/JbrIOy@public.gmane.org>
2010-01-12 18:36       ` Yoder Stuart-B08248
     [not found]         ` <9696D7A991D0824DBA8DFAC74A9C5FA305988778-ofAVchDyotYzzZk0BCvKg5jmvxFtTJ+o0e7PPNI6Mm0@public.gmane.org>
2010-01-13  6:06           ` Grant Likely
     [not found]             ` <fa686aa41001122206l232b270er58323a6409e575e9-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-01-13  6:24               ` Grant Likely
     [not found]                 ` <fa686aa41001122224t2eeec9acy15b40420ebe18541-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-01-13 18:06                   ` Scott Wood
     [not found]                     ` <4B4E0B96.1030204-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2010-01-17  6:42                       ` Grant Likely
2010-01-13 18:02               ` Scott Wood
     [not found]                 ` <4B4E0AC7.7090502-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2010-01-17  7:06                   ` Grant Likely [this message]
     [not found]                     ` <fa686aa41001162306x7c4e3dedy196409a4c8420e35-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-01-18 17: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=fa686aa41001162306x7c4e3dedy196409a4c8420e35@mail.gmail.com \
    --to=grant.likely-s3s/wqlpoipyb63q8fvjnq@public.gmane.org \
    --cc=B08248-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox