Re: [RFC 9/9] of/irq: create interrupts-extended property

[Benjamin Herrenschmidt]

On Mon, 2013-10-28 at 15:47 -0600, Stephen Warren wrote:

> "interrupts-ex" would be shorter, although I guess slightly harder to
> guess its purpose, unless you're familiar with "ex" in symbol names.
> 
> ...
> >> +A device node may contain either "interrupts" or "interrupts-extended", but not
> >> +both. If both properties are present, then the operating system should log an
> >> +error
> 
> That sounds rather like prescribing SW behaviour, which I thought DT
> bindings shouldn't do?
> 
> >> and use only the data in "interrupts".
> 
> ... so perhaps that's better phrased as:
> 
> A device node may contain either "interrupts" or "interrupts-extended",
> but not both. If both properties are present, the data in "interrupts"
> takes precedence.

So let's add a coat of paint to this shed :-)

Either it's an error, or we have a precedence rule. If it's an error
then there is no point having a precedence rule, the DT is broken and
might be in all sort of other ways, the precedence is pointless, there's
no telling what property is correct.

However, if we have a precedence rule, then it should be the other way
around, interrupts-extended takes precedence.

A concrete example:

A device has two interrupts "INT0" and "INT1". One goes to PICA, the
other one to PICB,
the first one is necessary for basic use, the second one is only
necessary for some advanced/new functionality.

It makes sense in this case to have the device-tree do:

   interrupts = < INT0 >;
   interrupt-parent = <&PICA>;
   interrupts-extended = <&PICA, INT0, &PICB, INT1>;

Because that way:

 - An old kernel which doesn't understand interrupts-extended but *also*
only uses the first interrupt (doesn't exploit the advanced/new
functionalities) will work by picking up interrupts+interrupt-parent,

 - A newer kernel which does understand interrupts-extended can then
make use of it to support the advanced/new functionalities.

Cheers,
Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/