[PATCH] dt-bindings: input: syna,rmi4: Allow incell supply

Sony Xperia Tama boards describe an incell-supply regulator on
Synaptics RMI4 touch controllers.

Add incell-supply to the converted binding so those existing
touchscreen nodes validate.

Assisted-by: LLM
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
---
 Documentation/devicetree/bindings/input/syna,rmi4.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/input/syna,rmi4.yaml b/Documentation/devicetree/bindings/input/syna,rmi4.yaml
index fb4804ac3544..464c83ece418 100644
--- a/Documentation/devicetree/bindings/input/syna,rmi4.yaml
+++ b/Documentation/devicetree/bindings/input/syna,rmi4.yaml

@@ -56,6 +56,7 @@ properties:
 
   vdd-supply: true
   vio-supply: true
+  incell-supply: true
 
   rmi4-f01@1:
     type: object

-- 
2.53.0

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dt-bindings: legitimize OS-specific fw_devlink hack in hardware schema
--

commit 18108c1337c210aa2101238d8a2bf5d5648f3f22
Author: Rob Herring (Arm) [off-list ref]

dt-bindings: input: syna,rmi4: Allow incell supply

This commit adds the incell-supply property to the Synaptics RMI4 touch
controller device tree binding. It is intended to allow existing Sony Xperia
Tama board device tree nodes to pass schema validation.

[Severity: Medium]
Does adding this property to the generic hardware schema violate device tree
design principles by formalizing an OS-specific software workaround?

Device tree bindings are typically expected to strictly describe actual
hardware. The user of this property is the Sony Xperia Tama board
configuration, which acknowledges it as a workaround:

arch/arm64/boot/dts/qcom/sdm845-sony-xperia-tama.dtsi:
        /*
         * This is a blatant abuse of OF, but the panel driver *needs*
         * to probe first, as the power/gpio switching needs to be precisely
         * timed in order for both the display and touch panel to function properly.
         */
        incell-supply = <&panel>;

Since the device tree source explicitly documents this as a mechanism to force
fw_devlink probe ordering between the panel and the touch controller, should
we avoid spoofing a fake hardware property in the official schema?

Would it be better to address the probe sequence dependency properly instead
of institutionalizing this workaround into the formal hardware schema?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260921232738.3135429-1-robh@kernel.org?part=1

On Mon, Sep 21, 2026 at 11:34:06PM +0000, sashiko-bot@kernel.org wrote:

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dt-bindings: legitimize OS-specific fw_devlink hack in hardware schema
--

commit 18108c1337c210aa2101238d8a2bf5d5648f3f22
Author: Rob Herring (Arm) [off-list ref]

dt-bindings: input: syna,rmi4: Allow incell supply

This commit adds the incell-supply property to the Synaptics RMI4 touch
controller device tree binding. It is intended to allow existing Sony Xperia
Tama board device tree nodes to pass schema validation.

quoted

diff --git a/Documentation/devicetree/bindings/input/syna,rmi4.yaml b/Documentation/devicetree/bindings/input/syna,rmi4.yaml
index fb4804ac3544d..464c83ece4186 100644
--- a/Documentation/devicetree/bindings/input/syna,rmi4.yaml
+++ b/Documentation/devicetree/bindings/input/syna,rmi4.yaml

@@ -56,6 +56,7 @@ properties:
 
   vdd-supply: true
   vio-supply: true
+  incell-supply: true

[Severity: Medium]
Does adding this property to the generic hardware schema violate device tree
design principles by formalizing an OS-specific software workaround?

Device tree bindings are typically expected to strictly describe actual
hardware. The user of this property is the Sony Xperia Tama board
configuration, which acknowledges it as a workaround:

arch/arm64/boot/dts/qcom/sdm845-sony-xperia-tama.dtsi:
        /*
         * This is a blatant abuse of OF, but the panel driver *needs*
         * to probe first, as the power/gpio switching needs to be precisely
         * timed in order for both the display and touch panel to function properly.
         */
        incell-supply = <&panel>;

Since the device tree source explicitly documents this as a mechanism to force
fw_devlink probe ordering between the panel and the touch controller, should
we avoid spoofing a fake hardware property in the official schema?

Would it be better to address the probe sequence dependency properly instead
of institutionalizing this workaround into the formal hardware schema?

Oh dear, do we actually want to merge this?