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

[sashiko-bot@kernel.org]

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) <robh@kernel.org>

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.

> 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?

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