New: Barlow Ridge TB5 tunneled xHCI (8086:5782) runtime-suspends to D3hot and fails to wake on USB-C device connect (Lenovo Legion 9 18IAX10)
https://bugzilla.kernel.org/show_bug.cgi?id=221655
Bug ID: 221655
Summary: Barlow Ridge TB5 tunneled xHCI (8086:5782)
runtime-suspends to D3hot and fails to wake on USB-C
device connect (Lenovo Legion 9 18IAX10)
Product: Drivers
Version: 2.5
Kernel Version: 7.0.12-201.fc44.x86_64
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: USB
Assignee: [email protected]
Reporter: [email protected]
Regression: NoCreated attachment 310324
--> https://bugzilla.kernel.org/attachment.cgi?id=310324&action=edit
a ZIP with all the relevant logs
== Summary ==
On a Lenovo Legion 9 18IAX10 (Core Ultra 9 275HX; Arrow Lake-HX + Intel JHL9580 "Barlow Ridge" Thunderbolt 5 host), USB devices plugged into the two LEFT-side USB-C ports never enumerate. These ports are served by the Barlow Ridge tunneled xHCI at PCI 0000:2d:00.0 (8086:5782).
Root cause: that xHCI is runtime-suspended to D3hot (power/control=auto, runtime_status=suspended). A USB-C device-connect event does NOT generate a wake to bring the controller back to D0, so the device never enumerates even though the Type-C layer registers the partner (data_role=host, power_role= source, partner present).
Forcing the controller to D0 makes the port work perfectly and immediately:
echo on > /sys/bus/pci/devices/0000:2d:00.0/power/control
After this, the device enumerates (e.g. SanDisk Extreme Pro Portable SSD as UAS at 20000M on bus 2). Reading PCI config space (lspci -vvv on 2d:00.0) also wakes it as a side effect and triggers enumeration. So hardware and driver paths are fine -- this is purely a runtime-PM wake-on-connect failure.
== Hardware ==
- Laptop: Lenovo Legion 9 18IAX10 (DMI product 83EY), BIOS RZCN48WW (latest)
- CPU: Intel Core Ultra 9 275HX
- TB5 host NHI: Intel JHL9580 TB5 NHI [Barlow Ridge] 8086:5781 (thunderbolt)
- Affected xHCI: Intel JHL9580 TB5 USB Controller 8086:5782 (xhci_hcd) -> buses 1 & 2 (LEFT USB-C)
- Working xHCI (PCH): Intel 800 Series PCH USB 3.1 xHCI 8086:7f6e -> buses 3 & 4 (RIGHT USB-C, internal)
- PD/UCSI: ucsi_acpi USBC000:00
== Kernel / boot ==
7.0.12-201.fc44.x86_64 (Fedora 44 base). Relevant kargs: pcie_aspm=off, intel_iommu=on, iommu=pt. Note pcie_aspm=off is already set, so this is runtime-PM (D3), not an ASPM issue.
== Steps to reproduce ==
1. Boot. Leave the 8086:5782 xHCI at default power/control=auto.
2. After idle, it enters D3hot / runtime_status=suspended.
3. Plug a USB device into a LEFT USB-C port.
4. Device does NOT enumerate; buses 1 & 2 stay empty. Type-C partner IS registered (/sys/class/typec/portN-partner present, data_role=host).
5. Run: echo on > /sys/bus/pci/devices/0000:2d:00.0/power/control -> controller returns to D0, device enumerates immediately.
== Evidence (device plugged into LEFT port, not detected) ==
/sys/bus/pci/devices/0000:2d:00.0/power_state -> D3hot
/sys/bus/pci/devices/0000:2d:00.0/power/control -> auto
/sys/bus/pci/devices/0000:2d:00.0/power/runtime_status -> suspended
/sys/class/typec/port1/data_role -> [host] /sys/class/typec/port1/power_role -> [source] /sys/class/typec/port1-partner/ -> present
lsusb -t: buses 1 (480M) and 2 (20000M) of 0000:2d:00.0 EMPTY
== After "echo on" (same device, same port) ==
power_state -> D0
lsusb -t: Bus 002 Port 002: Dev 003, Class=Mass Storage, Driver=uas,
20000M/x2
== Notes ==
- Recurring "ucsi_acpi USBC000:00: GET_CURRENT_CAM command failed" is present but appears unrelated to enumeration (occurs independently; ports work once the controller is in D0).
- Blacklisting ucsi_acpi is NOT a viable workaround on this platform: it removes
/sys/class/typec entirely (the EC does not take over).
- BIOS RZCN48WW (latest) does not fix it.
== Workaround ==
udev rule pinning power/control=on for 8086:5782 keeps the controller in D0 and makes the LEFT USB-C ports reliably enumerate devices (at an idle-power cost).
== Request ==
The tunneled Barlow Ridge xHCI should wake from D3 on a USB-C connect event. Is a PME/wake enablement or a runtime-PM quirk for 8086:5782 appropriate?
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221655] Barlow Ridge TB5 tunneled xHCI (8086:5782) runtime-suspends to D3hot and fails to wake on USB-C device connect (Lenovo Legion 9 18IAX10)
https://bugzilla.kernel.org/show_bug.cgi?id=221655
Mika Westerberg ([email protected]) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected] | |.com
--- Comment #1 from Mika Westerberg ([email protected]) --- Please remove pcie_aspm=off from the command line. That does more than just disables ASPM (effectively it disables native PCIe). If the problem still reproduces please attach full dmesg with "thunderbolt.dyndbg=+p" in the kernel command line.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221655] Barlow Ridge TB5 tunneled xHCI (8086:5782) runtime-suspends to D3hot and fails to wake on USB-C device connect (Lenovo Legion 9 18IAX10)
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221655
--- Comment #2 from [email protected] ---
(In reply to Mika Westerberg from comment #1)
Quoted 4 lines
Please remove pcie_aspm=off from the command line. That does more than just disables ASPM (effectively it disables native PCIe). If the problem still reproduces please attach full dmesg with "thunderbolt.dyndbg=+p" in the kernel command line.
removing pcie_aspm=off, my apologies for the bad ticket. please delete this.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221655] Barlow Ridge TB5 tunneled xHCI (8086:5782) runtime-suspends to D3hot and fails to wake on USB-C device connect (Lenovo Legion 9 18IAX10)
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221655
--- Comment #3 from [email protected] ---
(In reply to Mika Westerberg from comment #1)
Quoted 4 lines
Please remove pcie_aspm=off from the command line. That does more than just disables ASPM (effectively it disables native PCIe). If the problem still reproduces please attach full dmesg with "thunderbolt.dyndbg=+p" in the kernel command line.
(In reply to vuo9gt37 from comment #2)
Quoted 7 lines
(In reply to Mika Westerberg from comment #1)
Quoted 4 lines
Please remove pcie_aspm=off from the command line. That does more than just disables ASPM (effectively it disables native PCIe). If the problem still reproduces please attach full dmesg with "thunderbolt.dyndbg=+p" in the kernel command line.
removing pcie_aspm=off, my apologies for the bad ticket. please delete this.
removing pcie_aspm=off helped I wanted to say
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221655] Barlow Ridge TB5 tunneled xHCI (8086:5782) runtime-suspends to D3hot and fails to wake on USB-C device connect (Lenovo Legion 9 18IAX10)
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221655
Andy Shevchenko ([email protected]) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |[email protected]
Resolution|--- |INVALID--- Comment #4 from Andy Shevchenko ([email protected]) --- Closed based on the comment #3.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.