From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Sven Peter <sven@kernel.org>
Cc: Andreas Noever <andreas.noever@gmail.com>,
Mika Westerberg <westeri@kernel.org>,
Yehezkel Bernat <YehezkelShB@gmail.com>,
Konrad Dybcio <konradybcio@kernel.org>,
asahi@lists.linux.dev, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v2 1/7] thunderbolt: Hold a router reference for each path hop
Date: Mon, 24 Aug 2026 13:37:59 +0200 [thread overview]
Message-ID: <20260824113759.GH893316@black.igk.intel.com> (raw)
In-Reply-To: <295cce78-47d2-4a6e-af90-696edb60a05d@kernel.org>
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 ;-)
next prev parent reply other threads:[~2026-08-24 11:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-23 16:09 [PATCH v2 0/7] thunderbolt: Fix DP tunnel teardown while an async DPRX read is running Sven Peter
2026-08-23 16:09 ` [PATCH v2 1/7] thunderbolt: Hold a router reference for each path hop Sven Peter
2026-08-24 10:42 ` Mika Westerberg
2026-08-24 11:06 ` Sven Peter
2026-08-24 11:37 ` Mika Westerberg [this message]
2026-08-24 12:50 ` Sven Peter
2026-08-23 16:09 ` [PATCH v2 2/7] thunderbolt: Make the DP tunnel activation callback mandatory Sven Peter
2026-08-24 10:45 ` Mika Westerberg
2026-08-24 14:13 ` Sven Peter
2026-08-24 14:17 ` Mika Westerberg
2026-08-23 16:09 ` [PATCH v2 3/7] thunderbolt: Fix domain reference leak when DPRX read is canceled Sven Peter
2026-08-23 16:09 ` [PATCH v2 4/7] thunderbolt: Don't access a DP tunnel after its DPRX read was canceled Sven Peter
2026-08-23 16:09 ` [PATCH v2 5/7] thunderbolt: Mark discovered tunnels as active Sven Peter
2026-08-23 16:09 ` [PATCH v2 6/7] thunderbolt: Tear down inactive DP tunnels when the domain is stopped Sven Peter
2026-08-23 16:09 ` [PATCH v2 7/7] thunderbolt: Drop the DP tunnel activation callback data Sven Peter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260824113759.GH893316@black.igk.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=YehezkelShB@gmail.com \
--cc=andreas.noever@gmail.com \
--cc=asahi@lists.linux.dev \
--cc=konradybcio@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=sven@kernel.org \
--cc=westeri@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®