This series adds a kernel driver for the Goodix GXFP5130 fingerprint
sensor found in Huawei MateBook laptops (D16 2024, X Pro 2024, 14 2024).

The sensor is enumerated through ACPI (HID: GXFP5130) and communicates
with the host via an eSPI-based memory-mapped mailbox window plus three
GPIOs. It does not use SPI or I2C bus drivers.

A misc character device /dev/gxfp is exposed to userspace. The libfprint
library (with a corresponding GXFP5130 plugin) uses this device to perform
biometric enrollment and verification via fprintd.

The four patches are:
  [1/4] UAPI header (include/uapi/linux/gxfp_ioctl.h)
  [2/4] Driver source tree (drivers/misc/gxfp5130/)
  [3/4] Documentation (Documentation/misc-devices/gxfp5130.rst)
  [4/4] MAINTAINERS entry

Metehan Günen (4):
  include/uapi/linux: add gxfp_ioctl.h for GXFP5130 fingerprint sensor
  drivers/misc: add Goodix GXFP5130 eSPI fingerprint sensor driver
  Documentation/misc-devices: add gxfp5130.rst
  MAINTAINERS: add entry for GXFP5130 fingerprint sensor driver

 Documentation/misc-devices/gxfp5130.rst       |  90 +++++++
 Documentation/misc-devices/index.rst          |   1 +
 MAINTAINERS                                   |   7 +
 drivers/misc/Kconfig                          |   2 +
 drivers/misc/Makefile                         |   2 +
 drivers/misc/gxfp5130/Kconfig                 |  18 ++
 drivers/misc/gxfp5130/Makefile                |  28 ++
 drivers/misc/gxfp5130/cmd/gxfp_cmd.c          | 177 ++++++++++++
 drivers/misc/gxfp5130/cmd/gxfp_cmd.h          |  54 ++++
 .../misc/gxfp5130/cmd/gxfp_cmd_mcu_config.c   |  28 ++
 .../misc/gxfp5130/cmd/gxfp_cmd_mcu_config.h   |  12 +
 .../misc/gxfp5130/cmd/gxfp_cmd_mcu_state.c    |  89 +++++++
 .../misc/gxfp5130/cmd/gxfp_cmd_mcu_state.h    |  30 +++
 drivers/misc/gxfp5130/cmd/gxfp_cmd_reset.c    | 185 +++++++++++++
 drivers/misc/gxfp5130/cmd/gxfp_cmd_reset.h    |  27 ++
 drivers/misc/gxfp5130/cmd/gxfp_cmd_version.c  | 100 +++++++
 drivers/misc/gxfp5130/cmd/gxfp_cmd_version.h  |  22 ++
 drivers/misc/gxfp5130/driver/gxfp_irq.c       |  57 ++++
 drivers/misc/gxfp5130/driver/gxfp_irq.h       |   9 +
 drivers/misc/gxfp5130/driver/gxfp_platform.c  | 251 ++++++++++++++++++
 drivers/misc/gxfp5130/driver/gxfp_platform.h  |  12 +
 drivers/misc/gxfp5130/driver/gxfp_trace.c     | 179 +++++++++++++
 drivers/misc/gxfp5130/driver/gxfp_trace.h     |  15 ++
 drivers/misc/gxfp5130/driver/gxfp_uapi.h      |  25 ++
 drivers/misc/gxfp5130/driver/gxfp_uapi_ctrl.c | 136 ++++++++++
 drivers/misc/gxfp5130/driver/gxfp_uapi_fifo.c | 245 +++++++++++++++++
 drivers/misc/gxfp5130/driver/gxfp_uapi_misc.c | 123 +++++++++
 drivers/misc/gxfp5130/gxfp_main.c             | 127 +++++++++
 drivers/misc/gxfp5130/hw/gxfp_acpi.c          | 130 +++++++++
 drivers/misc/gxfp5130/hw/gxfp_acpi.h          |  15 ++
 drivers/misc/gxfp5130/hw/gxfp_delay.c         |  15 ++
 drivers/misc/gxfp5130/hw/gxfp_delay.h         |   7 +
 drivers/misc/gxfp5130/hw/gxfp_gpio.c          |  64 +++++
 drivers/misc/gxfp5130/hw/gxfp_gpio.h          |  17 ++
 drivers/misc/gxfp5130/hw/gxfp_mmio.c          |  45 ++++
 drivers/misc/gxfp5130/hw/gxfp_mmio.h          |  10 +
 .../misc/gxfp5130/include/gxfp_constants.h    |  38 +++
 drivers/misc/gxfp5130/include/gxfp_priv.h     |  55 ++++
 .../misc/gxfp5130/proto/gxfp_goodix_proto.c   |  84 ++++++
 .../misc/gxfp5130/proto/gxfp_goodix_proto.h   |  31 +++
 drivers/misc/gxfp5130/proto/gxfp_mp_proto.c   |  96 +++++++
 drivers/misc/gxfp5130/proto/gxfp_mp_proto.h   |  27 ++
 .../gxfp5130/transport/gxfp_espi_common.c     |  80 ++++++
 .../gxfp5130/transport/gxfp_espi_common.h     |  27 ++
 .../gxfp5130/transport/gxfp_espi_rx_irq.c     | 120 +++++++++
 .../gxfp5130/transport/gxfp_espi_rx_irq.h     |  15 ++
 .../gxfp5130/transport/gxfp_espi_rx_sync.c    |  96 +++++++
 .../gxfp5130/transport/gxfp_espi_rx_sync.h    |  14 +
 .../misc/gxfp5130/transport/gxfp_espi_tx.c    |  88 ++++++
 .../misc/gxfp5130/transport/gxfp_espi_tx.h    |  20 ++
 include/uapi/linux/gxfp_ioctl.h               |  43 +++
 51 files changed, 3188 insertions(+)

--
2.55.0

On Sat, Jul 18, 2026 at 11:14:27AM +0300, Metehan Günen wrote:
> This series adds a kernel driver for the Goodix GXFP5130 fingerprint
> sensor found in Huawei MateBook laptops (D16 2024, X Pro 2024, 14 2024).
> 
> The sensor is enumerated through ACPI (HID: GXFP5130) and communicates
> with the host via an eSPI-based memory-mapped mailbox window plus three
> GPIOs. It does not use SPI or I2C bus drivers.
> 
> A misc character device /dev/gxfp is exposed to userspace. The libfprint
> library (with a corresponding GXFP5130 plugin) uses this device to perform
> biometric enrollment and verification via fprintd.

Is that the "normal" user/kernel api for these types of sensors?  I
thought we had a real api these days, and a vendor one was not generally
a good idea as you are just exposing raw hardware design to userspace.

> The four patches are:
>   [1/4] UAPI header (include/uapi/linux/gxfp_ioctl.h)
>   [2/4] Driver source tree (drivers/misc/gxfp5130/)
>   [3/4] Documentation (Documentation/misc-devices/gxfp5130.rst)
>   [4/4] MAINTAINERS entry
> 
> Metehan Günen (4):
>   include/uapi/linux: add gxfp_ioctl.h for GXFP5130 fingerprint sensor
>   drivers/misc: add Goodix GXFP5130 eSPI fingerprint sensor driver
>   Documentation/misc-devices: add gxfp5130.rst
>   MAINTAINERS: add entry for GXFP5130 fingerprint sensor driver
> 
>  Documentation/misc-devices/gxfp5130.rst       |  90 +++++++
>  Documentation/misc-devices/index.rst          |   1 +
>  MAINTAINERS                                   |   7 +
>  drivers/misc/Kconfig                          |   2 +
>  drivers/misc/Makefile                         |   2 +
>  drivers/misc/gxfp5130/Kconfig                 |  18 ++
>  drivers/misc/gxfp5130/Makefile                |  28 ++
>  drivers/misc/gxfp5130/cmd/gxfp_cmd.c          | 177 ++++++++++++
>  drivers/misc/gxfp5130/cmd/gxfp_cmd.h          |  54 ++++
>  .../misc/gxfp5130/cmd/gxfp_cmd_mcu_config.c   |  28 ++
>  .../misc/gxfp5130/cmd/gxfp_cmd_mcu_config.h   |  12 +
>  .../misc/gxfp5130/cmd/gxfp_cmd_mcu_state.c    |  89 +++++++
>  .../misc/gxfp5130/cmd/gxfp_cmd_mcu_state.h    |  30 +++
>  drivers/misc/gxfp5130/cmd/gxfp_cmd_reset.c    | 185 +++++++++++++
>  drivers/misc/gxfp5130/cmd/gxfp_cmd_reset.h    |  27 ++
>  drivers/misc/gxfp5130/cmd/gxfp_cmd_version.c  | 100 +++++++
>  drivers/misc/gxfp5130/cmd/gxfp_cmd_version.h  |  22 ++
>  drivers/misc/gxfp5130/driver/gxfp_irq.c       |  57 ++++
>  drivers/misc/gxfp5130/driver/gxfp_irq.h       |   9 +
>  drivers/misc/gxfp5130/driver/gxfp_platform.c  | 251 ++++++++++++++++++
>  drivers/misc/gxfp5130/driver/gxfp_platform.h  |  12 +
>  drivers/misc/gxfp5130/driver/gxfp_trace.c     | 179 +++++++++++++
>  drivers/misc/gxfp5130/driver/gxfp_trace.h     |  15 ++
>  drivers/misc/gxfp5130/driver/gxfp_uapi.h      |  25 ++
>  drivers/misc/gxfp5130/driver/gxfp_uapi_ctrl.c | 136 ++++++++++
>  drivers/misc/gxfp5130/driver/gxfp_uapi_fifo.c | 245 +++++++++++++++++
>  drivers/misc/gxfp5130/driver/gxfp_uapi_misc.c | 123 +++++++++
>  drivers/misc/gxfp5130/gxfp_main.c             | 127 +++++++++
>  drivers/misc/gxfp5130/hw/gxfp_acpi.c          | 130 +++++++++
>  drivers/misc/gxfp5130/hw/gxfp_acpi.h          |  15 ++
>  drivers/misc/gxfp5130/hw/gxfp_delay.c         |  15 ++
>  drivers/misc/gxfp5130/hw/gxfp_delay.h         |   7 +
>  drivers/misc/gxfp5130/hw/gxfp_gpio.c          |  64 +++++
>  drivers/misc/gxfp5130/hw/gxfp_gpio.h          |  17 ++
>  drivers/misc/gxfp5130/hw/gxfp_mmio.c          |  45 ++++
>  drivers/misc/gxfp5130/hw/gxfp_mmio.h          |  10 +
>  .../misc/gxfp5130/include/gxfp_constants.h    |  38 +++
>  drivers/misc/gxfp5130/include/gxfp_priv.h     |  55 ++++
>  .../misc/gxfp5130/proto/gxfp_goodix_proto.c   |  84 ++++++
>  .../misc/gxfp5130/proto/gxfp_goodix_proto.h   |  31 +++
>  drivers/misc/gxfp5130/proto/gxfp_mp_proto.c   |  96 +++++++
>  drivers/misc/gxfp5130/proto/gxfp_mp_proto.h   |  27 ++
>  .../gxfp5130/transport/gxfp_espi_common.c     |  80 ++++++
>  .../gxfp5130/transport/gxfp_espi_common.h     |  27 ++
>  .../gxfp5130/transport/gxfp_espi_rx_irq.c     | 120 +++++++++
>  .../gxfp5130/transport/gxfp_espi_rx_irq.h     |  15 ++
>  .../gxfp5130/transport/gxfp_espi_rx_sync.c    |  96 +++++++
>  .../gxfp5130/transport/gxfp_espi_rx_sync.h    |  14 +
>  .../misc/gxfp5130/transport/gxfp_espi_tx.c    |  88 ++++++
>  .../misc/gxfp5130/transport/gxfp_espi_tx.h    |  20 ++
>  include/uapi/linux/gxfp_ioctl.h               |  43 +++
>  51 files changed, 3188 insertions(+)

Why isn't this just one single .c file?  3k for a driver is nothing,
this is a mess of stuff that odds are, can be much much smaller if its
all in one single file, and one .h file for the uapi.

What caused this to be split up so crazily?

And no copyright notices at all?  Are you sure about that?

thanks,

greg k-h

I am withdrawing this patch series (v1).

After consulting with Void755, who wrote the original out-of-tree driver
this submission was based on, it became clear that the driver is not ready
for mainline inclusion yet. Specifically:

  - The kernel module currently handles sensor-specific protocol logic
    (MP protocol, Goodix command structures) that belongs in userspace.
    This is consistent with the concern you raised about why a kernel
    driver is needed at all.

  - A sibling sensor (SIL6250) shares the same eSPI mailbox transport
    mechanism. A properly refactored, transport-only kernel driver could
    support both sensors, which would make a stronger case for mainline.

  - The original author prefers out-of-tree maintenance for now while
    the architecture is reworked.

I will resubmit once the kernel/userspace boundary is properly designed
and the driver is in a state the original author considers ready.

Thank you for the detailed review of v1.

Metehan Günen

On Sat, Jul 18, 2026 at 11:05:30AM +0200, Greg KH wrote:
> Is that the "normal" user/kernel api for these types of sensors?  I
> thought we had a real api these days, and a vendor one was not generally
> a good idea as you are just exposing raw hardware design to userspace.

The GXFP5130 communicates using a vendor-specific MP protocol over the
eSPI mailbox — it is not USB HID-compliant and does not expose a
standard fingerprint command set. The libfprint plugin that consumes
this device speaks the protocol directly and handles enrollment and
matching entirely in userspace, the same model used by other libfprint
char-device backends (e.g. goodix-55x4, elan-i2c).

I am open to alternative approaches. If there is a preferred kernel-side
abstraction for this class of device I should be targeting instead,
please point me to it and I will rework the driver accordingly.

The large file count (51 files) reflects the upstream tree layout of the
out-of-tree driver I ported. v2 will consolidate the driver into a
single .c file as is standard for misc drivers of this size.

The original driver code was written by Void755 (github.com/Void755),
who developed it for out-of-tree use. I ported it to mainline kernel
conventions with assistance from an AI tool for the reformatting work.
That AI assistance introduced several of the style issues you have
pointed out across the patches. I will fix all of them in v2 and add
proper copyright attribution for both Void755 and myself.

Thanks,
Metehan Günen

On Sun, Jul 19, 2026 at 03:53:06AM -0700, Metehan Günen wrote:
> On Sat, Jul 18, 2026 at 11:05:30AM +0200, Greg KH wrote:
> > Is that the "normal" user/kernel api for these types of sensors?  I
> > thought we had a real api these days, and a vendor one was not generally
> > a good idea as you are just exposing raw hardware design to userspace.
> 
> The GXFP5130 communicates using a vendor-specific MP protocol over the
> eSPI mailbox — it is not USB HID-compliant and does not expose a
> standard fingerprint command set. The libfprint plugin that consumes
> this device speaks the protocol directly and handles enrollment and
> matching entirely in userspace, the same model used by other libfprint
> char-device backends (e.g. goodix-55x4, elan-i2c).
> 
> I am open to alternative approaches. If there is a preferred kernel-side
> abstraction for this class of device I should be targeting instead,
> please point me to it and I will rework the driver accordingly.

Why does it have to be a kernel driver at all?  Can't you just talk to
the device directly from userspace through the spi userspace api
instead?

thanks,

greg k-h