[RFC PATCH 1/1] of/irq: create interrupts-extended-2 property

[Mark Rutland]

On Tue, Jan 21, 2014 at 01:03:23AM +0000, Olof Johansson wrote:
> On Mon, Jan 20, 2014 at 2:47 PM, Grant Likely <grant.likely at linaro.org> wrote:
> > On Wed, 15 Jan 2014 16:12:24 +0000, Mark Rutland <mark.rutland at arm.com> wrote:
> >> >
> >> > Another, more invasive option would be extend the dts syntax and teach
> >> > dtc to handle property appending. Then the soc dts could stay as it is,
> >> > and the board dts could have something like:
> >> >
> >> >     /append-property/ interrupts = <&intc1 6 1>;
> >> >     /append-property/ interrupt-names = "board-specific-irq";
> >> >
> >> > Both these options solve the issue at the source, are general to other
> >> > properties, and allow more than one level of hierarchy (the proposed
> >> > interrupts-extended-2 only allows one level).
> >>
> >> I've just had a go at implementing the append-property mechanism above
> >> in dtc, and it was far easier than I expected (patch below).
> >>
> >> Does anyone have any issues with the /append-property/ idea?
> >
> > I think that is reasonable.
> 
> 
> The main problem with this (same for clocks) is if you need to append
> something with a name when the original didn't have any.

Can you not just add a name in the original file? I assume we're not
going to use this to adjust dts files we're not already in full control
of.

> 
> Reordering entries might not work for interrupts, since the bindings
> might have requirements on order.

That's a fair point.

Do we currently have any optional/board-specific interrupts which must
appear at the start or middle of the list?

For those, could we add names? The kernel should be abel to fall back to
ordering if names aren't present, and we can recommend a particular
ordering for compatiblity with older kernels.

As a general preventative measure it would be nice to have named
elements whenever elements can be optional.

> 
> I'm not aware of a good solution for this. Suggestions welcome.

Me neither. Prepending and appending is easy.

Inserting and/or modifying the list requires knowledge of the size of
each element (and for variable-sized entries requires knowledge of the
particular binding, which we cannot embed in dtc). 

I suspect adding richer syntax for modifying properties in arbitrary
ways will devolve into a turing tarpit.

Thanks,
Mark.