Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH] libfdt: place new nodes & properties after the parent's
 ones
To:     David Gibson <david@gibson.dropbear.id.au>
Cc:     devicetree-compiler@vger.kernel.org, linux-kernel@vger.kernel.org,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
From:   Marek Szyprowski <m.szyprowski@samsung.com>
Message-ID: <bc380fd8-71bb-897e-f060-b51386dec9be@samsung.com>
Date:   Mon, 10 Feb 2020 12:40:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
        Thunderbird/68.4.2
MIME-Version: 1.0
In-Reply-To: <20200205054508.GG60221@umbus.fritz.box>
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 201P
References: <CGME20200204125854eucas1p19ace564a5f45b9231e0fba8af07009cd@eucas1p1.samsung.com>
        <20200204125844.19955-1-m.szyprowski@samsung.com>
        <20200205054508.GG60221@umbus.fritz.box>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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@samsung.com>
> 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. This sometimes 
has some side-effects.

For comparison, the other lib used for fdt manipulation (libufdt) 
applies overlays in a such way, that the order of properties and nodes 
is not reversed.

> I'm also concerned this could have a negative performance impact,
> since it has to skip over a bunch of existing things before adding the
> new one.  On the other hand, that may be offset by the fact that it
> will reduce the amount of stuff that needs to be memmove()ed later on.

This code is already slow (especially in the way the uboot's use it for 
'fdt apply' command), but in practice I've didn't observe negative 
impact on the performance of applying large overlays at all.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland