"Fingerprint sensor fails to resume after suspend on Framework 13 AMD (Goodix 27c6:609c)"

Prerequisites

  • Linux Distro: Arch Linux

  • Release Version: Rolling release (no specific version)

  • Last Updated: Regularly updated, last full system update: sudo pacman -Syu on 2025-01-18

  • Kernel: 6.18.5-arch1-1 (also tested with 6.17.0-arch1-1 with same results)

  • BIOS Version: 03.09 (latest as of 2025-01-19)

  • Framework Laptop 13 Model: AMD Ryzen™ 300 Series (Framework Laptop 13 - AMD Ryzen 5 AI 340)

Issue Description

The Goodix fingerprint sensor (ID 27c6:609c) works correctly on a fresh boot but disappears completely after suspend/resume cycles. The sensor is not detected by lsusb, fprintd, or the system until a USB controller reset is performed.

Steps to Reproduce

  1. Fresh boot system

  2. Verify fingerprint works: fprintd-enroll or fprintd-verify

  3. Suspend system: systemctl suspend

  4. Resume system (press power button)

  5. Attempt to use fingerprint - fails

  6. Check sensor status: lsusb | grep -i goodix - no output

Debug Information

dmesg shows critical errors:

text

[41637.641560] xhci_hcd 0000:c1:00.4: xHCI host controller not responding, assume dead
[41637.641588] xhci_hcd 0000:c1:00.4: HC died; cleaning up
[41637.641652] usb 1-1: PM: dpm_run_callback(): usb_dev_resume returns -22
[41637.641669] usb 1-1: PM: failed to resume async: error -22
[41637.645899] usb 1-1: USB disconnect, device number 2

Sensor hardware details:

  • USB ID: 27c6:609c

  • Product: Goodix USB2.0 MISC

  • Manufacturer: Goodix Technology Co., Ltd.

  • Serial: UID39C0152B_XXXX_MOC_B0

  • USB Path: usb1 → port 1-1 (bus 1, port 1)

Hardware/Software Context

  • USB Controller: AMD XHCI at 0000:c1:00.4 (USB 3.2 Gen 2)

  • Kernel modules involved: xhci_hcd, xhci_pci, goodix

  • Power states: Device appears to go to D3cold and fails to resume to D0

  • BIOS settings tried:

    • XHCI Hand-off: Enabled/Disabled (no difference)

    • USB Power Delivery: Various settings tested

    • Fingerprint Reader: Enabled

Testing Performed

  1. Kernal(s)

    • 6.17.x series: Fails

    • 6.18.x series: Fails

  2. Power management tests:

    • Setting usbcore.autosuspend=-1 in kernel parameters: Helps but doesn’t fix

    • Disabling USB autosuspend system-wide: Prevents issue but increases power consumption

  3. Sensor behavior:

    • Boot: ✓ Detected and working

    • First suspend/resume: ✗ Not detected

    • After USB reset: ✓ Working again

    • Subsequent suspend/resume: ✗ Not detected

Root Cause Analysis

Based on debugging, the issue appears to be a power sequencing problem during resume:

  1. The XHCI USB controller (0000:c1:00.4) fails to properly reinitialize after suspend

  2. Port 1 (where fingerprint is connected) doesn’t receive power or enumeration signal

  3. Goodix sensor remains in low-power state (D3cold) and isn’t woken

  4. USB disconnect events indicate ACPI power state transition failure

Request

  1. BIOS/EC firmware investigation: Could there be incorrect power state tables for this USB port?

  2. ACPI table review: Are the D3cold→D0 transitions defined correctly?

  3. Hardware design check: Is the fingerprint sensor on a power rail that needs special handling?

  4. Coordination with Linux maintainers: This may need kernel patches for proper AMD XHCI resume handling

1 Like

I have the same issue on Fedora 43 (Silverblue).

1 Like

Not a fix, but there is a workaround to get it working when it does fail.

And a way to actually implement that workaround with a service, since system-sleep is immutable on silverblue based installs.

Impressive. Thanks for the tip. I’ll try this out tomorrow. Shouldn’t this be patched in the firmware or, is it the way the firmware is being implemented in Linux? :thinking:

1 Like

Same here with Fedora 43 (Kinoite).

The most reliable way to get the fingerprint reader to start working again is to reboot then shutdown from the login screen and then turn laptop back on.

Regular shutdown sometimes results in a restart rather than shutdown and power off.

Support sent me to this page in their GitHub, which contains a script that wakes the sensor after a suspend. It worked for me.

The fix above worked like a charm. It’s just so strange that we need to make a systemd service for resetting the USB controller. thank you for the “unofficial” fix.