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

[mark.rutland@arm.com (Mark Rutland)]

On Wed, Jan 15, 2014 at 12:40:41PM +0000, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 12:17 Wed 15 Jan     , Mark Rutland wrote:
> > On Wed, Jan 15, 2014 at 11:47:25AM +0000, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > The new interrupts-extended property, which reuses the phandle+arguments
> > > pattern used by GPIOs and other core bindings, still have some issue.
> > > 
> > > If an SoC have already specifiy interrupt and a board want to add specific
> > > interrupt such as GPIO (which can be optionnal) be need to re-define
> > > interrupts-extended. So allow to have an optionnale interrupts-extended-2
> > > property.
> > > 
> > 
> > NAK.
> > 
> > This is a hack that works around a dts organisation issue. This is _not_
> > a binding or parsing issue.
> 
> So the DT is stupid. Yes w have board and SoC information
> so we do not want to duplicate them. Having a way to descript SoC vs board
> specific information need to be provided.

I agree that the current situation isn't fantastic. That doesn't make
the DT stupid. There are other solutions to this problem.

> 
> > 
> > Properties can be overridden - just describe all of the interrupts in
> > the final dts file.
> this is wrong, which mean you duplicate informaation and duplicate bug and
> fixes

It's certainly not nice, but it doesn't make it wrong.

The same problem can be found with any other list property that varies
per-board. Hacking the parsing of each property is not a solution.

Today the only way to implement what you want is to have the list in the
final file.

One way of working with that would be to have the common interrupts
described in a shared macro in the soc file:

#define SOC_COMMON_INTERRUPTS <&intc1 5 1>, <&intc2 1 0>

Then the soc file can have:

	interrupts = SOC_COMMON_INTERRUPTS;

And the board can have:

	interrupts = SOC_COMMON_INTERRUPTS, <&intc1 6 1>;

That gains functionality equivalent to your proposal, without
introducing new code or new edge cases in interrupt parsing. However, it
does make it unclear how many interrupts are described, and it won't
interact well with interrupt-names.

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).

Thanks,
Mark.