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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.