linux-kernel - Re: [PATCH] thunderbolt: Fix PCIe device enumeration with delayed rescan

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260127101701.GI2275908@black.igk.intel.com>
Date: Tue, 27 Jan 2026 11:17:01 +0100
From: Mika Westerberg <mika.westerberg@...ux.intel.com>
To: "Chia-Lin Kao (AceLan)" <acelan.kao@...onical.com>,
	Andreas Noever <andreas.noever@...il.com>,
	Mika Westerberg <westeri@...nel.org>,
	Yehezkel Bernat <YehezkelShB@...il.com>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org, Gil Fine <gil.fine@...ux.intel.com>
Subject: Re: [PATCH] thunderbolt: Fix PCIe device enumeration with delayed
 rescan

On Tue, Jan 27, 2026 at 09:45:13AM +0100, Mika Westerberg wrote:
> On Tue, Jan 27, 2026 at 01:04:20PM +0800, Chia-Lin Kao (AceLan) wrote:
> > On Mon, Jan 26, 2026 at 12:56:54PM +0100, Mika Westerberg wrote:
> > > On Mon, Jan 26, 2026 at 03:48:48PM +0800, Chia-Lin Kao (AceLan) wrote:
> > > > On Mon, Jan 26, 2026 at 06:42:31AM +0100, Mika Westerberg wrote:
> > > > > On Mon, Jan 26, 2026 at 11:30:47AM +0800, Chia-Lin Kao (AceLan) wrote:
> > > > > > Hi,
> > > > > > On Fri, Jan 23, 2026 at 01:01:12PM +0100, Mika Westerberg wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Fri, Jan 23, 2026 at 10:04:11AM +0800, Chia-Lin Kao (AceLan) wrote:
> > > > > > > > > Can you comment out call to tb_switch_xhci_connect() and see if that
> > > > > > > > > changes anything?
> > > > > > > >
> > > > > > > > Here is what I modified, and the problem becomes a little bit complicated.
> > > > > > >
> > > > > > > Okay I see it did not change anything (well this is kind of what I
> > > > > > > expected). Thanks for trying.
> > > > > > >
> > > > > > > I see in your log that the PCIe tunnel is established just fine. It's just
> > > > > > > that there is no PCIe hotplug happening or it is happening but the PCIe
> > > > > > > Downstream Port is not waking up.
> > > > > > >
> > > > > > > I figured you have following USB4/TB topology, right?
> > > > > > >
> > > > > > >   AMD Host <-> GR Hub <-> TB3 Hub
> > > > > > >                   ^
> > > > > > >                   |
> > > > > > >                 TB3 Hub
> > > > > > Should be more like this
> > > > > >   AMD Host <-> Dell TB4 Dock <-> OWC Envoy Express (1-502)
> > > > > >                              \
> > > > > >                               <-> OWC Envoy Express (1-702)
> > > > > > or
> > > > > >   AMD Host (1-0, domain1)
> > > > > >       |
> > > > > >       └─ Port 2 ──→ Dell Thunderbolt 4 Dock (1-2)
> > > > > >                       ├─ Port 5 ──→ OWC Envoy Express (1-502)
> > > > > >                       └─ Port 7 ──→ OWC Envoy Express (1-702)
> > > > >
> > > > > Okay so the same ;-)
> > > > >
> > > > > > > What if you run 'lspci' after the issue reproduces? Does that bring the
> > > > > > > missing PCIe devices? I suspect that this is due to older TB3 devices that
> > > > > > > they may need bit more time to get the PCIe link (going over the tunnel) up
> > > > > > > and running.
> > > > > > lspci doesn't bring back the missing tbt storage.
> > > > >
> > > > > Forgot to mention that let it (the whole topology) enter runtime suspend
> > > > > before you run lspci.
> > > >
> > > > https://people.canonical.com/~acelan/bugs/tbt_storage/dmesg_lspci.log
> > > >
> > > > The behavior is strange, the following 3 devices keep entering D3cold and then comes back
> > > > to D0 quickly. So, I'm not sure if the lspci do the actions you want.
> > >
> > > Yes. I should have mentioned so the lspci is there exactly to trigger
> > > runtime resume of the topology. I was hoping the PCIe links get
> > > re-established properly then.
> > >
> > > Can you do so that you:
> > >
> > > 1. Plug in the dock.
> > > 2. Plug in the other storage to the dock.
> > > 3. Block runtime PM from the PCIe Downstream Port that should lead to the
> > >    second storage device PCIe Upstream Port
> > >
> > >  # echo on > /sys/bus/pci/devices/DEVICE/power/control
> > >
> > > 4. Connect the second storage device and enable PCIe tunnel.
> > >
> > > Does that make it work each time?
> > Yes, follow the steps makes it work.
> > 
> >    echo on | sudo tee /sys/bus/pci/devices/*/*/power/control
> > 
> > Re-plug the dock, need to disable the runpm again.
> 
> But can you just block it from the PCIe Downstream Port that leads to the
> "non-working" storage before you enable PCIe tunnel? Not for all the
> devices.
> 
> (let me know if you want help locating the correct device).
> 
> Does it still work?

(+Gil)

There is also one patch that fixes the driver to follow more closely the CM
guide and that's related to the PCIe tunneling and may actually explain the
issue you see:

  https://lore.kernel.org/linux-usb/20260127094953.GF2275908@black.igk.intel.com/

Note it only does that for USB4 routers so you may need to tune that so
that it skips that check but there is complication because IIRC LTTSM bits
do not match the USB4 ones. One thing to try is to just check the USB4 PCIe
adapter side that it is in detect.

Second thing to try is to disable PCIe ASPM L1. We can do that from CM side
like we do already in tb_switch_pcie_l1_enable(). If possible you can try
so that you disable it from the BIOS (but don't use the pcie_aspm=  command
lne parameter).