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

[Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>]

Grant Likely wrote:
> On Tue, Jan 12, 2010 at 11:36 AM, Yoder Stuart-B08248
> <B08248-KZfg59tc24xl57MIdRCFDg@public.gmane.org> 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.

FWIW, Linux already does mask those bits.

> 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.

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

-Scott