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. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
