Re: [PATCH 2/5] dt-bindings: iommu: arm,smmu-v3: allow clocks

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] dt-bindings: iommu: arm,smmu-v3: unconstrained clocks property
--

commit 42a979d69e35794390e397c67d04e277f3c21933
Author: Arun Iyengar <aiyengar1990@gmail.com>

dt-bindings: iommu: arm,smmu-v3: allow clocks

This commit adds an optional clocks property allowing between one and four
clocks to the arm,smmu-v3 Devicetree binding schema.

> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> index c8f22dfdb1dbc..f8a74730667c8 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> @@ -63,6 +63,13 @@ properties:
>  
>    msi-parent: true
>  
> +  clocks:
> +    minItems: 1
> +    maxItems: 4
> +    description:
> +      Clocks needed to access the SMMU registers and to keep its translation
> +      units running, if they are not managed by firmware.

[Severity: Low]
Should clocks be constrained with an explicit items list, clock-names, or
implementation-specific compatible strings instead of allowing 1 to 4
unidentified clocks on the generic arm,smmu-v3 binding?

The SMMUv3 architecture does not define clock inputs, as clocks depend on
the specific implementation (such as MMU-600) and SoC integration.
Allowing up to four clocks without per-item descriptions or clock-names
(which is rejected by additionalProperties: false) leaves the clock
ordering and identity ambiguous whenever multiple clocks are present.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110-smmu-v3-pcie-pd-v1-0-628819ca44b9@gmail.com?part=2