Re: [PATCH v2 1/7] thunderbolt: Hold a router reference for each path hop
Sven Peter <[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]> |
On 8/24/26 13:37, Mika Westerberg wrote: > 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). Hah, nice! I wasn't aware the initial version of this driver was built for Apple hardware! Let's see if we can the Apple Silicon changes into a shape where they still work 10+ years from now as well :-) Sven