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

[Mika Westerberg]

[+Cc AMD folks]

On Thu, Feb 12, 2026 at 08:07:54AM +0100, Mika Westerberg wrote:
> On Thu, Feb 12, 2026 at 12:16:03PM +0800, AceLan Kao wrote:
> > > > Disable runpm on 62:02.0, then we have 83:00.0 and its downstream port
> > > > 84:01.0 and 85:00.0, and then the tbt storage is recognized.
> > Got troubles with mutt, my reply got rejected :(
> > 
> > Using gmail and copy/paste the content below again.
> 
> Okay.
> 
> > > Okay that means there is nothing wrong with the PCIe tunnel itself it's
> > > just that the PCIe side either does not get the PME or does not see that
> > > the PCIe link becomes active (e.g the PCIe Downstream Port runtime suspends
> > > itself before the link status changes).
> > >
> > > PME work so that there is wake first on Intel it's GPE that wakes up the
> > > root port and then PCIe stack wakes up devices and then the PME message is
> > > sent to the root complex.
> > >
> > > If you do this on Intel host do you see the same?
> > Intel host exhibits another symptom, I think the root cause is different.
> > 
> > Plug in the dock, and then plug in the tbt storage to the dock one by
> > one, both storage can be detected.
> > 
> > Plug both tbt storage to the dock, and then plug in the dock to the
> > machine, only one tbt storage appears. In rare chance, both tbt
> > storages show up, but most of the time, only one tbt storage is detected.
> > In this case, none of disable runpm, rescan, or lspci work. So, it's
> > most likely another issue.
> 
> By "detected" you mean the TB device is not detected on TB bus? Or it is
> detected on TB bus but creating PCIe tunnel does not make the content
> visible on PCIe bus?
> 
> You can check this from dmesg, the driver logs if it sees the plug event.
> Or run tblist (from tbtools) and see if the device is listed.
> 
> I suspect former and in that case it is likely a PD/retimer related issue
> rather than software. I see these once in a while especially with new
> hardware where the PD firmare is not yet stabilized. If there is TB/USB4
> link then all is working from TB/USB4 perspective.
> 
> > > Right at that point the PCIe Downstream Port probably is already back
> > > runtime suspended.
> > >
> > > Here you could try this:
> > >
> > > # echo 250 > /sys/bus/pci/devices/0000:62:02.0/power/autosuspend_delay
> > No luck, I enlarged the number to 1000, but still can't recognize the
> > second tbt storage.
> 
> What about -1?
> 
> That's effectively same as blocking runtime PM completely so should work.
> 
> > I tried to wake up the PCIe ports in the beginning of tb_tunnel_pci() and
> > it works.
> > 
> > +       pdev = pci_get_domain_bus_and_slot(0, 0x62, PCI_DEVFN(0x02, 0));
> > +       if (pdev) {
> > +               if (pdev->dev.power.runtime_status == RPM_SUSPENDED)
> > +                       pm_runtime_get_sync(&pdev->dev);
> > +               pci_dev_put(pdev);
> > +       }
> > 
> > But I can't find a generic way to get the bus and slot number, and
> > would you consider this a feasible approach?
> 
> No I don't want any (more) PCI related hacks in the driver.
> 
> This is not a TB issue, it's a PCIe issue. I suspect it has something to do
> with handling PME/GPE on AMD side. Essentially when runtime PM is blocked
> the PCIe hotplug driver notices the tunnel just fine. When it is runtime
> suspended (e.g D3) it should send PME to the root complex that the brings
> the topology up so that the hotplug driver can detect the presence but this
> does not seem to happen.
> 
> If you enable dynamic debugging of pciehp, do you see anything happening
> when you create the second PCIe tunnel? I suspect not.