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 <[email protected]>
