linux-kernel - Re: [PATCH] of: dynamic: Avoid reversing sibling order

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL_Jsq+4XVq6-i1+96ov7ysuBhWBxvt=oLB8n7mdpAh09wvvwA@mail.gmail.com>
Date: Thu, 2 Jan 2025 10:46:50 -0600
From: Rob Herring <robh@...nel.org>
To: Stephen Gordon <gordoste@...et.net.au>
Cc: Saravana Kannan <saravanak@...gle.com>, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] of: dynamic: Avoid reversing sibling order

On Mon, Dec 30, 2024 at 6:03 AM Stephen Gordon <gordoste@...et.net.au> wrote:
>
> Current implementation inserts nodes at the head of the list, resulting
> in sibling order being reversed from the .dts file. Some drivers care
> about the order and do not work properly. These changes add nodes at the
> end of the list instead, preversing sibling order.

s/preversing/preserving/

>
> Signed-off-by: Stephen Gordon <gordoste@...et.net.au>
> ---
>
> I ran across this issue using the ASoC audio_graph_card2 driver. Prior
> to the fix, I needed to reverse sibling order in the .dts to make things
> work. After the fix, it all works as expected.

The order should not be significant. What are the nodes where the order matters?

If the order matters, we create yet another problem with overlays
because if an overlay adds a child node where does it go WRT existing
child nodes? There is no way for the overlay to express that.

> Also, I noticed that drivers/of/fdt.c line 325-330 fix the same problem
> for flattened device trees.

Obviously some platforms cared at some point. Who knows if those still
exist or not. I'd rather not create more unknown cases. Though it's
probably not possible to enumerate the exceptions here. (I'm trying to
reduce the number of unconditional work-arounds for bad DTs in the DT
code and make them explicit so that we don't see new cases and can
remove work-arounds if platforms are removed.)

Rob