Re: [PATCH v6 1/3] dt-bindings: input: Add Himax HX83102J touchscreen

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] dt-bindings: Redundant required shared resources for TDDI chip
- [Low] dt-bindings: Missing maxItems constraint on firmware-name
--

commit 08e7a44d4b27dca463d90889398954bf0cfaff49
Author: Michał Kopeć <michal@nozomi.space>

dt-bindings: input: Add Himax HX83102J touchscreen

This commit adds the device tree binding for the touch function of the
Himax HX83102J, a TDDI controller. The display and touch functions share
analog supplies and reset lines, which power up together with the panel.

> diff --git a/Documentation/devicetree/bindings/input/touchscreen/himax,hx83102j.yaml b/Documentation/devicetree/bindings/input/touchscreen/himax,hx83102j.yaml
> new file mode 100644
> index 0000000000000..f0aca7a6662c9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/himax,hx83102j.yaml
[ ... ]
> +  display-reset-gpios:
> +    maxItems: 1
> +    description:
> +      Reset of the display function, usually driven by the panel. Asserting
> +      it also resets the touch function.
> +
> +  spi-cpha: true
> +
> +  spi-cpol: true
> +
> +  firmware-name:
> +    description: Specify the file name for firmware loading.

[Severity: Low]
Should this include a maxItems constraint? Since dtschema implicitly
evaluates this property as a string array, omitting a constraint like
maxItems: 1 allows device trees providing an array of multiple strings
for the firmware name to silently pass dt_binding_check.

> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - reset-gpios
> +  - panel
> +  - vccd-supply
> +  - vsn-supply
> +  - vsp-supply
> +  - display-reset-gpios

[Severity: Medium]
Since this is a TDDI chip and the driver utilizes the drm_panel_follower API
to coordinate power and reset with the panel, do we need to strictly require
vsn-supply, vsp-supply, and display-reset-gpios in the touchscreen node?

Requiring these alongside the panel phandle forces device tree authors to
duplicate the physical resource definitions (the exact same physical pins
and regulators) in both the panel and touch nodes, which might lead to probe
failures (-EBUSY) if drivers attempt to parse them natively.

Would it be better to remove these shared resources from the required list or
make them optional, deferring resource management entirely to the panel node?

> +
> +unevaluatedProperties: false
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261011181633.1778969-1-michal@nozomi.space?part=1