Re: [PATCH v2] dt-bindings: arm-smmu: Constrain clocks for newer Qualcomm variants

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Omission of AP variants allows invalid clock properties to pass validation.
- [High] Missing clock constraints for `hawi` and `kaanapali` Adreno SMMU variants.
- [Medium] Redundant and logically contradictory schema constraints for `sm6350`, `sm6375`, and `eliza`.
--

commit c2f0647af32a181995cc73fd00080208d48cecd5
Author: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

dt-bindings: arm-smmu: Constrain clocks for newer Qualcomm variants

This commit updates the arm,smmu.yaml binding to add missing clock
constraints for several Qualcomm SMMUs. It specifically targets variants
that share a front compatible string but have different fallback compatibles,
restricting the clocks property where appropriate.

> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> index 06fb5c8e7547c..ed0d10157bd61 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> @@ -566,7 +566,9 @@ allOf:
>        properties:
>          compatible:
>            items:
> -            - const: qcom,sm8750-smmu-500
> +            - enum:
> +                - qcom,glymur-smmu-500

Does this regression omit clock constraints for qcom,hawi-smmu-500 and
qcom,kaanapali-smmu-500 here?

These compatibles are explicitly defined in the top-level schema as Adreno GPU
SMMUs, yet neither appears in any conditional block that validates Adreno
clocks and clock-names.

Without this, when these are used as Adreno GPU SMMUs, the schema will accept
any arbitrary 1-7 clocks without validating the clock names, leaving schema
validation incomplete for these devices.

> +                - qcom,sm8750-smmu-500
>              - const: qcom,adreno-smmu
>              - const: qcom,smmu-500
>              - const: arm,mmu-500

[ ... ]

> @@ -602,6 +605,39 @@ allOf:
>          clock-names: false
>          clocks: false
>  
> +  # Disallow clocks for all other platforms where specific compatible is used
> +  # with different fallbacks and only one combination has no clocks
> +  - if:
> +      properties:
> +        compatible:
> +          items:
> +            - enum:
> +                - qcom,eliza-smmu-500

Does this regression introduce redundant constraints for eliza, sm6350, and
sm6375 in this block?

The newly added block explicitly targets platforms where specific compatibles
are used with different fallbacks.

The Adreno variants for sm6350 and sm6375 use the arm,smmu-v2 fallback. Their
-smmu-500 compatibles are exclusively used for APs and are already
unconditionally constrained by the preceding contains-based block.

Similarly, qcom,eliza-smmu-500 lacks an Adreno variant in the schema entirely
and could be added to the preceding unconditional block instead.

> +                - qcom,glymur-smmu-500
> +                - qcom,kaanapali-smmu-500
> +                - qcom,milos-smmu-500
> +                - qcom,qcs615-smmu-500
> +                - qcom,qcs8300-smmu-500
> +                - qcom,sa8775p-smmu-500
> +                - qcom,sm6115-smmu-500
> +                - qcom,sm6125-smmu-500
> +                - qcom,sm6350-smmu-500
> +                - qcom,sm6375-smmu-500
> +                - qcom,sm8150-smmu-500
> +                - qcom,sm8250-smmu-500
> +                - qcom,sm8350-smmu-500
> +                - qcom,sm8450-smmu-500
> +                - qcom,sm8550-smmu-500
> +                - qcom,sm8650-smmu-500
> +                - qcom,sm8750-smmu-500
> +                - qcom,x1e80100-smmu-500

Does this regression omit other AP variants from this new block?

Several SoCs share this identical pattern of sharing a front compatible with
Adreno GPU SMMUs: qcom,qcm2290-smmu-500, qcom,sar2130p-smmu-500,
qcom,sc7280-smmu-500, qcom,sc8180x-smmu-500, qcom,sc8280xp-smmu-500, and
qcom,hawi-smmu-500.

Because they are missing from the disallow list, their AP variants are not
properly restricted. For qcm2290, sar2130p, and hawi, their clocks remain
entirely unconstrained.

For sc7280, sc8180x, and sc8280xp, their AP nodes will hit existing
contains-based conditional blocks intended for their GPUs, meaning schema
validation will incorrectly allow their AP nodes to specify GPU clocks.

> +            - const: qcom,smmu-500
> +            - const: arm,mmu-500
> +    then:
> +      properties:
> +        clock-names: false
> +        clocks: false

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260519074113.61464-2-krzysztof.kozlowski@oss.qualcomm.com?part=1