Add device tree support to the CMDQV driver to enable usage on Tegra264
SoCs. The implementation parses the nvidia,cmdqv phandle from the SMMU
device tree node to associate each SMMU with its corresponding CMDQV
instance based on compatible string.

Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 32 +++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index dad3c0cb800b..0cd0013200f3 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -4530,6 +4530,35 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu)
 	return 0;
 }
 
+#ifdef CONFIG_TEGRA241_CMDQV
+static void tegra_cmdqv_dt_probe(struct device_node *smmu_node,
+				 struct arm_smmu_device *smmu)
+{
+	struct platform_device *pdev;
+	struct device_node *np;
+
+	np = of_parse_phandle(smmu_node, "nvidia,cmdqv", 0);
+	if (!np)
+		return;
+
+	/* Tegra241 CMDQV driver is responsible for put_device() */
+	pdev = of_find_device_by_node(np);
+	of_node_put(np);
+	if (!pdev)
+		return;
+
+	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));
+}
+#else
+static void tegra_cmdqv_dt_probe(struct device_node *smmu_node,
+				 struct arm_smmu_device *smmu)
+{
+}
+#endif
+
 #ifdef CONFIG_ACPI
 #ifdef CONFIG_TEGRA241_CMDQV
 static void acpi_smmu_dsdt_probe_tegra241_cmdqv(struct acpi_iort_node *node,
@@ -4635,6 +4664,9 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev,
 	if (of_dma_is_coherent(dev->of_node))
 		smmu->features |= ARM_SMMU_FEAT_COHERENCY;
 
+	if (of_device_is_compatible(dev->of_node, "nvidia,tegra264-smmu"))
+		tegra_cmdqv_dt_probe(dev->of_node, smmu);
+
 	return ret;
 }
 
-- 
2.25.1

On 15/12/2025 06:48, Ashish Mhetre wrote:
> Add device tree support to the CMDQV driver to enable usage on Tegra264
> SoCs. The implementation parses the nvidia,cmdqv phandle from the SMMU
> device tree node to associate each SMMU with its corresponding CMDQV
> instance based on compatible string.
> 
> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
> Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
> ---
>   drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 32 +++++++++++++++++++++
>   1 file changed, 32 insertions(+)
> 
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index dad3c0cb800b..0cd0013200f3 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -4530,6 +4530,35 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu)
>   	return 0;
>   }
>   
> +#ifdef CONFIG_TEGRA241_CMDQV
> +static void tegra_cmdqv_dt_probe(struct device_node *smmu_node,
> +				 struct arm_smmu_device *smmu)
> +{
> +	struct platform_device *pdev;
> +	struct device_node *np;
> +
> +	np = of_parse_phandle(smmu_node, "nvidia,cmdqv", 0);
> +	if (!np)
> +		return;
> +
> +	/* Tegra241 CMDQV driver is responsible for put_device() */
> +	pdev = of_find_device_by_node(np);
> +	of_node_put(np);
> +	if (!pdev)
> +		return;
> +
> +	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?

> +}
> +#else
> +static void tegra_cmdqv_dt_probe(struct device_node *smmu_node,
> +				 struct arm_smmu_device *smmu)
> +{
> +}
> +#endif
> +
>   #ifdef CONFIG_ACPI
>   #ifdef CONFIG_TEGRA241_CMDQV
>   static void acpi_smmu_dsdt_probe_tegra241_cmdqv(struct acpi_iort_node *node,
> @@ -4635,6 +4664,9 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev,
>   	if (of_dma_is_coherent(dev->of_node))
>   		smmu->features |= ARM_SMMU_FEAT_COHERENCY;
>   
> +	if (of_device_is_compatible(dev->of_node, "nvidia,tegra264-smmu"))
> +		tegra_cmdqv_dt_probe(dev->of_node, smmu);
> +
>   	return ret;
>   }
>   

-- 
nvpublic

On 12/18/2025 2:13 AM, Jon Hunter wrote:
>
>
> On 15/12/2025 06:48, Ashish Mhetre wrote:
>> Add device tree support to the CMDQV driver to enable usage on Tegra264
>> SoCs. The implementation parses the nvidia,cmdqv phandle from the SMMU
>> device tree node to associate each SMMU with its corresponding CMDQV
>> instance based on compatible string.
>>
>> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
>> Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
>> ---
>>   drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 32 +++++++++++++++++++++
>>   1 file changed, 32 insertions(+)
>>
>> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c 
>> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>> index dad3c0cb800b..0cd0013200f3 100644
>> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>> @@ -4530,6 +4530,35 @@ static int arm_smmu_device_hw_probe(struct 
>> arm_smmu_device *smmu)
>>       return 0;
>>   }
>>   +#ifdef CONFIG_TEGRA241_CMDQV
>> +static void tegra_cmdqv_dt_probe(struct device_node *smmu_node,
>> +                 struct arm_smmu_device *smmu)
>> +{
>> +    struct platform_device *pdev;
>> +    struct device_node *np;
>> +
>> +    np = of_parse_phandle(smmu_node, "nvidia,cmdqv", 0);
>> +    if (!np)
>> +        return;
>> +
>> +    /* Tegra241 CMDQV driver is responsible for put_device() */
>> +    pdev = of_find_device_by_node(np);
>> +    of_node_put(np);
>> +    if (!pdev)
>> +        return;
>> +
>> +    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?

>> +}
>> +#else
>> +static void tegra_cmdqv_dt_probe(struct device_node *smmu_node,
>> +                 struct arm_smmu_device *smmu)
>> +{
>> +}
>> +#endif
>> +
>>   #ifdef CONFIG_ACPI
>>   #ifdef CONFIG_TEGRA241_CMDQV
>>   static void acpi_smmu_dsdt_probe_tegra241_cmdqv(struct 
>> acpi_iort_node *node,
>> @@ -4635,6 +4664,9 @@ static int arm_smmu_device_dt_probe(struct 
>> platform_device *pdev,
>>       if (of_dma_is_coherent(dev->of_node))
>>           smmu->features |= ARM_SMMU_FEAT_COHERENCY;
>>   +    if (of_device_is_compatible(dev->of_node, 
>> "nvidia,tegra264-smmu"))
>> +        tegra_cmdqv_dt_probe(dev->of_node, smmu);
>> +
>>       return ret;
>>   }
>

On 18/12/2025 06:32, Ashish Mhetre wrote:
> 
> On 12/18/2025 2:13 AM, Jon Hunter wrote:
>>
>>
>> On 15/12/2025 06:48, Ashish Mhetre wrote:
>>> Add device tree support to the CMDQV driver to enable usage on Tegra264
>>> SoCs. The implementation parses the nvidia,cmdqv phandle from the SMMU
>>> device tree node to associate each SMMU with its corresponding CMDQV
>>> instance based on compatible string.
>>>
>>> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
>>> Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
>>> ---
>>>   drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 32 +++++++++++++++++++++
>>>   1 file changed, 32 insertions(+)
>>>
>>> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/ 
>>> iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>>> index dad3c0cb800b..0cd0013200f3 100644
>>> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>>> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>>> @@ -4530,6 +4530,35 @@ static int arm_smmu_device_hw_probe(struct 
>>> arm_smmu_device *smmu)
>>>       return 0;
>>>   }
>>>   +#ifdef CONFIG_TEGRA241_CMDQV
>>> +static void tegra_cmdqv_dt_probe(struct device_node *smmu_node,
>>> +                 struct arm_smmu_device *smmu)
>>> +{
>>> +    struct platform_device *pdev;
>>> +    struct device_node *np;
>>> +
>>> +    np = of_parse_phandle(smmu_node, "nvidia,cmdqv", 0);
>>> +    if (!np)
>>> +        return;
>>> +
>>> +    /* Tegra241 CMDQV driver is responsible for put_device() */
>>> +    pdev = of_find_device_by_node(np);
>>> +    of_node_put(np);
>>> +    if (!pdev)
>>> +        return;
>>> +
>>> +    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.

Jon

-- 
nvpublic

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.

Nicolin

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.

Jon

-- 
nvpublic

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

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?

Thanks,
Ashish Mhetre

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

-- 
nvpublic

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