Re: [PATCH 2/4] dt-bindings: input: edt-ft5x06 - add no-regmap-bulk-read property

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `no-regmap-bulk-read` property violates OS-agnostic Device Tree design principles by embedding Linux-specific software terminology and misplacing parent bus limitations into a child node.
--

--- Patch [2]: [PATCH 2/4] dt-bindings: input: edt-ft5x06 - add no-regmap-bulk-read property ---
commit adbbdf0f113c3cd899e582907d5e795b5a3a7cc7
Author: Alexandre Hamamdjian <azkali.limited@gmail.com>

dt-bindings: input: edt-ft5x06 - add no-regmap-bulk-read property

This commit documents an optional boolean property, no-regmap-bulk-read, for
boards where the I2C controller cannot reliably sustain multi-byte block reads.
It instructs the driver to read the touch frame one register at a time instead
of using a bulk transfer.

> diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> index 68b2f16016543..0d8310a290ea5 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> @@ -111,6 +111,14 @@ properties:
>  
>    interrupt-controller: true
>  
> +  no-regmap-bulk-read:
> +    type: boolean
> +    description:
> +      Set this when the i2c controller the touch controller is attached to
> +      cannot reliably sustain the multi-byte block read of a full touch
> +      frame and aborts long transfers. The driver then reads the touch
> +      frame one register at a time instead of in a single bulk transfer.

[Severity: Medium]
Does this property violate OS-agnostic Device Tree design principles? The
property name uses Linux-specific internal software terminology ("regmap")
and the description explicitly dictates driver implementation behavior rather
than describing the hardware layout.

Additionally, is it appropriate to model a limitation of the parent I2C
controller inside the child touch controller's device node? This appears to
misplace parent bus limitations into a child node. Should this quirk perhaps
be handled at the I2C controller level or expressed in a more hardware-centric,
OS-agnostic way?

> +
>  unevaluatedProperties: false
>  
>  required:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260723-b4-ft5426-v1-0-d4b4e32be042@gmail.com?part=2