The Versal NET clock controller compatible is specified as:
  compatible = "xlnx,versal-net-clk", "xlnx,versal-clk";

with xlnx,versal-clk listed as fallback. The original binding had
two separate if/then blocks - one matching xlnx,versal-clk (2 clocks)
and another matching xlnx,versal-net-clk (3 clocks). Since both
compatible strings are present, both conditions matched simultaneously
and JSON Schema applied the more restrictive 2-clock constraint,
causing false "too long" validation errors for Versal NET.

Restructure the allOf conditions to check for xlnx,versal-net-clk
first. If matched, allow 3 clocks (ref, pl_alt_ref, alt_ref).
Otherwise fall back to the xlnx,versal-clk case with 2 clocks
(ref, pl_alt_ref).

Add a dedicated example for the Versal NET 3-clock configuration
and split all examples into separate blocks so each compatible
variant is validated independently by dt_binding_check.

Signed-off-by: Michal Simek <michal.simek@amd.com>
---

 .../bindings/clock/xlnx,versal-clk.yaml       | 49 ++++++++++---------
 1 file changed, 27 insertions(+), 22 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml b/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml
index bef109d163a8..65d926d8f464 100644
--- a/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml
@@ -51,28 +51,7 @@ allOf:
       properties:
         compatible:
           contains:
-            enum:
-              - xlnx,versal-clk
-
-    then:
-      properties:
-        clocks:
-          items:
-            - description: reference clock
-            - description: alternate reference clock for programmable logic
-
-        clock-names:
-          items:
-            - const: ref
-            - const: pl_alt_ref
-
-  - if:
-      properties:
-        compatible:
-          contains:
-            enum:
-              - xlnx,versal-net-clk
-
+            const: xlnx,versal-net-clk
     then:
       properties:
         clocks:
@@ -86,6 +65,23 @@ allOf:
             - const: ref
             - const: pl_alt_ref
             - const: alt_ref
+    else:
+      if:
+        properties:
+          compatible:
+            contains:
+              const: xlnx,versal-clk
+      then:
+        properties:
+          clocks:
+            items:
+              - description: reference clock
+              - description: alternate reference clock for programmable logic
+
+          clock-names:
+            items:
+              - const: ref
+              - const: pl_alt_ref
 
   - if:
       properties:
@@ -135,6 +131,15 @@ examples:
       };
     };
 
+  - |
+    clock-controller {
+        #clock-cells = <1>;
+        compatible = "xlnx,versal-net-clk", "xlnx,versal-clk";
+        clocks = <&ref>, <&pl_alt_ref>, <&alt_ref>;
+        clock-names = "ref", "pl_alt_ref", "alt_ref";
+    };
+
+  - |
     clock-controller {
         #clock-cells = <1>;
         compatible = "xlnx,zynqmp-clk";
-- 
2.43.0

On Thu, Mar 05, 2026 at 04:39:49PM +0100, Michal Simek wrote:
> The Versal NET clock controller compatible is specified as:
>   compatible = "xlnx,versal-net-clk", "xlnx,versal-clk";
> 
> with xlnx,versal-clk listed as fallback. The original binding had
> two separate if/then blocks - one matching xlnx,versal-clk (2 clocks)
> and another matching xlnx,versal-net-clk (3 clocks). Since both
> compatible strings are present, both conditions matched simultaneously
> and JSON Schema applied the more restrictive 2-clock constraint,
> causing false "too long" validation errors for Versal NET.
> 
> Restructure the allOf conditions to check for xlnx,versal-net-clk
> first. If matched, allow 3 clocks (ref, pl_alt_ref, alt_ref).
> Otherwise fall back to the xlnx,versal-clk case with 2 clocks
> (ref, pl_alt_ref).
> 
> Add a dedicated example for the Versal NET 3-clock configuration
> and split all examples into separate blocks so each compatible
> variant is validated independently by dt_binding_check.

Really, the problem is xlnx,zynqmp-clk should be moved to its own 
schema. The only thing common is #clock-cells==1, but that would be true 
for hundreds of bindings. If you do that, then the clock-names can be 
defined at the top-level which is preferred anyway, and the only thing 
needed in if/then schemas is 'maxItems: 2' and 'minItems: 3'.

Rob