Re: [PATCH v6 11/16] dt-bindings: usb: mediatek,mtk-xhci: Switch to ports for USB connections

[Chen-Yu Tsai]

(Resending in plain text ...)

On Fri, Jul 31, 2026 at 10:34 PM Konrad Dybcio <konradybcio@xxxxxxxxx> wrote:
>
> On 7/31/26 4:33 PM, Konrad Dybcio wrote:
> > On 7/21/26 8:54 AM, Chen-Yu Tsai wrote:
> >> This reverts commit 454a1e3cd36c113341d7b71e8e691c6e47ab4a8a.
> >>
> >> MediaTek's XHCI implementation supports both USB 2.0 High Speed (HS)
> >> and USB 3.x Super Speed (SS). The block can also be synthesized with
> >> either HS-only capability or HS+SS capability. The SSUSB controller
> >> handles the device or gadget mode. Saying that SSUSB handles the HS
> >> portion is wrong.
> >
> > [...]
> >
> >> +  ports:
> >> +    $ref: /schemas/graph.yaml#/properties/ports
> >> +
> >> +    properties:
> >> +      port@1:
> >> +        $ref: /schemas/graph.yaml#/properties/port
> >> +        description: Super Speed (SS) data bus if SS-capable;
> >> +          otherwise High Speed (HS) data bus.
> >> +
> >> +      port@2:
> >> +        $ref: /schemas/graph.yaml#/properties/port
> >> +        description: High Speed (HS) data bus if controller is SS-capable.
> >
> > FWIW this is opposite vs what the (most common) DWC3 schema defines:
>
> (s/opposite/different to)

My version for mtk-xhci is modeled against what the hardware actually
reports, and thus what the kernel maps things to.

Yes it's different from what DWC3 uses, but then I'm not sure if folks
actually verified that the kernel maps the ports or onboard devices
correctly. The kernel doesn't actually check if the USB IDs one gives
in the device tree nodes matches or not. It only matches against the
port number. Put in another way, binding the device node to the USB
device is an afterthought.

I did a quick test on my Orange Pi 5 Plus, which is an RK3588 with a
GL3523 USB 2.0+3.0 hub connected to one of the DWC3 XHCIs. It seems
that port 1 is USB 2.0 and port 2 is USB 3.0. The ordering matches
the dwc3 binding, but the port number is off by 1. In hardware, USB
downstream ports are numbered starting at 1.

So yeah, we have problems.

> >
> >
> > (also true for mediatek,mtu3 and renesas,usb3-peri)
> >
> > -- Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml
> >   ports:
> >     $ref: /schemas/graph.yaml#/properties/ports
> >     description:
> >       Those ports should be used with any connector to the data bus of this
> >       controller using the OF graph bindings specified if the "usb-role-switch"
> >       property is used.
> >
> >     properties:
> >       port@0:
> >         $ref: /schemas/graph.yaml#/properties/port
> >         description: High Speed (HS) data bus.
> >
> >       port@1:
> >         $ref: /schemas/graph.yaml#/properties/port
> >         description: Super Speed (SS) data bus.

I feel like this numbering was only implemented for the gadget case, not
the host case. And it certainly doesn't match what one would put in for
onboard devices such as hubs. Ideally the numbering should be the same,
because it is a hardware property.

Any ideas for reconciling this? Mapping a device node to a USB host port
or downstream device is buried in the USB core. For example,
usb_of_get_device_node() and usb_of_get_connect_type() just take the USB
downstream port number (1-based).

OOTH dwc3 seems to just want _any_ graph connection to find an extcon
provider. The mtu3 driver doesn't even have any OF graph related calls.


Thanks
ChenYu