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