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: <aUWeUapsFo3KZP7i@Asurada-Nvidia>
Date: Fri, 19 Dec 2025 10:49:53 -0800
From: Nicolin Chen <nicolinc@...dia.com>
To: Jon Hunter <jonathanh@...dia.com>
CC: Ashish Mhetre <amhetre@...dia.com>, <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 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