[Bug 221655] 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)

[Bug 221655] 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)

[bugzilla-daemon]

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: drivers_usb@kernel-bugs.kernel.org
          Reporter: vuo9gt37@addy.io
        Regression: No

Created 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?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.