Re: [PATCH v2 1/7] thunderbolt: Hold a router reference for each path hop
Mika Westerberg <[email protected]>
| Newsgroups | dev.linux.lists.asahi,org.kernel.vger.linux-kernel,org.kernel.vger.linux-usb,org.kernel.vger.stable |
|---|---|
| Message-ID | <[email protected]> |
Hi, On Mon, Aug 24, 2026 at 01:06:12PM +0200, Sven Peter wrote: > So unfortunately the entire USB hardware is best described as horribly > broken :( :-( > For USB2 already we only ever receive a single hotplug interrupt in dwc3. If > the first device is unplugged and another one plugged in nothing happens. > The only way around that is to tear down dwc3/xhci and the PHY completely, > assert all external reset lines and then bring them up again. > Upstream drivers/usb/dwc3/dwc3-apple.c contains more details in the very > first comment at the top. > > With USB4 this gets a bit worse: There's a block called "ACIO" (Apple > Converged I/O) which can only be brought up correctly after the PHY has been > switched to Thunderbolt/USB4 mode. This block has a co-processor which then > exposes the host router, NHI, IOMMU, etc. to our address space. > We then have to write cable information into a vendor-specific capabilities > register and only then do we get the hotplug event and the link comes up. > This register appears to be effectively write-once after each boot of the > co-processor. If I try to write 0 that still works but trying to write the > value for the next connection then crashes the co-processor with a very > helpful message along the lines of "assert 4357 violated". > So there's no way around first tearing everything down, then shutting down > the co-processor and the entire ACIO block and then finally bringing it all > up again after the next cable is connected. I've tried to find ways around > this but didn't succeed without documentation and could only reproduce what > XNU does. Thanks for sharing the interesting details! I totally understand the pain of reverse engineering things. The initial USB4/TB driver was also result of a huge reverse engineering effort by Andreas Noever, but it was and still is functional, and we still support Apple TB1/2 hardware (although not too much testing is done these days, I fire up my Cactus Ridge based Mac maybe once a year). But okay it does not sound like the PC ACPI hotplug "solution" we had at least. It's just a much more complex subsystem with many interactions that need to be done in certain order which is not documented anywhere ;-)