Re: [PATCH v3 3/5] Documentation: DT bindings for HID over SPI.

[Rob Herring <robh@xxxxxxxxxx>]

On Fri, Jan 14, 2022 at 06:31:33PM -0800, Dmitry Antipov wrote:
> From: Dmitry Antipov <dmanti@xxxxxxxxxxxxx>
> 
> Added documentation describes the required properties for implementing
> Device Tree for a device supporting HID over SPI and also provides an
> example.

Bindings are in DT schema format now.

> 
> Signed-off-by: Dmitry Antipov <dmanti@xxxxxxxxxxxxx>
> ---
>  .../bindings/input/hid-over-spi.txt           | 43 +++++++++++++++++++
>  1 file changed, 43 insertions(+)
>  create mode 100755 Documentation/devicetree/bindings/input/hid-over-spi.txt
> 
> diff --git a/Documentation/devicetree/bindings/input/hid-over-spi.txt b/Documentation/devicetree/bindings/input/hid-over-spi.txt
> new file mode 100755
> index 000000000000..5eba95b5724e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/hid-over-spi.txt
> @@ -0,0 +1,43 @@
> +* HID over SPI Device-Tree bindings
> +
> +HID over SPI provides support for Human Interface Devices over the SPI bus. HID
> +Over SPI Protocol Specification 1.0 was written by Microsoft and is available at
> +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

What's a kernel module? ;) Bindings are OS independent (or supposed to 
be), so kernel details do not belong here.

> +with the device and the generic hid core layer will handle the protocol.
> +
> +Required properties:
> +- compatible: must be "hid-over-spi"

Bindings describe devices, not protocols. There is no such 
'hid-over-spi' device. Please see the existing hid-over-i2c binding. 
It's fine to have this compatible, but only as a fallback compatible.

> +- interrupts: interrupt line
> +- vdd-supply: phandle of the regulator that provides the supply voltage

What happens when the device has 2 supplies? And there's some timing 
requirement between them?

> +- reset_gpio-gpios: gpio wired to the device reset line

'reset-gpios' is the standard name.

> +- post-power-on-delay-ms: time required by the device after enabling its
> +regulators or powering it on, before it is ready for communication 
> +- minimal-reset-delay-ms: minimum amount of time that device needs to be in
> +reset state for the reset to take effect

These properties are what happens when we try to do generic bindings. 
It's a never-ending addition of more properties to try to describe 
(poorly) the power sequencing requirements.

> +- input-report-header-address: this property and the rest are described in HID
> +Over SPI Protocol Spec 1.0
> +- input-report-body-address
> +- output-report-address
> +- read-opcode
> +- write-opcode
> +- flags

A bit too generic. We generally want to avoid having a property name 
with 2 different types/meaning. It's not something we check for yet, but 
I plan to at some point.

> +
> +Example:
> +	spi-hid-dev0 {
> +		compatible = "hid-over-spi";
> +		reg = <0>;
> +		interrupts-extended = <&tlmm 42 IRQ_TYPE_EDGE_FALLING>;
> +		vdd-supply = <&pm8350c_l3>;
> +		input-report-header-address = <0x1000>;
> +		input-report-body-address = <0x1004>;
> +		output-report-address = <0x2000>;
> +		read-opcode = <0x0b>;
> +		write-opcode = <0x02>;
> +		flags = <0x00>;
> +		reset_gpio-gpios = <&tlmm 25 GPIO_ACTIVE_LOW>;
> +		post-power-on-delay-ms = <5>;
> +		minimal-reset-delay-ms = <5>;
> +		
> +	};
> -- 
> 2.25.1
> 
>