On Tue, Oct 08, 2024 at 08:23:43PM +0200, Lukas Wunner wrote:
> On Tue, Oct 08, 2024 at 07:37:32PM +0300, mika.westerberg@xxxxxxxxxxxxxxx wrote:
> > On Tue, Oct 08, 2024 at 03:58:34PM +0200, Lukas Wunner wrote:
> > > Finally, I'd appreciate if you could send me dmesg output with the
> > > refcounting fix applied. As said before, the MTL Thunderbolt controller
> > > claims that the link and slot presence bits are cleared, so it
> > > de-enumerates everything attached via Thunderbolt. I'm wondering
> > > if it then re-enumerates the Thunderbolt-attached devices so they're
> > > actually usable?
> > >
> > > I'm hoping Mika can clarify with Intel Thunderbolt CoE whether this
> > > is a hardware issue in MTL that can e.g. be fixed through a firmware
> > > or BIOS update.
> >
> > I think here it happens because we reset the host router when the driver
> > probes so all the BIOS CM created tunnels will be torn down as well.
>
> Okay this seems to have been introduced by 0fc70886569c ("thunderbolt:
> Reset USB4 v2 host router").
Correct, and there is similar commit for USB4 v1 routers.
> Is that a good idea though? What if the machine was booted from a
> Thunderbolt-attached drive? At least on Macs that has been supported
> since day 1. I'd assume that it may cause issues if the connection to
> the drive on which the root partition resides is forcefully torn down
> and re-established?
For Macs we still "discover" the topology. This is only for software
connection manager USB4 hosts. This same "strategy" is being used in
Windows nowadays, it allows to re-configure sub-optimal setup that the
BIOS CM might have done and avoids some issues too on AMD. Placing
necessary drivers in initrd should allow root partition to be connected
over USB4 (and there is the chicken bit, thunderbolt.host_reset=0 if
user absolutely does not want this behavior).
