USB: HP SK-2025 (03f0:0d4a) fails to re-enumerate after S3; port power-cycle does not recover

[Bill Supples]

Hello USB folks,

HP SK-2025 keyboard (03f0:0d4a, USB 1.1 low-speed HID) does not come
back after ACPI S3 on an MSI PRO B650-P WIFI. The kernel disconnects
it, attempts a port power-cycle, then logs "unable to enumerate USB
device". A physical unplug (long VBUS drop) always recovers it.

This is not a single bad port. The same failure happens on three xHCI
controllers on the same board. A Dell MS116 mouse (also USB 1.1 LS)
on the chipset controller survives the same resume.

I am not reporting the chipset "xHC error in resume, USBSTS 0x401,
Reinit" as the bug. That is the Promontory controller at 10:00.0
(1022:43f7) reinitializing after a failed save/restore (see also
bugzilla 216470). The mouse on that controller comes back. The two
Raphael CPU xHCIs (1022:15b6 / 1022:15b7) never log 0x401 and still
lose this keyboard.

Hardware
========
Board:  MSI PRO B650-P WIFI (MS-7D78), BIOS 1.I0 (2025-03-12)
CPU:    AMD Ryzen 7 7700X (Raphael)
Kernel: 7.2.4-ogc3.1.fc44.x86_64 (Bazzite 44 / Fedora 44 based)
Device: 03f0:0d4a HP SK-2025, bcdUSB 1.10, bcdDevice 2.07,
        bmAttributes 0xa0 (bus-powered, remote-wakeup), MaxPower 100mA,
        speed 1.5 Mbps, persist=1

USB controllers:
  0000:10:00.0  1022:43f7  AMD 600-series / Promontory USB 3.2
  0000:12:00.3  1022:15b6  Raphael USB 3.1 xHCI
  0000:12:00.4  1022:15b7  Raphael USB 3.1 xHCI
  0000:13:00.0  1022:15b8  Raphael USB 2.0 xHCI (no user ports)

Reproduced on
=============
1. Chipset Promontory, direct port usb 1-3
2. Raphael 12:00.4, usb 5-2 (and usb 5-1)
3. Raphael 12:00.3, usb 3-2  (current; rear USB 3.2 Gen2 Type-A)

Also failed after a cold reboot with the cable left connected (device
still wedged until unplug). So this is not only a suspend persist
path; the MCU needs VBUS actually removed.

S3 on Raphael 12:00.3 (usb 3-2), 2026-09-19
===========================================
PM: suspend entry (deep)
ACPI: PM: Waking up from system sleep state S3
xhci_hcd 0000:10:00.0: xHC error in resume, USBSTS 0x401, Reinit
usb 3-2: USB disconnect, device number 13
usb usb3-port2: attempt power cycle
usb usb3-port2: unable to enumerate USB device

(The 0x401 line is the *other* controller. usb3 is 12:00.3 and did
not log a host error.)

A userspace resume hook then wrote 1, slept 3s, wrote 0 to
  /sys/bus/usb/devices/3-0:1.0/usb3-port2/disable
That did not recover the device. After re-enable the kernel retried
as the wrong speed:

usb 3-2: new full-speed USB device number 18 using xhci_hcd
usb usb3-port2: attempt power cycle
usb usb3-port2: unable to enumerate USB device

~90s later a physical unplug/replug enumerated it correctly as
low-speed 03f0:0d4a.

S3 on Raphael 12:00.4 (usb 5-2), no userspace hook
=================================================
PM: suspend entry (deep)
ACPI: PM: Waking up from system sleep state S3
usb 5-2: USB disconnect, device number 2
usb usb5-port2: attempt power cycle
usb usb5-port2: unable to enumerate USB device

After the subsequent reboot, with the cable still connected:
  usb usb5-port2: attempt power cycle
  usb usb5-port2: unable to enumerate USB device
Unplug/replug recovered it.

S3 on Promontory 10:00.0 (usb 1-3)
=================================
xhci_hcd 0000:10:00.0: xHC error in resume, USBSTS 0x401, Reinit
usb 1-3: USB disconnect
usb 1-3: new full-speed USB device number 13 using xhci_hcd
usb 1-3: device descriptor read/64, error -71
usb usb1-port3: attempt power cycle
usb 1-3: device not accepting address 15, error -71
usb usb1-port3: unable to enumerate USB device

~12s later physical replug:
usb 1-3: new low-speed USB device number 17 using xhci_hcd
usb 1-3: New USB device found, idVendor=03f0, idProduct=0d4a

Note the kernel tries full-speed against a USB 1.1 LS device after
the failed resume, then gives up.

Why I do not think USB_QUIRK_RESET_RESUME is enough
===================================================
quirks.c already has USB_QUIRK_RESET_RESUME for other HP/Pixart HIDs
(03f0:2b4a, several 093a:* mice) but not 03f0:0d4a.
RESET_RESUME / DISCONNECT_SUSPEND help devices that stay logically
attached. This keyboard remains dead after a reboot with VBUS left
applied, and a 3s sysfs port/disable on the Raphael USB2 companion
port also failed. That points at PP/VBUS not actually dropping on
these AMD USB2 ports during hub_port power-cycle / port disable.

Questions
=========
1. Does xHCI USB2 port power-cycle on AMD Promontory (1022:43f7) and
   Raphael (1022:15b6/15b7) actually deassert VBUS?
2. If yes: can the off-time be lengthened for this VID:PID (or for LS
   devices that fail the first power-cycle)?
3. If no: that is a host bug; a device quirk cannot fix it.

I did not PCI-reset or unbind the xHCI function (too easy to leave a
controller unbound on a desktop).

Happy to gather more (full dmesg, lsusb -v, usbmon, dynamic debug)
if useful.

Thanks,
Brian