On 3/01/2025 3:46 am, Rob Herring wrote:
The order should not be significant. What are the nodes where the order matters?
The devicetree spec certainly doesn't make any guarantees of node order,
so this is a reasonable question.
The driver in question is using the of_graph_* functions with a tree like:
ports {
p0: port@0 { reg = <0>; endpoint { }; };
p1: port@1 { reg = <1>; endpoint { }; };
p2: port@2 { reg = <2>; endpoint { }; };
};
The driver navigates to p0 using various graph functions, because it
needs to process that before any other endpoint. It then uses
of_graph_get_next_port_endpoint to iterate through the remaining
endpoints. However, when the DT is created by dynamic.c, p0 is last and
no further endpoints are returned. If the tree is created by fdt.c or
pdt.c, everything works fine, because the list of siblings is in the
order they were specified in the file.
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.
AFAICS, this is the only example where child nodes are not inserted at
the end, so a different order is guaranteed when the tree is loaded by
this code (versus fdt.c/pdt.c).
For example, code using a phandle to access the "first" child of a node
and then calling of_get_next_child() to attempt to iterate through the
siblings will work fine - except on trees loaded by dynamic.c.
In the end, it's up to you. If this can't be changed, then we can fairly
easily work around it. I just thought it was worth letting you know that
the various tree-building mechanisms behave differently in this regard.
Happy New Year!
Regards
Stephen
