On Mon, Jan 20, 2014 at 2:47 PM, Grant Likely <grant.likely@xxxxxxxxxx> wrote: > On Wed, 15 Jan 2014 16:12:24 +0000, Mark Rutland <mark.rutland@xxxxxxx> 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. Reordering entries might not work for interrupts, since the bindings might have requirements on order. I'm not aware of a good solution for this. Suggestions welcome. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
