On Mon, Jun 27, 2022 at 11:14:47AM -0700, Matthias Kaehlcke wrote: > Maybe a bit more verbose documentation like this could help: > > Some background about the logic in this function, which can be a bit hard > to follow: > > Root hubs don't have dedicated device tree nodes, but use the node of their > HCD. The primary and secondary HCD are usually represented by a single DT > node. That means the root hubs of the primary and secondary HCD share the > same device tree node (the HCD node). As a result this function can be > called twice with the same DT node for root hubs. We only want to create a > single platform device for each physical onboard hub, hence for root hubs > the loop is only executed for the primary hub. Since the function scans By "primary hub", you mean "root hub for the primary HCD", right? This should be clarified. > through all child nodes it still creates pdevs for onboard hubs connected > to the secondary hub if needed. And likewise for "secondary hub". > > Further there must be only one platform device for onboard hubs with a > companion hub (the hub is a single physical device). To achieve this two What do you mean by "companion hub"? I think you are using the wrong word here. If you're talking about the relation between the two logical hubs (one attached to the SuperSpeed bus and one attached to the Low/Full/High-speed bus) within a physical USB-3 hub, the correct term for this is "peer". See the existing usages in hub.h, hub.c, and port.c. "Companion" refers to something completely different (i.e., the UHCI or OHCI controllers that handle Low/Full-speed connections on behalf of a High-speed EHCI controller). Alan Stern
