On Mon, Dec 30, 2024 at 6:03 AM Stephen Gordon <gordoste@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> > --- > > 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
