[Bug 220904] New: [BUG] ucsi_acpi: USB 3.0 SuperSpeed not negotiated on USB-C hot-plug

[Bug 220904] New: [BUG] ucsi_acpi: USB 3.0 SuperSpeed not negotiated on USB-C hot-plug

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220904

            Bug ID: 220904
           Summary: [BUG] ucsi_acpi: USB 3.0 SuperSpeed not negotiated on
                    USB-C hot-plug
           Product: Drivers
           Version: 2.5
    Kernel Version: 6.18.2-zen2-1-zen
          Hardware: Intel
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: USB
          Assignee: drivers_usb@kernel-bugs.kernel.org
          Reporter: thomas@jetzinger.com
        Regression: No

Created attachment 309074
  --> https://bugzilla.kernel.org/attachment.cgi?id=309074&action=edit
Kernel .config for 6.18.2-zen2-1-zen (Arch Linux zen kernel)

[1.] One line summary of the problem:
USB-C dock USB 3.0 devices fail to enumerate on hot-plug (only USB 2.0 works);
works at boot and on Windows

[2.] Full description of the problem/report:
On ThinkPad X1 Carbon Gen 11 with ThinkPad USB-C Dock Gen2 (40AS), USB 3.0
devices
(including ethernet adapter) do not enumerate when hot-plugging the dock. Only
USB 2.0
devices (audio, HID) enumerate. The same dock works correctly when connected at
boot,
and hot-plug works correctly on Windows 11, indicating this is a Linux driver
issue.

Detailed analysis:
- At boot: Dock connects via Thunderbolt 4 controller (0000:00:0d.0), USB 3.0
devices
  enumerate on Bus 2 (20Gbps SuperSpeed), ethernet (r8152) works
- On hot-plug: Thunderbolt USB buses report "root hub lost power or was reset"
but
  dock falls back to internal xHCI controller (0000:00:14.0) Bus 3 at USB 2.0
speeds only

The typec subsystem shows the issue:
- At boot: dock connects as port0-partner, port0 has USB connector bindings
  (usb2-port1, usb3-port1, usb4_port1)
- On hot-plug: dock may connect as port1-partner, but port1 has NO USB
connector
  bindings in ACPI (possible BIOS deficiency)
- Even when hot-plugging to port0: SuperSpeed lanes are not negotiated, only
USB 2.0

dmesg on hot-plug shows:
  usb usb1: root hub lost power or was reset
  usb usb2: root hub lost power or was reset
  usb 3-1: new high-speed USB device  <-- Only USB 2.0 enumeration, no
SuperSpeed

The UCSI driver does not appear to trigger USB 3.0 SuperSpeed lane
renegotiation
on partner connect. No typec connector binding messages appear on hot-plug.

Tested workarounds that do NOT fix the issue:
- xHCI controller unbind/rebind (echo 0000:00:0d.0 >
/sys/bus/pci/drivers/xhci_hcd/unbind)
- UCSI driver reload (modprobe -r ucsi_acpi && modprobe ucsi_acpi)
- Using either physical USB-C port

Working workaround: Boot with dock already connected.

[3.] Keywords (i.e., modules, networking, kernel):
ucsi_acpi, typec_ucsi, typec, USB-C, Thunderbolt, hot-plug, SuperSpeed,
xhci_hcd

[4.] Kernel information
[4.1.] Kernel version (from /proc/version):
Linux version 6.18.2-zen2-1-zen (linux-zen@archlinux) (gcc (GCC) 15.2.1
20251112, GNU ld (GNU Binutils) 2.45.1) #1 ZEN SMP PREEMPT_DYNAMIC Thu, 18 Dec
2025 18:00:58 +0000

[4.2.] Kernel .config file:
[Attached separately as kernel-config.txt]

[5.] Most recent kernel version which did not have the bug:
Unknown

[6.] Output of Oops.. message (if applicable) with symbolic information:
No kernel oops. The only relevant messages are:
  usb usb1: root hub lost power or was reset
  usb usb2: root hub lost power or was reset
And then USB 2.0-only enumeration on Bus 3 instead of SuperSpeed on Bus 2.

[7.] A small shell script or example program which triggers the problem (if
possible):
# Reproduce steps:
# 1. Boot system WITHOUT dock connected
# 2. Log in to desktop
# 3. Connect ThinkPad USB-C Dock Gen2 via USB-C cable
# 4. Check USB topology:
lsusb -t
# Expected: Dock on Bus 2 with 20000M devices
# Actual: Dock on Bus 3 with 480M devices only, Bus 2 empty

# Diagnostic commands:
ls /sys/class/typec/  # Shows port0-partner or port1-partner
ls /sys/class/typec/port0/usb*  # port0 has bindings
ls /sys/class/typec/port1/usb*  # port1 has NO bindings (ACPI issue?)
ip link show | grep enp  # Ethernet interface missing on hot-plug

[8.] Environment:
Hardware: Lenovo ThinkPad X1 Carbon Gen 11 (21HMCTO1WW)
BIOS: N3XET63W (1.38) dated 2025-10-08
Dock: ThinkPad USB-C Dock Gen2 (40AS), firmware 5.05.00
OS: Arch Linux (rolling)
Desktop: Hyprland (Wayland)

USB Controllers:
- 0000:00:0d.0: Intel Thunderbolt 4 (USB 3.2, buses 1+2)
- 0000:00:14.0: Intel Alder Lake xHCI (USB 3.1, buses 3+4)

ACPI USB-C controller: USBC000:00 with two ports (device:a2=port0,
device:a3=port1)

Related bug reports:
- Red Hat Bugzilla #2248484: UCSI driver bug
- Arch Linux Forum: https://bbs.archlinux.org/viewtopic.php?id=308325

-- 
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 220904] [BUG] ucsi_acpi: USB 3.0 SuperSpeed not negotiated on USB-C hot-plug

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220904

Heikki Krogerus (heikki.krogerus@linux.intel.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mika.westerberg@linux.intel
                   |                            |.com

--- Comment #1 from Heikki Krogerus (heikki.krogerus@linux.intel.com) ---
There are no logs here so I'm not completely sure what's going on, but the
symptoms sound very similar to a know issue with USB4/TBT where the PCI devices
fail to enumerate after resume.

This probable is not a Type-C issue, because this is UCSI system, and UCSI is
just a status interface. But you can always confirm that by disabling the ucsi
drivers before reproducing the issues.

-- 
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 220904] [BUG] ucsi_acpi: USB 3.0 SuperSpeed not negotiated on USB-C hot-plug

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220904

--- Comment #2 from Thomas Jetzinger (thomas@jetzinger.com) ---
Created attachment 309097
  --> https://bugzilla.kernel.org/attachment.cgi?id=309097&action=edit
Disabling UCSI does NOT resolve the issue

Hi Heikki,

Here are the logs from two test scenarios. Both tests confirm the issue
persists regardless of UCSI driver status.

## System Info
 - ThinkPad X1 Carbon Gen 11 (21HMCTO1WW)
 - BIOS: N3XET63W (1.38)
 - Kernel: 6.18.2-zen2-1-zen (custom build, also tested on stock 6.12)
 - Dock: ThinkPad USB-C Dock Gen2 (40AS)

## Test 1: UCSI Enabled (Normal Configuration)

**Boot with dock connected:** USB 3.0 works
 - Ethernet (17ef:a387) on Bus 002 @ 5000M
 - USB3.1 Hub (17ef:a391) on Bus 002 @ 10000M

**After disconnect + reconnect:** USB 3.0 FAILS
 - Only USB 2.0 devices enumerate (480M on Bus 003)
 - Bus 002 (20Gbps SuperSpeed) is completely empty
 - Ethernet and USB 3.0 hub missing

Key log pattern:
 usb usb1: root hub lost power or was reset
 usb usb2: root hub lost power or was reset
 usb 3-3: new high-speed USB device number 14 using xhci_hcd  ← USB 2.0 only

## Test 2: UCSI Disabled (blacklist ucsi_acpi)

**Boot with dock connected:** USB 3.0 works (same as Test 1)

**After disconnect + reconnect:** USB 3.0 STILL FAILS
 - Identical failure pattern to Test 1
 - Same "root hub lost power or was reset" messages
 - Only high-speed (USB 2.0) enumeration

## Conclusion

Disabling UCSI does NOT resolve the issue. The problem appears to be in the
USB-C/Thunderbolt physical layer negotiation, not the UCSI driver. The repeated
"root hub lost power or was reset" messages on usb1/usb2 (Thunderbolt/USB4
buses) during hot-plug suggest the xHCI controller is being reset but failing
to re-enumerate SuperSpeed devices.

Full logs attached:
 - bug-220904-test1-ucsi-enabled.txt (Test 1 with UCSI)
 - bug-220904-test2-ucsi-disabled.txt (Test 2 without UCSI)

-- 
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 220904] [BUG] ucsi_acpi: USB 3.0 SuperSpeed not negotiated on USB-C hot-plug

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220904

--- Comment #3 from Mika Westerberg (mika.westerberg@linux.intel.com) ---
Can you attach full dmesg of the repro with "thunderbolt.dyndbg=+p" in the
kernel command line?

-- 
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 220904] [BUG] ucsi_acpi: USB 3.0 SuperSpeed not negotiated on USB-C hot-plug

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220904

--- Comment #4 from Thomas Jetzinger (thomas@jetzinger.com) ---
Created attachment 309100
  --> https://bugzilla.kernel.org/attachment.cgi?id=309100&action=edit
full dmesg with thunderbolt.dyndbg=+p

Kernel: 6.18.2-arch2-1

Repro: Boot with dock → ethernet works. Unplug/replug dock → ethernet gone.

Key logs:
- Boot: cdc_ether registered at usb-0000:00:0d.0-3.1
- Unplug [178.9s]: r8152-cfgselector disconnect, cdc_ether unregister
- Replug [189.1s]: Thunderbolt resumed, USB hubs + HID + audio re-enumerated
- Ethernet (2-3.1) never re-registered

Note: "r8152-cfgselector: Unknown version 0x0000" at boot - driver falls back
to cdc_ether.

-- 
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 220904] [BUG] ucsi_acpi: USB 3.0 SuperSpeed not negotiated on USB-C hot-plug

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220904

--- Comment #5 from Mika Westerberg (mika.westerberg@linux.intel.com) ---
Okay thanks! This dock is not TB/USB4 so not related to USB4 link. I wonder if
you tried to disable runtime PM from the 0d.0 xHCI?

# echo on > /sys/bus/pci/devices/0000:00:0d.0/power/control

-- 
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 220904] [BUG] ucsi_acpi: USB 3.0 SuperSpeed not negotiated on USB-C hot-plug

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220904

--- Comment #6 from Thomas Jetzinger (thomas@jetzinger.com) ---
Thanks Mika, your xHCI runtime PM suggestion was correct.

Root cause: /sys/bus/pci/devices/0000:00:0d.0/power/control was auto.

Fix: Removed xhci_hcd from TLP's RUNTIME_PM_DRIVER_DENYLIST so TLP sets xHCI to
on on AC.

Result: Hot-plug works. Dock enumerates on USB 3.0 with ethernet at 5000M.

Note: TLP ships with xhci_hcd in the default denylist (defaults.conf), leaving
xHCI at kernel default (auto).

-- 
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 220904] [BUG] ucsi_acpi: USB 3.0 SuperSpeed not negotiated on USB-C hot-plug

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220904

--- Comment #7 from Mika Westerberg (mika.westerberg@linux.intel.com) ---
These ports should wake up on plug. Summoning Mathias if he has any ideas why
it is not working.

-- 
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 220904] [BUG] ucsi_acpi: USB 3.0 SuperSpeed not negotiated on USB-C hot-plug

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220904

--- Comment #8 from Thomas Jetzinger (thomas@jetzinger.com) ---
After further testing, I can confirm that the USB ports also fail to recover
after suspend/resume cycles. Will share logs later.

-- 
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 220904] [BUG] ucsi_acpi: USB 3.0 SuperSpeed not negotiated on USB-C hot-plug

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220904

--- Comment #9 from Mathias Nyman (mathias.nyman@linux.intel.com) ---
The log entries about 'root hub lost power or was reset' means
xHC controller failed to resume properly, and will be reset and re-initialized.

There are no other log entries after this from that xHC, so it's possible
there is something failing during re-initialization.

could you enable xhci and usb core dynamic debug and send a new dmesg of a
failing case:

echo 'module xhci_hcd =p' >/sys/kernel/debug/dynamic_debug/control
echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control

-- 
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 220904] [BUG] ucsi_acpi: USB 3.0 SuperSpeed not negotiated on USB-C hot-plug

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220904

--- Comment #10 from Thomas Jetzinger (thomas@jetzinger.com) ---
Created attachment 309154
  --> https://bugzilla.kernel.org/attachment.cgi?id=309154&action=edit
Tested with dynamic debug enabled. s2idle suspend/resume issue:

After resume, Thunderbolt xHCI (00:0d.0) reports "root hub lost power":

  usb usb1: root hub lost power or was reset
  usb usb2: root hub lost power or was reset
  usb 2-3: Waited 2000ms for CONNECT
  usb 2-3: can't resume, status -19
  usb 2-3: USB disconnect
  r8152-cfgselector 2-3.1: USB disconnect

All USB3 devices on Bus 2 disconnect and don't recover. Requires reboot.

Full dmesg with xhci_hcd and usbcore debug attached.

Kernel: 6.18.3-arch1-1

-- 
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 220904] [BUG] ucsi_acpi: USB 3.0 SuperSpeed not negotiated on USB-C hot-plug

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220904

--- Comment #11 from Mathias Nyman (mathias.nyman@linux.intel.com) ---
The usb device at 2-3 is set to U3 suspended state before the xhci host at
0000:00:0d.0 suspends to D3cold. 

xHCI host controller is then reset and reinitialized during resume.
This should only be done during restore phase (resume from s4 hibernate) or if
there an error in resume. Not in normal s2idle resume. 
Logs don't show any error during resume.

This host controller reset may trigger a warm port reset on USB3 ports.
The device at 2-3 is probably unaware of the host controller reset, and
remains in suspended u3 state until a warm reset is suddenly issued.

Right after we get the host re-initialuzed and up and running we read the port
status registers, and see that port 2-3 is stuck with "reset asserted" bit set,
and remain this way.

First we should figure out why host is reset during resumed for a normal s2idle
suspend/resume.
If the host reset is needed theb we might need to work around this and try
disabling/power off ports before resetting the host in resume.

would it be possible for you to try some testpatches on this setup if I write
them?

-- 
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 220904] [BUG] ucsi_acpi: USB 3.0 SuperSpeed not negotiated on USB-C hot-plug

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220904

--- Comment #12 from Thomas Jetzinger (thomas@jetzinger.com) ---
Thanks for the analysis. Happy to test any patches you have.

-- 
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 220904] [BUG] ucsi_acpi: USB 3.0 SuperSpeed not negotiated on USB-C hot-plug

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220904

--- Comment #13 from Mathias Nyman (mathias.nyman@linux.intel.com) ---
I was able to recreate this with a USB-C hub and forced xHC reset in resume.

So far no simple solution to solve this. I tried disabling the port in resume
path before host reset, tried toggling port power before host reset, but
nothing helped.

So looks like we need to focus on why your Intel xHC at 0000:00:0d.0 is
reset in resume, and avoid that.

Your log shows you have the  XHCI_RESET_ON_RESUME quirk BIT(7) set, which
explains the reset.

[1.901865] xhci_hcd 0000:00:0d.0: hcc params 0x20007fc1 hci version 0x120
quirks 0x0000000200009890

Intel xHC hosts don't normally have this set. Looks like its forced in kernel
cmdline at boot in your case:

Kernel command line: ... xhci_hcd.quirks=0x80 rw quiet splash

Any idea why this is set? 
Can you try to remove it and see if it works

-- 
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 220904] [BUG] ucsi_acpi: USB 3.0 SuperSpeed not negotiated on USB-C hot-plug

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220904

--- Comment #14 from Thomas Jetzinger (thomas@jetzinger.com) ---
Created attachment 309395
  --> https://bugzilla.kernel.org/attachment.cgi?id=309395&action=edit
Removed xhci_hcd.quirks=0x80 from kernel command line as suggested.

Suspend/resume now works correctly:

  PM: suspend entry (s2idle)
  xhci_hcd 0000:00:0d.0: xhci_suspend: stopping usb1 port polling.
  xhci_hcd 0000:00:14.0: xhci_suspend: stopping usb3 port polling.
  xhci_hcd 0000:00:0d.0: xhci_resume: starting usb1 port polling.
  xhci_hcd 0000:00:14.0: xhci_resume: starting usb3 port polling.
  r8152-cfgselector 2-3.1: usb resume
  r8152-cfgselector 2-3.1: finish resume
  r8152 2-3.1:1.0 enp0s13f0u3u1: carrier on
  PM: suspend exit

No "root hub lost power" messages. Ethernet recovers at SuperSpeed.
Full dmesg with xhci_hcd and usbcore debug attached.

Thanks for identifying the root cause.

-- 
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 220904] [BUG] ucsi_acpi: USB 3.0 SuperSpeed not negotiated on USB-C hot-plug

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=220904

Thomas Jetzinger (thomas@jetzinger.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |ANSWERED

--- Comment #15 from Thomas Jetzinger (thomas@jetzinger.com) ---
TLP blocks xhci_hcd from runtime PM by default, which caused my xHCI controller
to fail resume with "root hub lost power" errors.

I didn't realize TLP was the culprit, so I added xhci_hcd.quirks=0x80 to force
resets on resume. That fixed suspend/resume but broke hot-plug.

Proper fix:
- Remove xhci_hcd from TLP's RUNTIME_PM_DRIVER_DENYLIST in /etc/tlp.conf (if
installed)
- Remove xhci_hcd.quirks=0x80 from kernel command line (or never add it)

Both suspend/resume and hot-plug now work correctly. Other ThinkPad users with
TLP defaults might hit this same issue.

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

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