Re: USB 2.0 host controller for Thunderbolt 4

[Mathias Nyman <mathias.nyman@linux.intel.com>]

On 23.5.2023 12.45, Moń, Tomasz wrote:
> On Tue, 2023-05-23 at 12:01 +0300, Mika Westerberg wrote:
>> On Tue, May 23, 2023 at 10:53:17AM +0200, Tomasz Moń wrote:
>>> When I connect Thunderbolt 3 dock, two new host controllers show up:
>>>    * usb5 - USB 2.0 High-Speed
>>>    * usb6 - USB 3.0 SuperSpeed
>>>
>>> Devices connected through Thunderbolt 3 dock end up on expected host
>>> controllers, i.e. Low/Full/High-Speed devices connect to usb5 and
>>> SuperSpeed devices end up on usb6.
>>>
>>> Is Thunderbolt 3 essentially tunnelling the USB 2.0 traffic (by
>>> tunnelling PCIe xHCI host controller traffic) on the superspeed
>>> differential pairs (operating in alternate TBT3 mode)?
>>
>> It is not. The USB 2.x wires are separate on type-C cables.
> 
> Yes, the USB 2.x wires are separate on type-C cables. But this does not
> answer the question why there is new USB 2.0 High-Speed controller
> showing up that the devices do connect to.
> 
> Wouldn't the Low/Full/High-Speed devices traffic appear on usb3 (PCH
> controller) if the USB 2.x wires in type-C cable were really used in
> this case (instead of the usb5 which appeared only after Thunderbolt 3
> was connected)?
> 
> I forgot to mention that the Thunderbolt 3 docking station in question
> has Intel Corporation DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C
> 2015] and ASMedia Technology Inc. ASM1042A USB 3.0 Host Controller.
> 
> The way I understand it, that the usb5 and usb6 come from ASM1042A
> (which implements xHCI). The communication would then be:
>    * Dell Latitude <-> Thunderbolt 3 dock (TBT3 tunnelling PCIe xHCI)
>    * ASM1042 (in Thunderbolt 3 dock) <-> USB 2.x devices connected to
> the dock (data never makes it to type-C D+/D- wires, because it is
> ASM1042 that generates the tokens)
> 
> Is there a flaw in my understanding?
> 
>>> When I connect Thunderbolt 4 dock, the SuperSpeed devices connected to
>>> dock ports end up on usb2 host controller. However, Low/Full/High-Speed
>>> devices do end up on usb3 (USB 3.2 xHCI) and not on usb1 (Alder Lake-P
>>> Thunderbolt 4 USB Controller).
>>
>> Yes, that's expected the TBT USB controller (on the host) does not
>> support USB 2.x so it is routed to the PCH one.
> 
> Should the driver be changed to not even register the dummy USB 2.0
> interface in such case?
> 

Even if nothing is routed to the TBT USB xHCI USB 2.x ports, the controller
itself reports it supports both Low/Full/High-Speed ports and SuperSpeed
ports, so driver creates roothubs for both.

This might be due to xHCI spec 7.2.2.1 USB Protocols stating:
"USB 2.0 and USB 3.x Supported Protocol Capabilities shall be declared
if any USB3 connectors are associated with xHCI Root Hub ports that enable user
attached devices. Refer to sections 11.1 and 11.3 in the USB3 spec."

xhci driver was recently changed to support xHCI hosts with only one
roothub (USB 2.x or USB 3.x) for xHCI platform devices, there is some minor
work needed in xhci-pci.c to support only one roothub for PCI xHCI controllers.

But as long as the controller reports having both USB 2.x and USB 3.x ports the
driver will create roothubs for both.

Thanks
Mathias