On Mon, Sep 25, 2023 at 04:19:30PM +0200, Lukas Wunner wrote: > On Mon, Sep 25, 2023 at 08:48:41AM -0500, Bjorn Helgaas wrote: > > Now pciehp thinks the slot is occupied and the link is up, so we > > re-enumerate the hierarchy. Is this because thunderbolt did something > > to 06:00.0 that made the link from 05:01.0 come up? > > PCIe TLPs are encapsulated into Thunderbolt packets and transmitted > alongside DisplayPort and other data over the same physical link. > > For this to work, PCIe tunnels need to be set up between the Thunderbolt > host controller and attached devices. Once a tunnel is established, > the PCIe link magically goes up and TLPs can be transmitted. > > There are two ways to establish those tunnels: > > 1/ By a firmware in the Thunderbolt host controller. > (firmware or "internal" connection manager, drivers/thunderbolt/icm.c) > > 2/ Natively by the kernel. > (software connection manager) > > I'm assuming that the laptop in question exclusively uses the firmware > connection manager, hence the kernel is reliant on that firmware to > establish tunnels and can't really do anything if it fails to do so. Thanks for the background; that improves my meager understanding a lot. Since this seems to be a firmware issue, it does sound like this laptop uses a firmware connection manager. But there still seems to be some kernel connection because pre-e8b908146d44, the link came up in <5 seconds, and after the minor e8b908146d44 change, it takes >60 seconds. I'm kind of at a loss here because I don't have a clear path forward. What I'm hearing is that the real fix is a firmware update or a BIOS setting change (Thunderbolt "user" instead of "secure" mode). That is problematic for users, who will think resume got broken and they don't know how to fix it. It's problematic for me, because it *looks* like a PCI issue and a PCI change exposed it, so I'll have to deal with the reports. Bjorn
