Re: [PATCH net-next 03/11] dt-bindings: net: qcom,ipq9574-ppe: Add IPQ5424 PPE support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] dt-bindings: missing minItems/maxItems in conditionals allows incorrect array lengths
- [Low] dt-bindings: incomplete ethernet-ports restriction allows out-of-bounds ports
--

commit dead4fe7fe0227c2a98000bdee56dfba287669d7
Author: Luo Jie <jie.luo@oss.qualcomm.com>

dt-bindings: net: qcom,ipq9574-ppe: Add IPQ5424 PPE support

This commit adds the IPQ5424 compatible to the IPQ9574 PPE binding. It
describes the interconnect paths for each SoC and limits the Ethernet ports
for IPQ5424 to ports 1-3.

> diff --git a/Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml b/Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml
> --- a/Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml
> +++ b/Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml
[ ... ]
> @@ -236,6 +233,62 @@ required:
>  
>  allOf:
>    - $ref: ethernet-switch.yaml
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: qcom,ipq9574-ppe
> +    then:
> +      properties:
> +        interconnects:
> +          items:
> +            - description: Bus interconnect path leading to PPE switch core function
> +            - description: Bus interconnect path leading to PPE register access
> +            - description: Bus interconnect path leading to QoS generation
> +            - description: Bus interconnect path leading to timeout reference
> +            - description: Bus interconnect path leading to NSS NOC from memory NOC
> +            - description: Bus interconnect path leading to memory NOC from NSS NOC
> +            - description: Bus interconnect path leading to enhanced memory NOC from NSS NOC

[Severity: Medium]
Does this array need explicit minItems and maxItems to strictly enforce the
length?

According to standard JSON Schema rules, an items array inside a conditional
block validates the matching indices but does not enforce the array length
unless minItems and maxItems are explicitly declared. 

Since the global schema allows minItems: 5, could an incomplete IPQ9574
node with only 5 interconnects falsely pass validation here?

> +
> +        interconnect-names:
> +          items:
> +            - const: ppe
> +            - const: ppe_cfg
> +            - const: qos_gen
> +            - const: timeout_ref
> +            - const: nssnoc_memnoc
> +            - const: memnoc_nssnoc
> +            - const: memnoc_nssnoc_1
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: qcom,ipq5424-ppe
> +    then:
> +      properties:
> +        interconnects:
> +          items:
> +            - description: Bus interconnect path leading to PPE switch core function
> +            - description: Bus interconnect path leading to PPE register access
> +            - description: Bus interconnect path leading to CE AXI
> +            - description: Bus interconnect path leading to CE APB
> +            - description: Bus interconnect path leading to NSS CSR access

[Severity: Medium]
Similarly, should minItems and maxItems be explicitly set to 5 here?

Without these limits, an IPQ5424 node could declare 7 interconnects and pass
because it satisfies the global maxItems: 7 constraint, leaving the trailing
2 elements unchecked.

> +
> +        interconnect-names:
> +          items:
> +            - const: ppe
> +            - const: ppe_cfg
> +            - const: nssnoc_ce_axi
> +            - const: nssnoc_ce_apb
> +            - const: nssnoc_nss_csr
> +
> +        ethernet-ports:
> +          patternProperties:
> +            "^ethernet-port@[1-3]$":
> +              properties:
> +                reg:
> +                  maximum: 3
> +            "^ethernet-port@[4-6]$": false

[Severity: Low]
Does this workaround fully restrict the out-of-bounds ports for IPQ5424?

The top-level ethernet-ports container lacks an unevaluatedProperties: false
constraint. Because ethernet-switch.yaml (included via allOf) dynamically
matches any port matching ^(ethernet-)?port@[0-9a-f]+$ as a generic object,
out-of-bounds nodes like ethernet-port@7 would pass ethernet-switch.yaml's
checks.

Since this block explicitly sets ^ethernet-port@[4-6]$: false but does not
cap the container itself, will ports 7 and above silently pass schema
validation?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261008-qcom_ipq5424_ppe-v1-0-16caf43e44ee@oss.qualcomm.com?part=3