Re: [PATCH v5 1/4] dt-bindings: pci: Strictly distinguish C0 from C1-C5

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `oneOf` conditional branches for C0 and C1-C5 controllers fail to specify `minItems` and `maxItems` for `reg` and `reg-names`, allowing incorrect array lengths to pass schema validation.
--

commit e94ac7315673fefb739d35acd2b3406eaf80cdbc
Author: Thierry Reding <treding@nvidia.com>

dt-bindings: pci: Strictly distinguish C0 from C1-C5

This commit strictly distinguishes the C0 controller from the C1-C5
controllers in the Tegra264 PCIe binding. It updates the register lists
and names for each variant under an allOf oneOf block to match the
hardware correctly.

> diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> index dc4f8725c9f59..acb677d477fb3 100644
> --- a/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
[ ... ]
>  properties:
>    compatible:
>      const: nvidia,tegra264-pcie
>  
>    reg:
>      minItems: 4
> +    maxItems: 5
>  
>    reg-names:
>      minItems: 4
> +    maxItems: 5
[ ... ]
> @@ -70,6 +61,40 @@ required:
>  
>  allOf:
>    - $ref: /schemas/pci/pci-host-bridge.yaml#
> +  - oneOf:
> +      - description: C0 controller (no UPHY)
> +        properties:
> +          reg:
> +            items:
> +              - description: application layer registers
> +              - description: transaction layer registers
> +              - description: privileged transaction layer registers
> +              - description: ECAM compatible configuration space
> +
> +          reg-names:
> +            items:
> +              - const: xal
> +              - const: xtl
> +              - const: xtl-pri
> +              - const: ecam

[Severity: Medium]
Will this schema fully enforce the register counts for each variant?

Since JSON schema tuple validation only evaluates elements present up to the
length of the instance array, it does not enforce bounds on the length unless
minItems and maxItems are explicitly provided in these conditional branches.

Because the top-level schema permits minItems: 4 and maxItems: 5, a C0 node
providing 5 registers might incorrectly pass validation against the C0 branch.
The first 4 items match the items list, the 5th item is unconstrained by the
C0 branch, and the array satisfies the top-level maxItems: 5.

Similarly, a C1-C5 node providing only 4 registers could pass the C1-C5
branch below. The 5th constraint would never be evaluated on a 4-item array,
and the array would satisfy the top-level minItems: 4.

Should explicit minItems: 4 and maxItems: 4 be added to the C0 properties
block, along with minItems: 5 and maxItems: 5 for the C1-C5 properties block,
to ensure the strict distinction mentioned in the commit message?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260526-tegra264-pcie-v5-0-84a813b979d7@nvidia.com?part=1