Re: [REGRESSION] USB-A devices not working on boot after recent USB merge

[Mathias Nyman <mathias.nyman@linux.intel.com>]

Hi  Arisa

On 10/9/25 01:25, Arisa Snowbell wrote:
> This is what I get when I use good kernel:
> 
> kernel: xhci_hcd 0000:7a:00.0: xHCI Host Controller
> kernel: xhci_hcd 0000:7a:00.0: new USB bus registered, assigned bus number 9
> kernel: xhci_hcd 0000:7a:00.0: USB3 root hub has no ports
> kernel: xhci_hcd 0000:7a:00.0: hcc params 0x0110ffc5 hci version 0x120
> quirks 0x0000000200000010
> kernel: xhci_hcd 0000:7a:00.0: xHCI Host Controller
> kernel: xhci_hcd 0000:7a:00.0: new USB bus registered, assigned bus number 10
> kernel: xhci_hcd 0000:7a:00.0: Host supports USB 3.0 SuperSpeed
> kernel: usb usb9: New USB device found, idVendor=1d6b, idProduct=0002,
> bcdDevice= 6.17
> kernel: usb usb9: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> kernel: usb usb9: Product: xHCI Host Controller
> kernel: usb usb9: Manufacturer: Linux
> 6.17.0-1-mainline-12298-gf5bd2142c274 xhci-hcd
> kernel: usb usb9: SerialNumber: 0000:7a:00.0
> kernel: hub 9-0:1.0: USB hub found
> kernel: hub 9-0:1.0: 1 port detected
> kernel: usb usb10: We don't know the algorithms for LPM for this host,
> disabling LPM.
> kernel: usb usb10: New USB device found, idVendor=1d6b,
> idProduct=0003, bcdDevice= 6.17
> kernel: usb usb10: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> kernel: usb usb10: Product: xHCI Host Controller
> kernel: usb usb10: Manufacturer: Linux
> 6.17.0-1-mainline-12298-gf5bd2142c274 xhci-hcd
> kernel: usb usb10: SerialNumber: 0000:7a:00.0
> kernel: hub 10-0:1.0: USB hub found
> kernel: hub 10-0:1.0: config failed, hub doesn't have any ports! (err -19)
> 
> where the 2.0 USB's work, mice is powered on, with the bad kernel the
> mice doesn't even power the LED's on.
> In the bad kernel its missing the New USB and all.

It looks like the new (bad) kernel tries to suspend the xHCI host immediately
after setting the one USB 2.0 roothub up. It's possible it fails to detect any
port changes, and thus device before this.

Does forcing the xHCI and roothub "on" help?, preventing runtime suspend?

on bad (new) kernel:

# echo on > /sys/bus/pci/devices/0000:7a:00.0/power/control
# echo on > /sys/bus/pci/devices/0000:7a:00.0/usb9/power/control

It's possible there's some issue with xhci driver runtime pm usage count
when only using one roothub.

xhci driver enables runtime pm for all PCI based xHCI 1.2 controllers by default.
The "one roothub" xHCI controllers enabled earlier were all non-PCI hosts, which
don't enable runtime PM by default.

Thanks
Mathias