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
