Re: [PATCH v6 1/3] dt-bindings: input: touchscreen: st,stmfts: Introduce STM FTS5
From: sashiko-bot@kernel.org
Date: 2026-09-06 16:40:16
Also in:
linux-devicetree
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 [off-list ref]
dt-bindings: input: touchscreen: st,stmfts: Introduce STM FTS5
Introduce more recent STM FTS5 touchscreen support.
quoted hunk ↗ jump to hunk
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
[ ... ]
quoted hunk ↗ jump to hunk
@@ -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.
quoted hunk ↗ jump to hunk
+ 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