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

[Jie Luo <jie.luo@oss.qualcomm.com>]

On 10/9/2026 10:52 PM, sashiko-bot@kernel.org wrote:
> 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?
> 

dtschema already sets minItems/maxItems to the length of an items list,
No change needed.

>> +
>> +        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.
> 

No change is needed here either, for the same reason as above.

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

I will update it in the next version by matching all ethernet-port@
nodes and relying on the reg range limits.