USB hub (QinHeng 1a86:809d) becomes unresponsive after suspend/shutdown on MacBook Air M1 #570

On a MacBook Air M1 (MacBookAir10,1) running Fedora Asahi Remix (GNOME), a USB hub connected to the USB-C port stops responding — along with every device attached to it — after the system suspends/resumes or is powered off/on. The hub only comes back if it is physically unplugged and replugged.

An attempt to recover it in software, by unbinding and rebinding the xhci-hcd platform driver instance without physically touching the cable, failed: the controller could not be halted/reset (-110 timeout), suggesting the issue sits below the generic xhci-hcd driver — likely in the SoC's USB-C/Thunderbolt port controller not restoring power/link state correctly on resume.
Steps to reproduce
Connect the QinHeng hub to the MacBook Air M1's USB-C port, with devices attached to it.
Suspend the system and resume it (the issue is also reported to occur after a full shutdown/power-on cycle, though the log below is specifically from a suspend/resume cycle).
The hub and everything attached to it stop responding — nothing from it shows up in lsusb.
Expected behavior

The hub and its downstream devices should become available again automatically on resume/boot.

Actual behavior

The hub stays completely inaccessible until it is physically disconnected and reconnected.

Log on resume (dmesg)
[ 436.867770] Restarting tasks: Starting
[ 436.867802] usb 1-1: USB disconnect, device number 2
[ 436.867803] usb 1-1.1: USB disconnect, device number 3
[ 436.868166] Restarting tasks: Done
...
[ 436.897633] usb 1-1.5: USB disconnect, device number 4
[ 436.897719] cdc_ether 1-1.5:2.0 enu1u5c2: unregister 'cdc_ether' usb-xhci-hcd.2.auto-1.5, CDC Ethernet Device

Note that the hub itself (1-1) is disconnected, not just the devices hanging off it (1-1.1, 1-1.5). This points to the hub losing power (Vbus) entirely during suspend, rather than merely failing to answer a resume request.

Failed software recovery attempt

Tried forcing the controller to reinitialize via sysfs, without physically unplugging the hub:

bash
echo -n "xhci-hcd.2.auto" | sudo tee /sys/bus/platform/drivers/xhci-hcd/unbind
sleep 2
echo -n "xhci-hcd.2.auto" | sudo tee /sys/bus/platform/drivers/xhci-hcd/bind

Result — the controller could not come back up:

[ 830.092267] xhci-hcd xhci-hcd.2.auto: remove, state 4
[ 830.092274] usb usb2: USB disconnect, device number 1
[ 830.092476] xhci-hcd xhci-hcd.2.auto: USB bus 2 deregistered
[ 830.092524] xhci-hcd xhci-hcd.2.auto: remove, state 4
[ 830.092525] usb usb1: USB disconnect, device number 1
[ 830.134294] xhci-hcd xhci-hcd.2.auto: Host halt failed, -110
[ 830.134297] xhci-hcd xhci-hcd.2.auto: Host controller not halted, aborting reset.
[ 830.137018] xhci-hcd xhci-hcd.2.auto: USB bus 1 deregistered
[ 832.186977] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[ 832.187163] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 1
[ 832.228998] xhci-hcd xhci-hcd.2.auto: Host halt failed, -110
[ 832.229002] xhci-hcd xhci-hcd.2.auto: can't setup: -110
[ 832.229005] xhci-hcd xhci-hcd.2.auto: USB bus 1 deregistered
[ 832.229063] xhci-hcd xhci-hcd.2.auto: probe with driver xhci-hcd failed with error -110

The -110 timeout while trying to halt/reset the controller suggests the problem is lower than the generic xhci-hcd driver — likely in the Apple Silicon-specific USB-C/Thunderbolt port controller not being reinitialized correctly on resume.

Workaround

Physically unplug and replug the hub.

Thank you for all the work, I really like Asahi