On Mon, Sep 25, 2023 at 07:59:28AM +0300, Mika Westerberg wrote: > On Sun, Sep 24, 2023 at 03:18:00PM -0500, Bjorn Helgaas wrote: > ... > > So is there some user-level software that runs between the removal and > > re-enumeration? Something that authorizes the 07:00.0 Upstream Port? > > No. > > They get "authorized" upon plug by boltd based on user decision and > after that the firmware should keep them authorized as long as the > device is connected, including also resume. I'm trying to understand the events involved in bringing that link up. When we resume, evidently the link is not up, and it doesn't come up by itself no matter how long we wait. From the log at [1], [ 0.494521] pci 0000:05:01.0: PCI bridge to [bus 07-3b] The hierarchy that's a problem is bus 07-3b. [ 117.485355] ACPI: PM: Preparing to enter system sleep state S3 Suspended. [ 117.528216] ACPI: PM: Waking up from system sleep state S3 [ 117.606664] ACPI: EC: interrupt unblocked [ 118.915870] thunderbolt 0000:06:00.0: control channel starting... Resuming. [ 118.985530] pcieport 0000:05:01.0: Data Link Layer Link Active not set in 1000 msec [ 190.090902] pcieport 0000:05:01.0: pciehp: Slot(1): Card not present [ 190.376024] pci_bus 0000:09: busn_res: [bus 09] is released [ 190.376089] pci_bus 0000:0a: busn_res: [bus 0a] is released [ 190.376168] pci_bus 0000:0b: busn_res: [bus 0b] is released [ 190.376850] pci_bus 0000:0c: busn_res: [bus 0c] is released [ 190.376883] pci_bus 0000:0d: busn_res: [bus 0d-3b] is released [ 190.376912] pci_bus 0000:08: busn_res: [bus 08-3b] is released Link from 05:01.0 didn't come up, so pciehp thinks the "slot" is empty and we removed the problem hierarchy (bus 07-3b). [ 191.754347] thunderbolt 0000:06:00.0: 1: DROM version: 1 [ 191.762638] thunderbolt 0-1: new device found, vendor=0x108 device=0x1630 [ 191.762641] thunderbolt 0-1: Lenovo ThinkPad Thunderbolt 3 Dock [ 191.943506] pcieport 0000:05:01.0: pciehp: Slot(1): Card present [ 191.943518] pcieport 0000:05:01.0: pciehp: Slot(1): Link Up [ 192.074593] pci 0000:07:00.0: [8086:15d3] type 01 class 0x060400 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? Does Windows suffer from the same 60+ second resume time on this platform? Bjorn [1] https://bugzilla-attachments.redhat.com/attachment.cgi?id=1984803
