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

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

On 9/23/26 07:26, Kovacs, Alexander wrote:
> AMD General
> 
> Freeman Z,
> 
> And this same setup still exhibits the failed behavior with a mainline 7.2 kernel?
> 
> Replied or Forwarded By:
> Alex Kovacs
> 845-625-4422
> akovacs@amd.com
> 
> -----Original Message-----
> From: Freeman Z <SHD-ISAC@outlook.com>
> Sent: Wednesday, September 23, 2026 6:52 AM
> To: Limonciello, Mario <Mario.Limonciello@amd.com>; Kovacs, Alexander <Alexander.Kovacs@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>; Martinez, Juan <Juan.Martinez@amd.com>
> Subject: Re: [BUG] PCI/USB4: AMD Phoenix 1022:14ef runtime suspend prevents JHL9480 downstream enumeration
> 
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> 
> 
> Hi Mario, Mika and Alex,
> 
> I tested the Kensington SD5000T5 dock again by using Ubuntu 26.04.1 Live with kernel 7.0.0-30-generic and thunderbolt.dyndbg=+p. The dock was disconnected at boot, and I did not run lspci before the hotplug log and power states had been saved.
> 
> In this Ubuntu run the PCIe/USB enumeration worked without any workaround:
> 
>    426.716: USB4 dock connection detected (host port 0:2, link up)
>    426.753: Kensington SD5000T5 discovered
>    428.410: PCIe Down path activation complete
>    428.411: PCIe Up path activation complete
>    429.025: pcieport 0000:00:04.1 reports Card present / Link Up
>    429.026: downstream 0000:09:00.0 (8086:5786) enumerated
> 
> After the dock had connected, but *before* running lspci, the sysfs states were:
> 
>    0000:00:04.1  power/control=auto; runtime_status=active; power_state=D0
>    0000:09:00.0  present
>    0000:6b:00.6  runtime_status=active; power_state=D0
> 
> The downstream USB devices and dock Ethernet also enumerated. I then ran lspci once: 0000:00:04.1 remained active/D0, 0000:09:00.0 remained present. Thus this run cannot show an lspci-triggered wakeup or a resulting PME event: it was already working.
> In my previous failing CachyOS runs, invoking lspci could wake 00:04.1 and make 09:00.0 appear. I do not see an explicit PME delivery message at hotplug in the Ubuntu dmesg.
> 
> The external display did still flicker. The Ubuntu log includes one DP tunnel DPRX read timeout at ~431.188s, followed by a completed capability read at ~431.239s, I do not know if it's related.
> 
> Attached are the full Ubuntu dmesg after/before hotplug and the state files.
> Unrelated USB serial numbers and network interface MAC addresses are redacted.
> 
> Thanks,
> Freeman
> 
OK, so IMV either:

A) We Have a regression from mainline 7.0 to mainline 7.2.
B) Cachy OS has a patch that is causing the issue.
C) There is a patch Ubuntu's distro kernel that is helping.

I think we need to narrow down which of those is the case.

Can you please check out and build a mainline 7.0 tag on your Cachy and 
see if you can reproduce?

If you can't reproduce; check out a mainline 7.2 tag and see if you can.