On Thu, Jan 2, 2025 at 8:08 PM Stephen Gordon <gordoste@xxxxxxxxxxxx> wrote:
>
> 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 { }; };
> };
Well, this should be easy to fix. We have addresses, so we should
iterate in address order.
> 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.
Can you just iterate by the index instead? We have functions which
return the specified port and/or endpoint number.
We can't really wholesale sort the child list to address order. While
that is the preferred source order as well, I'm sure there's something
somewhere depending on the order. The order can affect probe order
just like linking order does. However, I think we can safely change
the graph functions to guarantee address order. That means we need a
version of of_get_next_child() which guarantees it goes in address
order and then use that in the graph functions. It won't be efficient
since each iteration has to walk the whole list of children, but
there's never a lot of ports/endpoints.
Rob
