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

On Mon, 20 Jan 2014 17:03:23 -0800, Olof Johansson [off-list ref] wrote:

On Mon, Jan 20, 2014 at 2:47 PM, Grant Likely [off-list ref] wrote:

quoted

On Wed, 15 Jan 2014 16:12:24 +0000, Mark Rutland [off-list ref] wrote:

quoted

quoted

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.

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

Hmmm, yes. to handle that case would need a higher level construct that
keeps the name and interrupt value together. Maybe something like this?

device {
	add-interrupt(27);
	add-interrupt(29, 5, controller=&intc1);
	add-interrupt(2, 4, name="error");
};

I'm using python-like syntax here where controller and name are optional
arguments.

We could get DTC to generate the appropriate interrupt-parent,
interrupts, interrupts-extended and interrupt-names properties as
needed. Of course the shared context would be lost when the tree is
compiled, but it would be useful for building up parsing data. It would
also work for gpio, clocks and similar bindings. Kind of like an
intelligent macro.

g.