On 07/01/2026 06:44, Ashish Mhetre wrote:

On 12/20/2025 12:19 AM, Nicolin Chen wrote:

quoted

On Fri, Dec 19, 2025 at 10:48:22AM +0000, Jon Hunter wrote:

quoted

On 18/12/2025 18:57, Nicolin Chen wrote:

quoted

On Thu, Dec 18, 2025 at 08:48:32AM +0000, Jon Hunter wrote:

quoted

On 18/12/2025 06:32, Ashish Mhetre wrote:

quoted

On 12/18/2025 2:13 AM, Jon Hunter wrote:

quoted

quoted

+    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

-- 
nvpublic