Re: [PATCH v2 2/2] dt-bindings: firmware: xilinx: Add conditional pinctrl schema

[Rob Herring <robh@kernel.org>]

On Fri, Dec 12, 2025 at 02:05:42AM -0800, Ronak Jain wrote:
> Updates the Device Tree bindings for Xilinx firmware by introducing
> conditional schema references for the pinctrl node.
> 
> Previously, the pinctrl node directly referenced
> xlnx,zynqmp-pinctrl.yaml. However, this patch modifies the schema to
> conditionally apply the correct pinctrl schema based on the compatible
> property. Specifically:
> - If compatible contains "xlnx,zynqmp-pinctrl", reference
>   xlnx,zynqmp-pinctrl.yaml.
> - If compatible contains "xlnx,versal-pinctrl", reference
>   xlnx,versal-pinctrl.yaml.
> 
> Additionally, an example entry for "xlnx,versal-pinctrl" has been
> added under the examples section.
> 
> Signed-off-by: Ronak Jain <ronak.jain@amd.com>
> ---
> Suggestion from Rob:
> 
> The somewhat preferred way to do this would be to do this in the top
> level:
> 
> pinctrl:
>   type: object
>   additionalProperties: true
>   properties:
>     compatible:
>       contains:
>         enum:
>           - xlnx,zynqmp-pinctrl
>           - xlnx,versal-pinctrl
>   required:
>     - compatible
> 
> Otherwise, the pinctrl schema ends up being applied twice.
> 
> 
> My response:
> 
> In your suggested code, the schema allows either xlnx,zynqmp-pinctrl
> or xlnx,versal-pinctrl on any platform, which is incorrect. This
> means that if a user mistakenly assigns xlnx,versal-pinctrl to a
> ZynqMP platform or xlnx,zynqmp-pinctrl to a Versal platform, the
> wrong reference will be used, but no error is reported. The
> dt-binding check still passes instead of flagging this as an issue.

True, but you can create a whole DT that's just random bindings from all 
sorts of different SoCs and the schema validation would be perfectly 
happy. We can't really ever check everything.

> By using a conditional schema, we can enforce platform-specific
> compatibility, ensuring that the correct compatible string is used
> for the corresponding platform. This would also generate an error if
> an incorrect compatible string is provided, preventing
> misconfigurations.

But what you have is fine too. It will validate the node twice as I 
pointed out and that slows things down some, but it's already slow...

Rob