linux-kernel - Re: [PATCH V7 2/4] iommu/arm-smmu-v3: Add device-tree support for CMDQV driver

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: <c8686af9-775e-45bd-bfde-25f995b59ac2@nvidia.com>
Date: Tue, 13 Jan 2026 10:42:02 +0530
From: Ashish Mhetre <amhetre@...dia.com>
To: Jon Hunter <jonathanh@...dia.com>, Nicolin Chen <nicolinc@...dia.com>
Cc: will@...nel.org, robin.murphy@....com, joro@...tes.org, robh@...nel.org,
 krzk+dt@...nel.org, conor+dt@...nel.org, thierry.reding@...il.com,
 vdumpa@...dia.com, jgg@...pe.ca, 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 V7 2/4] iommu/arm-smmu-v3: Add device-tree support for
 CMDQV driver



On 1/9/2026 3:15 PM, Jon Hunter wrote:
>
> On 07/01/2026 06:44, Ashish Mhetre wrote:
>>
>>
>> On 12/20/2025 12:19 AM, Nicolin Chen wrote:
>>> On Fri, Dec 19, 2025 at 10:48:22AM +0000, Jon Hunter wrote:
>>>> On 18/12/2025 18:57, Nicolin Chen wrote:
>>>>> On Thu, Dec 18, 2025 at 08:48:32AM +0000, Jon Hunter wrote:
>>>>>> On 18/12/2025 06:32, Ashish Mhetre wrote:
>>>>>>> On 12/18/2025 2:13 AM, Jon Hunter wrote:
>>>>>>>>> +    smmu->impl_dev = &pdev->dev;
>>>>>>>>> +    smmu->options |= ARM_SMMU_OPT_TEGRA241_CMDQV;
>>>>>>>>> +    dev_info(smmu->dev, "found companion CMDQV device: %s\n",
>>>>>>>>> +         dev_name(smmu->impl_dev));
>>>>>>>> This seems a bit noisy. dev_dbg?
>>>>>>>>
>>>>>>> This info print is similar to what is there in ACPI path as well.
>>>>>>> It's only a single print per SMMU at boot time. Should I still 
>>>>>>> change
>>>>>>> it to dev_dbg?
>>>>>> Yes, I would.
>>>>> It's really not that bad IMHO, I am not against that though..
>>>>>
>>>>> If we have to change that, we'd need another patch changing the
>>>>> one in the ACPI path as well to keep things aligned.
>>>> Regardless of what is already present, does not mean we need add 
>>>> more prints
>>>> to just say everything is OK.
>>> This is how it looks like for each instance probe():
>>>
>>> [    2.709269] arm-smmu-v3 arm-smmu-v3.10.auto: found companion 
>>> CMDQV device: NVDA200C:00
>>> [    2.709273] arm-smmu-v3 arm-smmu-v3.10.auto: option mask 0x10
>>> [    2.709618] arm-smmu-v3 arm-smmu-v3.10.auto: ias 48-bit, oas 
>>> 48-bit (features 0x001e1fbf)
>>> [    2.716236] arm-smmu-v3 arm-smmu-v3.10.auto: allocated 524288 
>>> entries for cmdq
>>> [    2.719432] arm-smmu-v3 arm-smmu-v3.10.auto: allocated 524288 
>>> entries for evtq
>>> [    2.725898] arm-smmu-v3 arm-smmu-v3.10.auto: allocated 524288 
>>> entries for priq
>>> [    2.736051] arm-smmu-v3 arm-smmu-v3.10.auto: allocated 524288 
>>> entries for vcmdq0
>>> [    2.742553] arm-smmu-v3 arm-smmu-v3.10.auto: allocated 524288 
>>> entries for vcmdq1
>>> [    2.742586] arm-smmu-v3 arm-smmu-v3.10.auto: msi_domain absent - 
>>> falling back to wired irqs
>>> [    2.742759] arm-smmu-v3 arm-smmu-v3.10.auto: no priq irq - PRI 
>>> will be broken
>>>
>>> On a second thought: The CMDQV device has a very unclear naming in
>>> ACPI path: "NVDA200C:00". So, printing it gives us a hint for any
>>> later warning/error tagged with "NVDA200C:00".
>>>
>>> Now, for DT, it might be okay to not print it. But making the two
>>> paths asymmetric feels odd. So, is it really worth nitpicking here
>>> given that each SMMU already prints quite a few lines on probe()?
>>>
>>> Nicolin
>>
>> Hi Jon, Nic,
>>
>> Shall I keep this print or send a new version removing it?
>
> Make it dev_dbg() and you can always enable it if you want it. 99.9% 
> of the time you will not need this.
>
> Thanks!
> Jon
>

Ack, I'll update this in next version.

Thanks,
Ashish Mhetre