Grant Likely wrote:
On Tue, Jan 12, 2010 at 11:36 AM, Yoder Stuart-B08248
<[email protected]> 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
_______________________________________________
devicetree-discuss mailing list
[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss
