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 ;-)
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.