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

Oh dear, do we actually want to merge this?