On Mon, Jan 20, 2014 at 05:03:23PM -0800, Olof Johansson wrote: > 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. So, in principle my preferred way to handle things like this would be to add richer expression support, including a token for "previous value" when overlaying. But although I've recently had another look at it, that's still a ways off, so I wouldn't object to another approach as a stopgap, as long as its not too hideous. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
pgpIIHY70Zoea.pgp
Description: PGP signature
