Re: [BUG] PCI/USB4: AMD Phoenix 1022:14ef runtime suspend prevents JHL9480 downstream enumeration

[Mario Limonciello <mario.limonciello@amd.com>]

> -----Original Message-----
> From: Freeman Z <SHD-ISAC@outlook.com>
> Sent: Tuesday, September 22, 2026 11:41 AM
> To: Limonciello, Mario <Mario.Limonciello@amd.com>; Mika Westerberg <mika.westerberg@linux.intel.com>
> Cc: linux-pci@vger.kernel.org; linux-usb@vger.kernel.org; bhelgaas@google.com; westeri@kernel.org; andreas.noever@gmail.com; YehezkelShB@gmail.com; rafael@kernel.org; linux-pm@vger.kernel.org; S, Sanath <Sanath.S@amd.com>; Natikar, Basavaraj <Basavaraj.Natikar@amd.com>; Kovacs, Alexander <Alexander.Kovacs@amd.com>
> Subject: Re: [BUG] PCI/USB4: AMD Phoenix 1022:14ef runtime suspend prevents JHL9480 downstream enumeration
> 
> [You don't often get email from shd-isac@outlook.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> 
> 
> Hi Mika, Mario,
> 
> I reproduced the failure following the requested sequence on my installed CachyOS system with kernel 7.2.6-1-cachyos and thunderbolt.dyndbg=+p.
> 
> For this trace the dock was physically disconnected at boot. I did not run lspci before or during the reproduction.
> 
> Before plugging the dock:
> 
>      0000:00:04.1
>        power/control        = auto
>        power/runtime_status = suspended
>        power_state          = D3cold
> 
>      0000:6b:00.6
>        power/control        = auto
>        power/runtime_status = suspended
>        power_state          = D3cold
> 
> After plugging the Kensington SD5000T5 and waiting about 15 seconds:
> 
>      0000:00:04.1
>        power/control        = auto
>        power/runtime_status = suspended
>        power_state          = D3cold
> 
>      0000:09:00.0
>        missing
> 
>      0000:6b:00.6
>        power/control        = auto
>        power/runtime_status = active
>        power_state          = D0
> 
> The Thunderbolt dynamic debug log shows the NHI/control channel waking and the USB4 fabric being configured. In particular:
> 
>      thunderbolt 0000:6b:00.6: control channel starting...
>      thunderbolt 0000:6b:00.6: 0: resuming switch
>      thunderbolt 0000:6b:00.6: 0:2: is connected, link is up (state: 2)
>      thunderbolt 0-2: Kensington SD5000T5 EQ Thunderbolt 5 Dock
>      thunderbolt 0000:6b:00.6: 0:5 <-> 2:9 (PCI): activating
>      thunderbolt 0000:6b:00.6: PCIe Down path activation complete
>      thunderbolt 0000:6b:00.6: PCIe Up path activation complete
> 
> However, I do not see a PME message corresponding to the dock insertion.
> The PME messages in the full dmesg are the early-boot
> "PME: Signaling with IRQ ..." initialization messages.
> 
> So in this reproduction, the NHI at 0000:6b:00.6 wakes from D3cold to D0 and the Thunderbolt driver successfully programs the PCIe tunnel in the
> USB4 fabric, but the AMD 1022:14ef PCIe root port/tunnel at 0000:00:04.1 remains in D3cold and the downstream 0000:09:00.0 hierarchy never appears.
> 
> I attached the full dmesg captured after the dock plug, plus the small before/after state files. I redacted only unrelated local network identifiers, the hostname, and filesystem/LUKS UUIDs; the Thunderbolt debug data and device UIDs are otherwise unchanged.
> 
> This particular dynamic-debug trace was collected on CachyOS rather than the Arch stock kernel used for my earlier reproduction.
> 
It sure sounds like a PME doesn't deliver properly for some reason.

I suppose that while in this state - if you ran lspci the root port at 
0000:00:04.1 exits D3cold and 0000:09:00.0 shows up, right?

Does the PME show up in the logs after you've done this?

Any chance you can easily check Ubuntu 26.04.1 live media?  There is a 
7.0 based kernel there, and I would like to know if this regressed from 
that.