Re: [PATCH 2/2] dt-bindings: usb: snps,dwc3: Fix downstream port numbering

[Neil Armstrong]

On 10/14/26 18:36, Konrad Dybcio wrote:
> On 10/14/26 11:44 AM, Neil Armstrong wrote:
> > On 10/14/26 11:29, Chen-Yu Tsai wrote:
> > > On Wed, Oct 14, 2026 at 5:28 PM Neil Armstrong
> > > <neil.armstrong@xxxxxxxxxx> wrote:
> > > > On 10/14/26 10:20, Chen-Yu Tsai wrote:
> > > > > The DWC3 controller can operate in host mode. It does so with a XHCI
> > > > > compliant host controller. The XHCI has two downstream ports, one for
> > > > > HS and one for SS. USB downstream ports start from 1, not 0.
>
> [...]
>
>
> > > IMHO having consistent numbering across controller types would be
> > > better. This avoids making the USB core and hub code deal with more
> > > exceptions, and also easier to understand and write device trees.
> >
> > I was in the impression the port number not necessarily reflects
> > an actual physical numbering, and can be a logical number we would
> > then map in the kernel.
> >
> > I don't see any issue here having base 0 for the bindings and then
> > converting it to base 1 for the XHCI port numbering.
>
> I thought base1 comes from the USB spec and not just XHCI?

This is my question, is the spec says: each USB Host Controller root
port shall be considered as a port of a Hub and numbered the same way,
then fine, let's use the base1 numbering.

As I understand how USB is architectured, all downstream ports of Hubs
are numbered in base1, and the whole topology is based on that.

But here, we are speaking of physically separate USB busses, one
USB2.0 and one USB3.0, a controller could also have 10 USB2.0 ports
and 5 USB3.0 ports, who knows. The way those will be numbered is not
part of the specification because the specification only the defines
the topology of an USB bus, like PCI(e) defines the topology on a PCI(e) bus.

How we aggregate all those busses to abstract them to software is not
part of the spec, we chose to declare a fake root Hub with a physical
downstream port as a virtual port of the root Hub, fine but this is
purely software abstraction.

We may only use the hardware IP port numbering in the bindings, not
the software abstraction.

We could use the base1 to describe the DWC3 ports, but how to describe
all the physical USB busses a controller can expose ? We may not limit
the bindings to USB2.0 and USB3.0 ports only.

How about the USB4, does it use the USB3.0 port ?

Neil

> Konrad