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

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

[Krzysztof Kozlowski]

Many of SMMU on Qualcomm SoCs come in two flavors using the same front
compatible but a bit different fallback:

1. For application processor, usually without any controllable
   clocks,

2. For the Adreno GPU, with some controllable clock(s) and using
   additionally qcom,adreno-smmu fallback compatible.

Add missing constraints for Glymur SMMU on Adreno GPU and several other
Qualcomm SMMUs for application processors, to restrict the clocks
property to a specific length.

Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

---

Changes in v2:
1. Tags
2. Fix grammar in commit msg
---
 .../devicetree/bindings/iommu/arm,smmu.yaml   | 38 ++++++++++++++++++-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index 06fb5c8e7547..ed0d10157bd6 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
+                - qcom,sm8750-smmu-500
             - const: qcom,adreno-smmu
             - const: qcom,smmu-500
             - const: arm,mmu-500
@@ -595,6 +597,7 @@ allOf:
               - qcom,sdm845-smmu-500
               - qcom,sdx55-smmu-500
               - qcom,sdx65-smmu-500
+              - qcom,sdx75-smmu-500
               - qcom,sm6350-smmu-500
               - qcom,sm6375-smmu-500
     then:
@@ -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
+                - 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
+            - const: qcom,smmu-500
+            - const: arm,mmu-500
+    then:
+      properties:
+        clock-names: false
+        clocks: false
+
   - if:
       properties:
         compatible:
-- 
2.51.0

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

[Krzysztof Kozlowski]

Many of SMMU on Qualcomm SoCs come in two flavors using the same front
compatible but a bit different fallback:

1. For application processor, usually without any controllable
   clocks,

2. For the Adreno GPU, with some controllable clock(s) and using
   additionally qcom,adreno-smmu fallback compatible.

Add missing constraints for Glymur SMMU on Adreno GPU and several other
Qualcomm SMMUs for application processors, to restrict the clocks
property to a specific length.

Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

---

Changes in v2:
1. Tags
2. Fix grammar in commit msg
---
 .../devicetree/bindings/iommu/arm,smmu.yaml   | 38 ++++++++++++++++++-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index 06fb5c8e7547..ed0d10157bd6 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
+                - qcom,sm8750-smmu-500
             - const: qcom,adreno-smmu
             - const: qcom,smmu-500
             - const: arm,mmu-500
@@ -595,6 +597,7 @@ allOf:
               - qcom,sdm845-smmu-500
               - qcom,sdx55-smmu-500
               - qcom,sdx65-smmu-500
+              - qcom,sdx75-smmu-500
               - qcom,sm6350-smmu-500
               - qcom,sm6375-smmu-500
     then:
@@ -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
+                - 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
+            - const: qcom,smmu-500
+            - const: arm,mmu-500
+    then:
+      properties:
+        clock-names: false
+        clocks: false
+
   - if:
       properties:
         compatible:
-- 
2.51.0

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

[Krzysztof Kozlowski]

On 19/05/2026 09:41, Krzysztof Kozlowski wrote:
> Many of SMMU on Qualcomm SoCs come in two flavors using the same front
> compatible but a bit different fallback:
> 
> 1. For application processor, usually without any controllable
>    clocks,
> 
> 2. For the Adreno GPU, with some controllable clock(s) and using
>    additionally qcom,adreno-smmu fallback compatible.
> 
> Add missing constraints for Glymur SMMU on Adreno GPU and several other
> Qualcomm SMMUs for application processors, to restrict the clocks
> property to a specific length.
> 
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
> Reviewed-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> 
> ---

Apologies, that's a duplicated posting.

Best regards,
Krzysztof

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The new conditional block disallowing clocks for Application Processor SMMUs omits `qcom,qcm2290-smmu-500`, `qcom,sar2130p-smmu-500`, `qcom,sc7280-smmu-500`, `qcom,sc8180x-smmu-500`, and `qcom,sc8280xp-smmu-500`.
- [Low] Redundant schema constraints for `qcom,sm6350-smmu-500` and `qcom,sm6375-smmu-500`.
--

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

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

This commit adds missing constraints for the glymur variant and several
other qualcomm application processor variants to restrict the clocks
property.

> 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
[ ... ]
> @@ -595,6 +597,7 @@ allOf:
>                - qcom,sdm845-smmu-500
>                - qcom,sdx55-smmu-500
>                - qcom,sdx65-smmu-500
> +              - qcom,sdx75-smmu-500
>                - qcom,sm6350-smmu-500
>                - qcom,sm6375-smmu-500
>      then:
> @@ -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
> +                - qcom,glymur-smmu-500
> +                - qcom,kaanapali-smmu-500

Are there a few application processor variants missing from this new block?

It looks like qcom,qcm2290-smmu-500, qcom,sar2130p-smmu-500,
qcom,sc7280-smmu-500, qcom,sc8180x-smmu-500, and qcom,sc8280xp-smmu-500
also share this two-flavor pattern.

Without them included here, will device tree nodes specifying clocks for
these variants silently pass schema validation?

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

This isn't a bug, but are these two variants redundant here?

Since qcom,sm6350-smmu-500 and qcom,sm6375-smmu-500 are already listed
in the previous block to unconditionally enforce clocks as false, does
adding them to this more specific fallback block have any additional effect?

> +                - qcom,sm8150-smmu-500
> +                - qcom,sm8250-smmu-500
[ ... ]

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

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

[sashiko-bot]

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

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

[Krzysztof Kozlowski]

On 19/05/2026 09:57, sashiko-bot@kernel.org wrote:
>>  
>> +  # 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
>> +                - qcom,glymur-smmu-500
>> +                - qcom,kaanapali-smmu-500
> 
> Are there a few application processor variants missing from this new block?
> 
> It looks like qcom,qcm2290-smmu-500, qcom,sar2130p-smmu-500,
> qcom,sc7280-smmu-500, qcom,sc8180x-smmu-500, and qcom,sc8280xp-smmu-500
> also share this two-flavor pattern.

false positive, these have clocks.

> 
> Without them included here, will device tree nodes specifying clocks for
> these variants silently pass schema validation?
> 
>> +                - 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
> 
> This isn't a bug, but are these two variants redundant here?
> 
> Since qcom,sm6350-smmu-500 and qcom,sm6375-smmu-500 are already listed
> in the previous block to unconditionally enforce clocks as false, does
> adding them to this more specific fallback block have any additional effect?

Ack, I will send v3.


Best regards,
Krzysztof

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

[Krzysztof Kozlowski]

On 19/05/2026 10:00, sashiko-bot@kernel.org wrote:
> 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?

Kaanapali I can add, for Hawi I have no public data. I can try to dig it
somewhere...

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



Best regards,
Krzysztof

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

[Will Deacon]

On Tue, 19 May 2026 09:41:00 +0200, Krzysztof Kozlowski wrote:
> Many of SMMU on Qualcomm SoCs come in two flavors using the same front
> compatible but a bit different fallback:
> 
> 1. For application processor, usually without any controllable
>    clocks,
> 
> 2. For the Adreno GPU, with some controllable clock(s) and using
>    additionally qcom,adreno-smmu fallback compatible.
> 
> [...]

!! Please note: this conflicted with the Glymur GPU bindings update. That
   was trivial to fix, but I've also queued an update adding
   "qcom,shikra-smmu-500" which you may want in your list of platforms
   where clocks are disallowed?

Applied to iommu (arm/smmu/bindings), thanks!

[1/1] dt-bindings: arm-smmu: Constrain clocks for newer Qualcomm variants
      https://git.kernel.org/iommu/c/75949eb02653

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev

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

[Krzysztof Kozlowski]

On 19/05/2026 17:23, Will Deacon wrote:
> On Tue, 19 May 2026 09:41:00 +0200, Krzysztof Kozlowski wrote:
>> Many of SMMU on Qualcomm SoCs come in two flavors using the same front
>> compatible but a bit different fallback:
>>
>> 1. For application processor, usually without any controllable
>>    clocks,
>>
>> 2. For the Adreno GPU, with some controllable clock(s) and using
>>    additionally qcom,adreno-smmu fallback compatible.
>>
>> [...]
> 
> !! Please note: this conflicted with the Glymur GPU bindings update. That
>    was trivial to fix, but I've also queued an update adding
>    "qcom,shikra-smmu-500" which you may want in your list of platforms
>    where clocks are disallowed?
> 

Thanks, I will double check and send a followup if needed.

Best regards,
Krzysztof