[RFC PATCH 0/3] HID: spi-hid: support the pre-release protocol (Surface Pro X digitizer)

[Tawheed Makhdoomi <_@tawheed.cc>]

This RFC series sits on top of Jingyuan's "[PATCH v7 00/11] Add spi-hid
transport driver" [1]. It adds support for digitizers that speak the
pre-release revision of the HID over SPI protocol, the one Microsoft's
original 2022 spi-hid driver targeted. The motivating device is the
Microsoft Surface Pro X (Qualcomm sc8180x), whose touch/pen digitizer
(045E:0996) ships this way.

With v7 as posted, the Pro X digitizer binds (via the g6 compatible), but
every input report is rejected with "Unknown input report version (v 0x2)".
The differences go beyond the version nibble:

 - input header: report type in the high nibble of byte 0, a fragment id,
   and a 12-bit length across bytes 1-2
 - input body: a 3-byte body header (length, content id), no report type
 - output: a 6-byte header (opcode, register address, version + 12-bit
   length) followed by a 4-byte body header (content type, length, id)
 - requests are addressed to per-function registers: device descriptor at
   a fixed register, report descriptor at wReportDescRegister,
   features/output reports at wOutputRegister
 - a 28-byte device descriptor carrying those registers, bcdVersion 0x0100
 - SET_FEATURE and output reports are not acknowledged

Patch 2 keeps all of this behind a per-device "protocol" field in
struct spi_hid_conf, in small helpers, so the v3 paths (g6, ACPI) are
unchanged. Patch 3 adds the Pro X match data. Patch 1 adds its compatible.

Tested on two Surface Pro X SQ1 (LTE) units on top of v7 (plus an
out-of-tree sc8180x DT): the device and report descriptors are accepted,
the HID device is created, iptsd's GET_FEATURE/SET_FEATURE succeed, and
multitouch works (5 simultaneous contacts, no driver errors).

Questions, which are why this is an RFC:
 - Would you take support for the pre-release protocol revision at all,
   given it's in shipping hardware? If so, is a per-device protocol field
   in spi_hid_conf the right shape, or would you prefer something else?
 - The compatible is named after the product
   ("microsoft,surface-pro-x-touch-digitizer"), since Microsoft publishes
   no part number or generation for this digitizer. Is that acceptable?

Known gaps / observations:
 - Fragmented input reports are not supported in the v2 path (fragment id
   ignored); I have not seen this device send fragments.
 - COMMAND (e.g. SET_POWER), output reports and suspend/resume are not
   exercised by my testing yet.
 - Once, on the first boot after installing a new kernel, the boot-time
   probe saw no interrupt at all (IRQ count stayed 0); unbind/bind fixed it
   and later boots were fine. That looks like a reset-response edge lost
   at probe. v7 has no timeout/retry for that case; I'm not sure yet
   whether it's specific to this device.
 - Around a rebind, one "Unknown input report version" from the power-up
   window can appear, because the version check runs before the
   reset-pending check. Harmless, but noisy.

The matching sc8180x DT change will go via the Surface Pro X DT work.

[1] https://lore.kernel.org/r/20261024-send-upstream-v7-0-abad13174b43@chromium.org

Tawheed Makhdoomi (3):
  dt-bindings: input: hid-over-spi: add the Surface Pro X touch
    digitizer
  HID: spi-hid: support the pre-release HID over SPI protocol revision
  HID: spi-hid-of: add the Surface Pro X touch digitizer

 .../bindings/input/hid-over-spi.yaml          |   1 +
 drivers/hid/spi-hid/spi-hid-core.c            | 327 +++++++++++++++---
 drivers/hid/spi-hid/spi-hid-core.h            |   4 +
 drivers/hid/spi-hid/spi-hid-of.c              |  26 ++
 drivers/hid/spi-hid/spi-hid.h                 |  27 +-
 5 files changed, 344 insertions(+), 41 deletions(-)


base-commit: 04fd628c5c27c93b623b5b6b88fd52d4444d5a7b
-- 
2.43.0