linux-kernel - Re: [PATCH 2/3] dt-bindings: iommu: Add NVIDIA Tegra CMDQV support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <bb87c493-bf4d-4f6b-9327-f07aa61c81d5@nvidia.com>
Date: Fri, 21 Nov 2025 11:16:48 +0530
From: Ashish Mhetre <amhetre@...dia.com>
To: Robin Murphy <robin.murphy@....com>, Krzysztof Kozlowski
 <krzk@...nel.org>, will@...nel.org
Cc: joro@...tes.org, robh@...nel.org, krzk+dt@...nel.org,
 conor+dt@...nel.org, thierry.reding@...il.com, jonathanh@...dia.com,
 jgg@...pe.ca, nicolinc@...dia.com, linux-tegra@...dia.com,
 linux-arm-kernel@...ts.infradead.org, iommu@...ts.linux.dev,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-tegra@...r.kernel.org
Subject: Re: [PATCH 2/3] dt-bindings: iommu: Add NVIDIA Tegra CMDQV support


On 11/20/2025 3:53 PM, Robin Murphy wrote:
> External email: Use caution opening links or attachments
>
>
> On 2025-11-20 6:07 am, Ashish Mhetre wrote:
>>
>> On 11/3/2025 7:24 PM, Ashish Mhetre wrote:
>>>
>>> On 10/31/2025 1:44 PM, Krzysztof Kozlowski wrote:
>>>> External email: Use caution opening links or attachments
>>>>
>>>>
>>>> On Fri, Oct 31, 2025 at 06:29:58AM +0000, Ashish Mhetre wrote:
>>>>> The Command Queue Virtualization (CMDQV) hardware is part of the
>>>>> SMMUv3 implementation on NVIDIA Tegra SoCs. It assists in
>>>>> virtualizing the command queue for the SMMU.
>>>> If this is specific to Nvidia, then I think you need specific front
>>>> compatible and disallow it for other vendors.
>>>
>>> Yes, CMDQV is specific to Nvidia. There isn't currently a 
>>> vendor-specific
>>> compatible for Nvidia's arm,smmu-v3 implementation. Would it be
>>> acceptable
>>> to document this as Nvidia-specific in the description? Or can we add a
>>> new Nvidia-specific compatible string like "nvidia,smmu-v3" if that's
>>> preferred and use conditional schema to restrict the property?
>>
>> Hi Will, Robin,
>>
>> Do you have any suggestions on this? I have followed existing ACPI 
>> approach
>> for implementing DT support.
>
> No, the way the ACPI binding is implemented has the lookup going *from*
> the CMDQV node back to the SMMU instance (via the matching identifier) -
> this is entirely the opposite. The literal DT equivalent would be to use
> for_each_matching_node/for_each_compatible_node to scan the CMDQV nodes
> for a property indicating the relevant SMMU.
>
> I'm not hugely fussed either way though - since the fact is the Tegra234
> SMMU does have this custom modification, a specific
> "nvidia,tegra234-smmu", "arm,smmu-v3" compatible isn't inappropriate,
> even if it really doesn't make any difference to architectural SMMU
> operation without awareness of the other CMDQV nodes.
>
> Thanks,
> Robin.
>

Thanks for the suggestions Robin. Approach 2 is much simpler with current
implementation I have. I will proceed with adding Nvidia specific compatible
string "nvidia,tegra264-smmu", "arm,smmu-v3" in V2.

>> Will it be fine to add separate compatible
>> string
>> for Nvidia Tegra264 SMMU to restrict the usage of CMDQV?
>>
>>>>> Add a new device tree binding document for nvidia,tegra264-cmdqv.
>>>>>
>>>>> Also update the arm,smmu-v3 binding to include an optional 
>>>>> nvidia,cmdqv
>>>>> property. This property is a phandle to the CMDQV device node, 
>>>>> allowing
>>>>> the SMMU driver to associate with its corresponding CMDQV instance.
>>>>>
>>>>> Signed-off-by: Ashish Mhetre <amhetre@...dia.com>
>>>>> ---
>>>>>   .../bindings/iommu/arm,smmu-v3.yaml           | 10 ++++
>>>>>   .../bindings/iommu/nvidia,tegra264-cmdqv.yaml | 46 +++++++++++++++
>>>>> ++++
>>>>>   2 files changed, 56 insertions(+)
>>>>>   create mode 100644 Documentation/devicetree/bindings/iommu/
>>>>> nvidia,tegra264-cmdqv.yaml
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-
>>>>> v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
>>>>> index 75fcf4cb52d9..edc0c20a0c80 100644
>>>>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
>>>>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
>>>>> @@ -58,6 +58,15 @@ properties:
>>>>>
>>>>>     msi-parent: true
>>>>>
>>>>> +  nvidia,cmdqv:
>>>>> +    description: |
>>>>> +      A phandle to its pairing CMDQV extension for an
>>>>> implementation on NVIDIA
>>>>> +      Tegra SoC.
>>>>> +
>>>>> +      If this property is absent, CMDQ-Virtualization won't be used
>>>>> and SMMU
>>>>> +      will only use its own CMDQ.
>>>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>>>> +
>>>>>     hisilicon,broken-prefetch-cmd:
>>>>>       type: boolean
>>>>>       description: Avoid sending CMD_PREFETCH_* commands to the SMMU.
>>>>> @@ -92,4 +101,5 @@ examples:
>>>>>               dma-coherent;
>>>>>               #iommu-cells = <1>;
>>>>>               msi-parent = <&its 0xff0000>;
>>>>> +            nvidia,cmdqv = <&cmdqv>;
>>>>>       };
>>>>> diff --git a/Documentation/devicetree/bindings/iommu/
>>>>> nvidia,tegra264-cmdqv.yaml b/Documentation/devicetree/bindings/
>>>>> iommu/nvidia,tegra264-cmdqv.yaml
>>>>> new file mode 100644
>>>>> index 000000000000..f22c370278a3
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/iommu/nvidia,tegra264-
>>>>> cmdqv.yaml
>>>>> @@ -0,0 +1,46 @@
>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>> +%YAML 1.2
>>>>> +---
>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>> +
>>>>> +title: NVIDIA Tegra264 CMDQV
>>>> Missing blank line
>>>
>>> Ack, I will correct this in V2.
>>>>> +description: |
>>>> Do not need '|' unless you need to preserve formatting.
>>>
>>> Okay, I'll remove this in next version.
>>>>> +  The CMDQ-Virtualization hardware block is part of the SMMUv3
>>>>> implementation
>>>>> +  on Tegra264 SoCs. It assists in virtualizing the command queue
>>>>> for the SMMU.
>>>>> +
>>>>> +maintainers:
>>>>> +  - NVIDIA Corporation <linux-tegra@...dia.com>
>>>> No. It should be a person. If entire Nvidia cannot find a person, I
>>>> don't think we are interested in having this in the kernel.
>>>
>>> Okay, I'll add Nicolin as maintainer.
>>>>> +
>>>>> +properties:
>>>>> +  compatible:
>>>>> +    const: nvidia,tegra264-cmdqv
>>>>> +
>>>>> +  reg:
>>>>> +    maxItems: 1
>>>>> +
>>>>> +  interrupts:
>>>>> +    maxItems: 1
>>>>> +
>>>>> +  interrupt-names:
>>>>> +    items:
>>>>> +      - const: cmdqv
>>>> Drop interript names, obvious.
>>>
>>> Sure, I will update in V2.
>>>>> +
>>>>> +required:
>>>>> +  - compatible
>>>>> +  - reg
>>>>> +  - interrupts
>>>>> +  - interrupt-names
>>>>> +
>>>>> +additionalProperties: false
>>>>> +
>>>>> +examples:
>>>>> +  - |
>>>>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>>> +    #include <dt-bindings/interrupt-controller/irq.h>
>>>>> +
>>>>> +    cmdqv: cmdqv@...5200000 {
>>>> Drop unused label
>>>
>>> Okay, I will remove the label.
>>>> Best regards,
>>>> Krzysztof
>>>>