Re: [PATCH v4 00/11] Add spi-hid transport driver

[Dale Whinham]

On 18/09/2026 11:10, fQwQf wrote:
> Hi Jingyuan,
>
>
> > This series picks up the spi-hid driver work originally started by
> > Microsoft. The patch breakdown has been modified and the implementation
> > has been refactored to address upstream feedback and testing issues. We
> > are submitting this as a new series while keeping the original sign-off
> > chain to reflect the history.
>
>
> I am working on Linux support for the Surface Laptop 7 (13.8-inch, Snapdragon X series), whose touchpad is a HID-over-SPI device behind a Qualcomm GENI QSPI controller. I noticed that v4 (June 9) is the
> latest revision of this series and has so far only seen automated review feedback, so I would like to coordinate before preparing any upstream submission of my own.
>
> Current state on my side:
>
> - I have a working touchpad using a downstream Qualcomm GENI QSPI +  spi-hid stack (originally from scuggo's x1e-nixos work, imported  via ELLX-Kernel). My local adaptations move the transport to spi-mem and add framing, response matching, and DMA/error-path  hardening.
> - Normal touchpad use works on my machine. The latest hardening currently has only build and software-test coverage; I have not validated s.
> 2. The SL7 adds a different transport requirement (quad-SPI via GENI, through spi-mem) on topuspend/resume, and I have not yet run your v4 series on this hardware.
>
> I believe our work may complement each other in two ways:
>
> 1. The automated review of the series raised DMA cacheline-alignment concerns for SPI transfer buffers and unchecked reset return values in the init/resume paths. Both overlap with the hardening I have been doing downstream, and I would be glad to contribute fixes there.
> 2. The SL7 adds a different transport requirement (quad-SPI via GENI, through spi-mem) on top of the same HID-over-SPI protocol, which looks like a natural fit for your generic driver rather than a standalone one.
>
> Questions:
>
> - What tree or series do you recommend working against? Is v4 still your current baseline, or do you have a newer development branch?
> - Would adding the SL7 quad-SPI transport requirements to your generic driver be the preferred upstream approach? Is anyone already working on this?
> - Are you waiting on maintainer review before a v5? A second hardware platform may help move things along, and I am happy to provide testing on SL7.
>
> I am also tracing the downstream provenance of the Qualcomm QSPI code with the original authors to ensure a clean sign-off chain; I appreciate that this series handles its own history the same way.
>
> Happy to share technical details or a preliminary diff if useful.
>
> I'm not subscribed to the lists; please keep me in CC.
>
> Best regards,
> Jizhou Tong

Hi Jizhou, Jingyuan,

I am working on Surface Pro 11 aka. Denali, Snapdragon X1E80100.

This series (v4) has enabled successful bringup of touchscreen and pen 
on the SP11, which also uses QSPI via GENI.

There is some updated SL7 QSPI 'glue' code at 
https://github.com/orvitpng/nix1e that reworked the original scuggo nix 
flake code to work on top of Jingyuan's updated spi-hid series.

With that + some extra pieces to wire it into the Denali devicetree, 
this series is working well here.

I'm keen to help move things along as the tablet functionality is a key 
feature of the Surface Pro - please feel free to CC me on further 
discussions.

Tested-by: Dale Whinham <daleyo@xxxxxxxxx>