USB hub / mouse not re-enumerated after lid resume (xHC error in resume, USBSTS 0x401)

[raghuOnePlus]

Title

USB hub / mouse not re-enumerated after lid resume (xHC error in resume, USBSTS 0x401)

Environment

• Device: Apple MacBook Air (M1, 2020)
• OS: Fedora Linux Asahi Remix 44 (KDE Plasma Desktop Edition)
• Kernel: 7.1.13-402.asahi.fc44.aarch64+16k

Summary

After closing and reopening the lid (suspend/resume), a USB hub with a mouse attached to it is not re-enumerated. The mouse stops working and no new USB devices appear. Physically unplugging and replugging the hub is the only way to recover it — no software-side action (rebind, restart of usb services) that I've tried fixes it without a full reboot.

Steps to reproduce

1. Connect a USB hub with a mouse (and in my case an Ethernet adapter) to the MacBook.
2. Close the lid to suspend, then reopen it to resume.
3. Observe: mouse and other devices on the hub do not come back.

Expected behavior

USB devices behind the hub re-enumerate normally after resume, like the internal keyboard/trackpad do.

Actual behavior

On resume, the kernel log shows the xHCI controller failing and reinitializing, then never re-registering the downstream devices until the hub is physically replugged:

kernel: xhci-hcd xhci-hcd.2.auto: xHC error in resume, USBSTS 0x401, Reinit
kernel: cdc_ether 1-1.4.3:2.0 enu1u4u3c2: unregister 'cdc_ether' usb-xhci-hcd.2.auto-1.4.3, CDC Ethernet Device
...
kernel: xhci-hcd xhci-hcd.2.auto: remove, state 4
kernel: xhci-hcd xhci-hcd.2.auto: USB bus 2 deregistered
kernel: xhci-hcd xhci-hcd.2.auto: remove, state 4
kernel: xhci-hcd xhci-hcd.2.auto: Host halt failed, -110
kernel: xhci-hcd xhci-hcd.2.auto: Host controller not halted, aborting reset.
kernel: xhci-hcd xhci-hcd.2.auto: USB bus 1 deregistered
kernel: phy-apple-atc 383000000.phy: Pipehandler lock not acked.
kernel: phy-apple-atc 383000000.phy: Failed to lock pipehandler
kernel: xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
kernel: xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 1
kernel: xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 2

After this point, only the internal devices come back automatically; the downstream hub with mouse/ethernet stays dark until physically unplugged and replugged, which forces a full renegotiation through the USB-C PD chip.

This has happened consistently across multiple resume cycles (confirmed reproducible on 2026-09-11 and 2026-09-12).

Workaround

Physically disconnect and reconnect the USB hub after each resume. No in-software fix found so far.

What I've already tried (unsuccessful / made things worse)

• A custom systemd-sleep hook script that rebinds xhci-hcd / phy-apple-atc after resume — unreliable, didn't consistently fix it.
• Manually unbinding/rebinding the USB-C PD controller (tps6598x) or dwc3-apple via sysfs while the system was running — this broke USB entirely (even the internal root hubs disappeared) and required a full reboot to recover. I would not recommend this approach.

Happy to provide dmesg/journalctl output around additional resume cycles, lsusb -t before/after, or test patches if useful.