New: USB: xhci_hcd: Goodix USB Fingerprint sensor keep resetting

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

            Bug ID: 222000
           Summary: USB: xhci_hcd: Goodix USB Fingerprint sensor keep
                    resetting
           Product: Drivers
           Version: 2.5
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: USB
          Assignee: [email protected]
          Reporter: [email protected]
        Regression: No

The Goodix USB Fingerprint sensor on my laptop is correctly detected and registered by the xhci_hcd driver (USB ID 27c6:6090). But every time I use this fingerprint sensor, it'll reset twice and cause this device pretty unstable. I've tried disabling the USB power saving feature via udev on this device but it didn't work.

Kernel Version:
7.3.0-rc2-1-cachyos-rc

Distribution:
Arch Linux

Hardware:
- Laptop Model: MSI Prestige 16 Flip AI+ C3MTG
- Finger sensor: Shenzhen Goodix Technology Co.,Ltd. Goodix USB2.0 MISC
- USB ID: 27c6:6090

Steps to reproduce:
1. Wait for the device to be registered by the kernel
2. Proceed user authentication via this fingerprint sensor

Expected behavior:
The device should be stable and easy to proceed user authentication

Actual behavior:
The device pretty unstable and often fail to proceed user authentication

relevant dmesg log:
sudo dmesg | grep "usb 3-6"

[    0.740400] usb 3-6: new full-speed USB device number 2 using xhci_hcd
[    0.864102] usb 3-6: New USB device found, idVendor=27c6, idProduct=6090,
bcdDevice= 1.00
[    0.864890] usb 3-6: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[    0.864893] usb 3-6: Product: Goodix USB2.0 MISC
[    0.864896] usb 3-6: Manufacturer: Goodix Technology Co., Ltd.
[    0.864898] usb 3-6: SerialNumber: UIDEA968203_XXXX_MOC_B0
[   34.580581] usb 3-6: reset full-speed USB device number 2 using xhci_hcd
[   34.827562] usb 3-6: reset full-speed USB device number 2 using xhci_hcd
[   67.098374] usb 3-6: reset full-speed USB device number 2 using xhci_hcd
[   67.346355] usb 3-6: reset full-speed USB device number 2 using xhci_hcd
[   77.613264] usb 3-6: reset full-speed USB device number 2 using xhci_hcd
[  441.602772] usb 3-6: reset full-speed USB device number 2 using xhci_hcd
[  441.854704] usb 3-6: reset full-speed USB device number 2 using xhci_hcd
[ 1896.452054] usb 3-6: reset full-speed USB device number 2 using xhci_hcd
[ 1896.702992] usb 3-6: reset full-speed USB device number 2 using xhci_hcd
[ 1968.751598] usb 3-6: reset full-speed USB device number 2 using xhci_hcd
[ 1969.003726] usb 3-6: reset full-speed USB device number 2 using xhci_hcd

You may reply to this email to add a comment.

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

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

[email protected] ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

                 CC|                            |[email protected]

--- Comment #1 from [email protected] ([email protected]) --- The repeated "reset full-speed USB device" messages likely come from usb_reset_device() in drivers/usb/core/hub.c. The device 27c6:6090 has no entry in the USB quirk table (drivers/usb/core/quirks.c), and autosuspend is enabled by default with a 2-second delay — the sensor autosuspends frequently and may fail to resume cleanly, triggering a reset-resume fallback.

Could you test this kernel boot parameter (no rebuild needed)：

usbcore.quirks=27c6:6090:kr

k = disable LPM, r = force reset-resume. If this stops the resets, the fix is to add the device to usb_quirk_list[] in drivers/usb/core/quirks.c:

{ USB_DEVICE(0x27c6, 0x6090), .driver_info = USB_QUIRK_NO_LPM |
USB_QUIRK_RESET_RESUME },
Also note: disabling power/control on the device alone via udev is insufficient — the parent hub's autosuspend can still affect it.
It would also help to know whether the resets happen during idle or only during authentication — that would distinguish autosuspend issues from a device firmware problem.

You may reply to this email to add a comment.

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