On Wed, Feb 12, 2020 at 12:57 AM Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> wrote: > > Hi Rob, > > On 11.02.2020 21:29, Rob Herring wrote: > > On Mon, Feb 10, 2020 at 5:44 PM David Gibson > > <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > >> On Mon, Feb 10, 2020 at 12:40:19PM +0100, Marek Szyprowski wrote: > >>> Hi David, > >>> > >>> On 05.02.2020 06:45, David Gibson wrote: > >>>> On Tue, Feb 04, 2020 at 01:58:44PM +0100, Marek Szyprowski wrote: > >>>>> While applying dt-overlays using libfdt code, the order of the applied > >>>>> properties and sub-nodes is reversed. This should not be a problem in > >>>>> ideal world (mainline), but this matters for some vendor specific/custom > >>>>> dtb files. This can be easily fixed by the little change to libfdt code: > >>>>> any new properties and sub-nodes should be added after the parent's node > >>>>> properties and subnodes. > >>>>> > >>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> > >>>> I'm not convinced this is a good idea. > >>>> > >>>> First, anything that relies on the order of properties or subnodes in > >>>> a dtb is deeply, fundamentally broken. That can't even really be a > >>>> problem with a dtb file itself, only with the code processing it. > >>> I agree about the properties, but generally the order of nodes usually > >>> implies the order of creation of some devices or objects. > >> Huh? From the device tree client's point of view the devices just > >> exist - the order of creation should not be visible to it. > > I'm not sure if downstream is different, but upstream this stems from > > Linux initcalls being processed in link order within a given level. > > It's much better than it used to be, but short of randomizing the > > ordering, I'm not sure we'll ever find and fix all these hidden > > dependencies. > > Downstream is probably much worse, because I've seen a lots of custom > code iterating over the nodes and doing its initialization. > > >>> This sometimes > >>> has some side-effects. > >> If those side effects matter, your code is broken. If you need to > >> apply an order to nodes, you should be looking at 'reg' or other > >> properties. > > The general preference is to sort by 'reg'. And we try to catch and > > reject any node re-ordering patches. > > If one applies an dt-overlay with current libfdt, the order of the all > nodes from that overlay is reversed. Sure, but my caring about the ordering ends at the source level. Rob
