On 12:02 Tue 21 Jan , Mark Rutland wrote: > 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@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. > > 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 never was a fanof index search I do agree the names irq is the best way > > > > > 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. no this need to stay simple if too much complexe => mess up, unmaintainable if you really have complex stuff duplicate the info Best Regards, J. > > Thanks, > Mark. -- 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
