Re: [PATCH v6 1/3] dt-bindings: input: touchscreen: st,stmfts: Introduce STM FTS5

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The `if` condition matching the `compatible` property against `st,stmfts5` incorrectly uses `const` instead of `contains: const`, breaking the conditional logic and improperly forbidding `mode-switch-gpios` for the new variant.
- [Medium] The patch contains undocumented modifications to the existing `st,stmfts` device tree example and file structure.
--

commit b15460ebf5a9b2a2c1695b3d9fb6f5007a3c46e1
Author: David Heidelberg <david@ixit.cz>

dt-bindings: input: touchscreen: st,stmfts: Introduce STM FTS5
    
Introduce more recent STM FTS5 touchscreen support.

> diff --git a/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.yaml b/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.yaml
> index 64c4f24ea3dd0..3de4bc5cd3f78 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.yaml
> +++ b/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.yaml
[ ... ]
> @@ -51,6 +54,17 @@ required:
>    - interrupts
>    - vdd-supply
>  
> +allOf:
> +  - $ref: touchscreen.yaml#
> +  - if:
> +      not:
> +        properties:
> +          compatible:
> +            const: st,stmfts5

[Severity: Medium]
In Device Tree json-schema representation, the compatible property evaluates
as an array of strings. Does this use of const: instead of contains: const:
incorrectly compare the array to a single string?

Since the comparison would always evaluate to false, the not condition negates
this to true, which means the then clause is always applied. This appears to
incorrectly enforce mode-switch-gpios: false for all devices, breaking the
schema validation for the new st,stmfts5 variant.

> +    then:
> +      properties:
> +        mode-switch-gpios: false
> +
>  unevaluatedProperties: false
>  
>  examples:
> @@ -64,10 +78,9 @@ examples:
>          touchscreen@49 {
>              compatible = "st,stmfts";
>              reg = <0x49>;
> -            interrupt-parent = <&gpa1>;
> -            interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
> -            touchscreen-size-x = <1599>;
> -            touchscreen-size-y = <2559>;
> +            interrupts-extended = <&gpa1 1 IRQ_TYPE_LEVEL_LOW>;
> +            touchscreen-size-x = <1600>;
> +            touchscreen-size-y = <2560>;

[Severity: Medium]
Are these modifications to the existing st,stmfts example and the earlier
restructuring of the allOf block missing from the commit message?

The commit message explicitly states only that it introduces STM FTS5
touchscreen support. While migrating to interrupts-extended and changing the
touchscreen size might be valid cleanups, they are undocumented side-effects
and likely should be explicitly mentioned in the commit message to justify
the changes.

>              touch-key-connected;
>              avdd-supply = <&ldo30_reg>;
>              vdd-supply = <&ldo31_reg>;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260906-stmfts5-v6-0-50fbf6af8718@ixit.cz?part=1