[PATCH] ARM: dts: add interrupt-names property to get interrupt resource by name

Sylwester Nawrocki sylvester.nawrocki at gmail.com
Wed Mar 20 08:40:12 EST 2013


On 03/18/2013 04:50 PM, Rob Herring wrote:
> On 03/13/2013 05:42 PM, Sylwester Nawrocki wrote:
>> On 03/13/2013 03:39 PM, Rob Herring wrote:
>>> I fail to see what the hack is. The order of interrupt properties must
>>> be defined by the binding. interrupt-names is auxiliary data and must
>>> not be required by an OS.
>>
>> It is clear that the order of the interrupts must be defined by the
>> bindings. But how useful<resource>-names properties are when we
>> cannot define them as required ? If an OS cannot rely on them then
>> it must use some other, reliable, method to identify the resources,
>> e.g. by hard coding the indexes. If we have to do it then why even
>> bother with the<resource>-names properties ? I can see interrupt-names
>> property specified as required in at least 2 bindings' documentation
>> and all bindings having reg-names property define it as required.
>> Are they wrong them ?
>
> You can require the name for a binding definition, but that does not
> remove the requirement that the order and index of interrupts also be
> defined by the binding. Then it is up to the OS to use names or
> hard-coded indexes. Hard-coded indexes are not a hack. This is how FDT
> and OF are defined to work.

OK, that makes it all crystal clear for me, thanks.

> I'm still not clear how changing the order of the interrupts removes a hack.

Originally the binding in question was not specifying the interrupt
order at all. And the drivers required order of the interrupt resources
different than in what they were normally defined in the SoC interrupt
combiner. So I suggested to use the interrupt-names property to make it
all more explicit and less error prone. I once had to fix the order of
the FIMD interrupts in the device tree to make the display work, since
I used a patch where the interrupts were listed in the IRQ combiner order,
and not the order expected by the driver.

I wasn't really clear then whether the order of interrupts needs to be
still fixed by the binding when the interrupt-names property was used.

That said I don't think there was previously any hack there. Just an
undocumented expected order of the interrupts in DT, different than the
normal order in the IRQ combiner. So it is really hard to agree with
what's written in the $subject patch description as it is now.

Thanks,
Sylwester


More information about the devicetree-discuss mailing list