On Wed, Mar 11, 2026 at 5:58 PM Jingyuan Liang <[email protected]> wrote:
>
> (Resending to the list. Apologies, I accidentally dropped the CCs on
> my initial reply!)
>
> On Tue, Mar 3, 2026 at 5:53 AM Rob Herring <[email protected]> wrote:
> >
> > On Tue, Mar 3, 2026 at 12:14 AM Jingyuan Liang <[email protected]>
> > wrote:
> > >
> > > Documentation describes the required and optional properties for
> > > implementing Device Tree for a Microsoft G6 Touch Digitizer that
> > > supports HID over SPI Protocol 1.0 specification.
> > >
> > > The properties are common to HID over SPI.
> > >
> > > Signed-off-by: Dmitry Antipov <[email protected]>
> > > Signed-off-by: Jarrett Schultz <[email protected]>
> > > Signed-off-by: Jingyuan Liang <[email protected]>
> > > ---
> > > .../devicetree/bindings/input/hid-over-spi.yaml | 153
> > > +++++++++++++++++++++
> > > 1 file changed, 153 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> > > b/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> > > new file mode 100644
> > > index 000000000000..b623629ed9d3
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> > > @@ -0,0 +1,153 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/input/hid-over-spi.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: HID over SPI Devices
> > > +
> > > +maintainers:
> > > + - Benjamin Tissoires <[email protected]>
> > > + - Jiri Kosina <[email protected]>
> > > +
> > > +description: |+
> > > + HID over SPI provides support for various Human Interface Devices over
> > > the
> > > + SPI bus. These devices can be for example touchpads, keyboards, touch
> > > screens
> > > + or sensors.
> > > +
> > > + The specification has been written by Microsoft and is currently
> > > available here:
> > > + https://www.microsoft.com/en-us/download/details.aspx?id=103325
> > > +
> > > + If this binding is used, the kernel module spi-hid will handle the
> > > communication
> > > + with the device and the generic hid core layer will handle the
> > > protocol.
> > > +
> > > +allOf:
> > > + - $ref: /schemas/input/touchscreen/touchscreen.yaml#
> > > +
> > > +properties:
> > > + compatible:
> > > + oneOf:
> > > + - items:
> > > + - enum:
> > > + - microsoft,g6-touch-digitizer
> > > + - const: hid-over-spi
> > > + - description: Just "hid-over-spi" alone is allowed, but not
> > > recommended.
> > > + const: hid-over-spi
> > > +
> > > + reg:
> > > + maxItems: 1
> > > +
> > > + interrupts:
> > > + maxItems: 1
> > > +
> > > + reset-gpios:
> > > + maxItems: 1
> > > + description:
> > > + GPIO specifier for the digitizer's reset pin (active low). The
> > > line must
> > > + be flagged with GPIO_ACTIVE_LOW.
> > > +
> > > + vdd-supply:
> > > + description:
> > > + Regulator for the VDD supply voltage.
> >
> > Is this part of the spec? This won't scale for multiple devices with
> > different power rails.
>
> This is not part of the spec but is needed for power management. Is it okay I
> mark it as optional? Thank you.
>
> >
> > > +
> > > + input-report-header-address:
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + minimum: 0
> > > + maximum: 0xffffff
> > > + description:
> > > + A value to be included in the Read Approval packet, listing an
> > > address of
> > > + the input report header to be put on the SPI bus. This address has
> > > 24
> > > + bits.
> > > +
> > > + input-report-body-address:
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + minimum: 0
> > > + maximum: 0xffffff
> > > + description:
> > > + A value to be included in the Read Approval packet, listing an
> > > address of
> > > + the input report body to be put on the SPI bus. This address has
> > > 24 bits.
> > > +
> > > + output-report-address:
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + minimum: 0
> > > + maximum: 0xffffff
> > > + description:
> > > + A value to be included in the Output Report sent by the host,
> > > listing an
> > > + address where the output report on the SPI bus is to be written
> > > to. This
> > > + address has 24 bits.
> > > +
> > > + post-power-on-delay-ms:
> > > + description:
> > > + Optional time in ms required by the device after enabling its
> > > regulators
> > > + or powering it on, before it is ready for communication.
> >
> > Drop. This should be implied by the compatible.
>
> Thank you, I will fix this in v2.
>
> >
> > > +
> > > + minimal-reset-delay-ms:
> > > + description:
> > > + Optional minimum amount of time in ms that device needs to be in
> > > reset
> > > + state for the reset to take effect.
> >
> > Drop. This should be implied by the compatible.
>
> I will fix this in v2.
>
> >
> > > +
> > > + read-opcode:
> > > + $ref: /schemas/types.yaml#/definitions/uint8
> > > + description:
> > > + Value to be used in Read Approval packets. 1 byte.
> > > +
> > > + write-opcode:
> > > + $ref: /schemas/types.yaml#/definitions/uint8
> > > + description:
> > > + Value to be used in Write Approval packets. 1 byte.
> >
> > Why are these and the address properties above not defined by the
> > spec? Do they vary for a specific device? If not, then they should be
> > implied by the compatible.
>
> These properties are not defined by the spec:
>
> "The Input Report Address (header or body) and READ opcode are retrieved
> from ACPI."
>
> Same for the output report address and write opcode. I will drop these in v2.
Hi Rob,
Please disregard my previous reply about dropping the read/write opcodes and
input/output addresses. The spec does not define these fields. Instead, it says
these values are retrieved from ACPI _DSM methods. If we remove them from
the binding, the driver is not very generic. Would it be okay to keep them?
>
> >
> > > +
> > > + hid-over-spi-flags:
> > > + $ref: /schemas/types.yaml#/definitions/uint16
> > > + description:
> > > + 16 bits.
> > > + Bits 0-12 - Reserved (must be 0)
> > > + Bit 13 - SPI Write Mode. Possible values -
> > > + * 0b0- Writes are carried out in Single-SPI mode
> > > + * 0b1- Writes are carried out in the Multi-SPI mode specified by
> > > bits
> > > + 14-15
> > > + Bits 14-15 - Multi-SPI Mode. Possible values -
> > > + * 0b00- Single SPI
> > > + * 0b01- Dual SPI
> > > + * 0b10- Quad SPI
> >
> > We already have SPI properties to define the bus width for read and write.
>
> Will fix this in v2.
>
> >
> > > +
> > > +required:
> > > + - compatible
> > > + - interrupts
> > > + - reset-gpios
> > > + - vdd-supply
> > > + - input-report-header-address
> > > + - input-report-body-address
> > > + - output-report-address
> > > + - read-opcode
> > > + - write-opcode
> > > + - hid-over-spi-flags
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > + - |
> > > + #include <dt-bindings/interrupt-controller/irq.h>
> > > + #include <dt-bindings/gpio/gpio.h>
> > > +
> > > + spi {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + hid@0 {
> > > + compatible = "hid-over-spi";
> > > + reg = <0x0>;
> > > + interrupts-extended = <&gpio 42 IRQ_TYPE_EDGE_FALLING>;
> > > + reset-gpios = <&gpio 27 GPIO_ACTIVE_LOW>;
> > > + vdd-supply = <&pm8350c_l3>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&ts_d6_reset_assert &ts_d6_int_bias>;
> > > + input-report-header-address = <0x1000>;
> > > + input-report-body-address = <0x1004>;
> > > + output-report-address = <0x2000>;
> > > + read-opcode = <0x0b>;
> > > + write-opcode = <0x02>;
> > > + hid-over-spi-flags = <0x0000>;
> > > + post-power-on-delay-ms = <5>;
> > > + minimal-reset-delay-ms = <5>;
> > > + };
> > > + };
> > > \ No newline at end of file
> >
> > Fix this.
>
> Will fix this in v2.
>
> >
> > Rob
