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

[Mika Westerberg <mika.westerberg@linux.intel.com>]

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?