RFC: proposal to extend the open-pic interrupt specifier definition

[Grant Likely]

On Tue, Jan 12, 2010 at 11:06 PM, Grant Likely
<grant.likely at secretlab.ca> wrote:
> On Tue, Jan 12, 2010 at 11:36 AM, Yoder Stuart-B08248
> <B08248 at freescale.com> wrote:
>>> > The advantage of the above approach is backwards compatibility.
>>> > Existing interrupt specifiers (and device trees) are valid with
>>> > this proposal.
>>>
>>> Actually they're not, like BenH pointed out.
>>
>> The proposal is backwards compatible.  An existing interrupt
>> specifier  (e.g. interrupts = <24 2>;) retains its exact
>> same meaning.  Old device trees do not need to change
>> to comply with the proposal.
>
> You also need to deal with the case of old drivers incorrectly binding
> to and trying to understand the new data.
>
>> I'm not directly familiar with the case Ben pointed out, but
>> it sounded like Apple used the 1st cell in some non-standard
>> way.
>>
>> It is true that openpic drivers would need to change to handle
>> the new specifier-- minimally masking the level/sense field
>> to 2 bits.
>
> Which makes the new binding incompatible with old kernels/drivers
> which just leads to confusion.  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.

Oh, and BTW, this is *exactly* why I advocate being explicit about
what part the node describes instead of depending on some generic
name.  ie. "fsl,p4080-mpic" instead of "chrp,open-pic".  So that you
can deal with part specific oddities and so you can create new
bindings when necessary.  Nodes can still put backwards compatible
entries in the compatible list after the specific device when
appropriate so that existing drivers can still bind to them.

g.

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