Re: [PATCH v6 06/16] usb: hub: Associate port@ fwnode with USB port device

[Chen-Yu Tsai]

(dug this out of my kernel.org email)

On Fri, Jul 31, 2026 at 10:44 PM Konrad Dybcio
<konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
>
> On 7/21/26 8:54 AM, Chen-Yu Tsai wrote:
> > When a USB hub port is connected to a connector in a firmware node
> > graph, the port itself has a node in the graph.
> >
> > Associate the port's firmware node with the USB port's device,
> > usb_port::dev. This is used in later changes for the M.2 slot power
> > sequencing provider to match against the requesting port.
> >
> > To avoid potential conflicts with ACPI firmware nodes and then causing
> > power management issues, only assign the firmware node if the hub's
> > firmware node is not an ACPI firmware node.
> >
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
> > Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxxxxxxxx>
> > Signed-off-by: Chen-Yu Tsai <wenst@xxxxxxxxxxxx>
> > ---
>
> [...]
>
> > +     /*
> > +      * ACPI FW nodes are associated later when device_register() happens.
> > +      * Skip assigning one here to avoid potential conflicts.
> > +      */
> > +     if (!is_acpi_node(fwnode)) {
> > +             struct fwnode_handle *port;
> > +
> > +             /*
> > +              * fwnode_graph_get_port_by_id() returns either a valid fwnode handle
> > +              * or NULL. Passing NULL to device_set_node() clears any associated
> > +              * fwnode. It is effectively a no-op here, since no fwnode has been
> > +              * assigned to the newly created device yet.
> > +              */
> > +             port = fwnode_graph_get_port_by_id(fwnode, port1, FWNODE_GRAPH_DEVICE_DISABLED);
>
> This works if the node at the other end of the graph is a
> USB hub, e.g. from qcom/lemans-evk.dts:
>
> usb_hub_3_x: hub@2 {
>         compatible = "usb5e3,625";
>         reg = <2>;
>
>         peer-hub = <&usb_hub_2_x>;
>
>         ports {
>                 #address-cells = <1>;
>                 #size-cells = <0>;
>
>                 port@1 {
>                         reg = <1>;
>
>                         usb_hub_3_1: endpoint {
>                                 remote-endpoint = <&hd3ss3220_1_out_ep>;
>                         };
>                 };
>
>                 port@4 {
>                         reg = <4>;
>
>                         usb_hub_3_4: endpoint {
>                         };
>                 };
>         };
> };
>
> But something I faced when I was poking at USB4 was that dt-bindings
> currently assume every controller is effectively single-port and the
> of_graph ports under it represent HS/SS lanes, i.e. the entire
> "ports" subnode represents a single USB port

Which controller is this? AFAIK for xHCI hosts there currently is no
"ports" node specified in the common usb-hcd.yaml binding. I plan to
add this separately, as it can already be used for USB A connectors.

The kernel maps every downstream port of the root hub to a separate
node. On the XHCI it is more complicated because it has two root hubs,
one for HS and one for SS. I'm not familiar with the hardware specifics
but they seem to map into one common namespace, so you probably get
ports 1~8 for HS and then 9~12 for SS. Note the number of ports is
different. This is just an example from my x86 workstation. And on
x86 each port is mapped to a different ACPI node.

> I think the solution here would be to do ports {} under the controller
> and have every one of them have 2 endpoints (for HS and SS
> respectively) - then, each DT-port would correspond to a USB port
> (sorta like in the hub case, minus the hubs are split for HS/SS so
> they have just a single endpoint under each port)

But the hardware descriptors actually give two ports, one for HS and one
for SS. And in the case of dwc3, I suspect that they always come with
one downstream HS port and (optionally) one downstream SS port. So the
binding is actually correct, except for the numbering.

I'm looking into the dwc3 case. Changing the numbering might actually
not break anything. Linux seems to just need one *a* graph connection,
but doesn't care about the number. I looked through some other projects:

- FreeBSD doesn't use the OF graph for anything
- U-boot doesn't use the OF graph for USB
- OpenBSD doesn't support dwc3, only the XHCI in dwc3, and doesn't use the
  OF graph for USB
- coreboot doesn't use the OF graph for anything
- Zephyr doesn't support dwc3
- TF-A doesn't use the OF graph for anything
- EDK2 doesn't support dwc3 and doesn't support OF graph
- OP-TEE doesn't support dwc3 and doesn't support OF graph

> But that comes with a big breakage, as always..

As I mentioned, it probably isn't as large of a breakage.


ChenYu