[PATCH v3 1/6] dt-bindings: iommu: arm,smmu: Document interconnects property

[Bibek Kumar Patro]

On 7/6/2026 11:09 PM, Dmitry Baryshkov wrote:
> On Mon, Jul 06, 2026 at 10:26:34PM +0530, Bibek Kumar Patro wrote:
>> Some SoC implementations require a bandwidth vote on an interconnect
>> path before the SMMU register space is accessible. Add the optional
> 
> Why is it limited only to those SoCs? Is it also applicable to other
> Qualcomm SoCs?
> 

I was hoping to keep this series focused on the core infrastructure
changes: the bindings, base ICC bandwidth-voting support, and DT
interconnect properties for the platforms currently supported on
Qualcomm Linux and have been validated so far.

The additional targets have not been tested yet, so I'd prefer
to add their support in a separate follow-up series once validation
is complete, rather than growing this series further. WDYT?

>> 'interconnects' property to the binding to allow platform DT nodes
>> to describe this path.
>>
>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at oss.qualcomm.com>
>> Signed-off-by: Bibek Kumar Patro <bibek.patro at oss.qualcomm.com>
>> ---
>>   .../devicetree/bindings/iommu/arm,smmu.yaml        | 27 ++++++++++++++++++++++
>>   1 file changed, 27 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> index a701dec2fa0a..fab8944d7b63 100644
>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> @@ -246,6 +246,13 @@ properties:
>>       minItems: 1
>>       maxItems: 3
>>   
>> +  interconnects:
>> +    maxItems: 1
>> +    description:
>> +      Interconnect path to the SMMU register space. Required on SoCs
>> +      where the SMMU registers are only accessible after a bandwidth
>> +      vote has been placed on the interconnect fabric.
>> +
>>     nvidia,memory-controller:
>>       description: |
>>         A phandle to the memory controller on NVIDIA Tegra186 and later SoCs.
>> @@ -644,6 +651,26 @@ allOf:
>>           clock-names: false
>>           clocks: false
>>   
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          items:
>> +            - enum:
>> +                - qcom,qcs615-smmu-500
>> +                - qcom,qcs8300-smmu-500
>> +                - qcom,sa8775p-smmu-500
>> +                - qcom,sc7280-smmu-500
>> +            - const: qcom,adreno-smmu
>> +            - const: qcom,smmu-500
>> +            - const: arm,mmu-500
> 
> Can we be more idiomatic here?
> Something like:
> 
> if:
>    allOf:
>      - properties:
>          compatible:
>            contains:
>              enum:
>                - qcom,qcs615-smmu-500
>                - qcom,qcs8300-smmu-500
>                - qcom,sa8775p-smmu-500
>                - qcom,sc7280-smmu-500
>      - properties:
>          compatible:
>            contains:
>              const: qcom,adreno-smmu
> 
> In the end, we don't need to list the full list of compats. We need to
> specify that it's Adreno SMMU on one of the listed platforms.
> 

Agreed.
We need the interconnect property for any of the listed platform using
the adreno-smmu only.

Additionally in following e.g.

compatible = "qcom,adreno-smmu",
              "qcom,sc7280-smmu-500",
              "qcom,smmu-500",
              "arm,mmu-500",
              "qcom,new-string";

The current schema could miss enforcing the interconnect property
when new compatible strings are introduced, whereas the approach you
suggested continues to handle such cases correctly.

I'll update the binding accordingly in the next revision.

Thanks & regards,
Bibek


>