[PATCH 0/3] arm-smmu-v3: Add PMCG child support and update PMU MMIO mapping

[PATCH 0/3] arm-smmu-v3: Add PMCG child support and update PMU MMIO mapping

[Peng Fan (OSS)]

This patch series adds proper support for describing and probing the
Arm SMMU v3 PMCG (Performance Monitor Control Group) as a child node of
the SMMU in Devicetree, and updates the relevant drivers accordingly.

The SMMU v3 architecture allows an optional PMCG block, typically
associated with TCUs, to be implemented within the SMMU register
address space. For example, mmu700 PMCG is at the offset 0x2000 of the
TCU page 0.

Patch 1 updates the SMMU v3 Devicetree binding to allow PMCG child nodes,
referencing the existing arm,smmu-v3-pmcg binding.

Patch 2 updates the arm-smmu-v3 driver to populate platform devices for
child nodes described in DT once the SMMU probe succeeds.

Patch 3 updates the SMMUv3 PMU driver to correctly handle MMIO mapping when
PMCG is described as a child node. The PMCG registers occupy a sub-region
of the parent SMMU MMIO window, which is already requested by the SMMU

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Peng Fan (3):
      dt-bindings: iommu: arm-smmu-v3: Allow PMU child nodes
      iommu/arm-smmu-v3: Populate PMU child devices from Devicetree
      perf/arm-smmuv3: Avoid double-requesting shared SMMU MMIO for PMCG

 .../devicetree/bindings/iommu/arm,smmu-v3.yaml        | 10 ++++++++++
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c           |  3 +++
 drivers/perf/arm_smmuv3_pmu.c                         | 19 ++++++++++++++++---
 3 files changed, 29 insertions(+), 3 deletions(-)
---
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
change-id: 20260408-smmu-perf-754367fe66c8

Best regards,
-- 
Peng Fan <peng.fan@nxp.com>

[PATCH 1/3] dt-bindings: iommu: arm-smmu-v3: Allow PMU child nodes

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

The Arm SMMU v3 specification defines an optional PMCG (Performance
Monitor Control Group) block. Per MMU-700 TRM, it has three 64KB pages,
with TCU Performance Monitor Counter Group (PMCG) registers starting at
offset 0x02000 in page 0. So PMCG could be described as a child node of the
SMMU in Devicetree.

Add a patternProperties entry to the arm,smmu-v3 binding to allow child
nodes matching "pmu@<addr>" and reference the existing
arm,smmu-v3-pmcg.yaml schema.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
index 82957334bea24402b583e47eb61b5724c91e4378..1d09c5476e5f1a7c3e5c935b677641ee6cc9897e 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
@@ -50,6 +50,10 @@ properties:
             - cmdq-sync   # CMD_SYNC complete
             - priq        # PRI Queue not empty
 
+  '#address-cells': true
+  '#size-cells': true
+  ranges: true
+
   '#iommu-cells':
     const: 1
 
@@ -83,6 +87,12 @@ properties:
       register access with page 0 offsets. Set for Cavium ThunderX2 silicon that
       doesn't support SMMU page1 register space.
 
+patternProperties:
+  '^pmu@[0-9a-f]+$':
+    type: object
+    $ref: /schemas/perf/arm,smmu-v3-pmcg.yaml#
+    unevaluatedProperties: false
+
 allOf:
   - if:
       not:

-- 
2.37.1

[PATCH 2/3] iommu/arm-smmu-v3: Populate PMU child devices from Devicetree

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

The Arm SMMU v3 can expose optional child devices such as the PMCG-based
PMU, which are described as child nodes in Devicetree. While the binding
allows these nodes, the driver did not populate them, preventing the
corresponding platform devices from being created.

Call devm_of_platform_populate() after a successful SMMU DT probe to
instantiate any child nodes associated with the SMMU device.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 +++
 1 file changed, 3 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 e8d7dbe495f0302191c3c7ec4c6d7564062f6236..0ce1d41c5ba6864ccad8291551f7f5c91c27b3db 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -5363,6 +5363,9 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev,
 	if (of_device_is_compatible(dev->of_node, "nvidia,tegra264-smmu"))
 		tegra_cmdqv_dt_probe(dev->of_node, smmu);
 
+	if (!ret)
+		return devm_of_platform_populate(dev);
+
 	return ret;
 }
 

-- 
2.37.1

Re: [PATCH 2/3] iommu/arm-smmu-v3: Populate PMU child devices from Devicetree

[sashiko-bot]

Sashiko AI review found 1 potential issue(s):
- [High] Premature population of child devices before the parent SMMU is initialized.
--

commit b6188437ce3fc797b1e6f4d35f8ab59a8362fd98
Author: Peng Fan <peng.fan@nxp.com>

iommu/arm-smmu-v3: Populate PMU child devices from Devicetree

This commit populates optional child devices of the Arm SMMU v3,
such as the PMCG-based PMU, by instantiating them during the device
tree probe phase.

> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -5363,6 +5363,9 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev,
>  	if (of_device_is_compatible(dev->of_node, "nvidia,tegra264-smmu"))
>  		tegra_cmdqv_dt_probe(dev->of_node, smmu);
>  
> +	if (!ret)
> +		return devm_of_platform_populate(dev);

Will calling devm_of_platform_populate() this early cause the child
platform devices to be probed before the parent SMMU is fully
initialized?

If a child device depends on the parent being fully set up, might it
fail since arm_smmu_device_dt_probe() is called early in the parent's
probe sequence, before IO memory is mapped, hardware is initialized, or
platform_set_drvdata() is called?

Additionally, if a subsequent step in the parent's probe returns
-EPROBE_DEFER, will this result in unnecessary probing and immediate
devres teardown of the child devices?

Would it be safer to defer populating the child devices until the end
of arm_smmu_device_probe() after the parent SMMU has successfully
initialized?

> +
>  	return ret;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260408-smmu-perf-v1-0-d75dac96e828@nxp.com?part=2

[PATCH 3/3] perf/arm-smmuv3: Avoid double-requesting shared SMMU MMIO for PMCG

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

The PMCG is described as a child device of the SMMU in Devicetree and
its register space occupies a sub-region of the parent SMMU MMIO window.
That MMIO region is already requested by the arm-smmu-v3 driver during
SMMU probe.

Using devm_platform_get_and_ioremap_resource() or
devm_platform_ioremap_resource() for the PMCG would attempt to request
the same memory region again and fail with -EBUSY.

Switch to explicitly retrieving the PMCG memory resources and mapping
them with devm_ioremap(), avoiding double-requesting already owned SMMU
MMIO while preserving correct register offsets for both page 0 and the
optional relocated counter page.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 drivers/perf/arm_smmuv3_pmu.c | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
index 621f02a7f43be364e5c260fd97aa375f5e8e3404..1c9585ef2618397b59158aa18c21054ef672dc83 100644
--- a/drivers/perf/arm_smmuv3_pmu.c
+++ b/drivers/perf/arm_smmuv3_pmu.c
@@ -847,7 +847,7 @@ static void smmu_pmu_get_iidr(struct smmu_pmu *smmu_pmu)
 static int smmu_pmu_probe(struct platform_device *pdev)
 {
 	struct smmu_pmu *smmu_pmu;
-	struct resource *res_0;
+	struct resource *res_0, *res_1;
 	u32 cfgr, reg_size;
 	u64 ceid_64[2];
 	int irq, err;
@@ -877,7 +877,16 @@ static int smmu_pmu_probe(struct platform_device *pdev)
 		.capabilities	= PERF_PMU_CAP_NO_EXCLUDE,
 	};
 
-	smmu_pmu->reg_base = devm_platform_get_and_ioremap_resource(pdev, 0, &res_0);
+	res_0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res_0)
+		return dev_err_probe(dev, -ENOENT, "missing PMCG page 0 MMIO resource\n");
+
+	/*
+	 * PMCG registers might be a sub-region of the parent SMMU MMIO window,
+	 * which is already requested by the SMMU driver. Do not call
+	 * devm_ioremap_resource() here to avoid double-requesting the region.
+	 */
+	smmu_pmu->reg_base = devm_ioremap(dev, res_0->start, resource_size(res_0));
 	if (IS_ERR(smmu_pmu->reg_base))
 		return PTR_ERR(smmu_pmu->reg_base);
 
@@ -885,7 +894,11 @@ static int smmu_pmu_probe(struct platform_device *pdev)
 
 	/* Determine if page 1 is present */
 	if (cfgr & SMMU_PMCG_CFGR_RELOC_CTRS) {
-		smmu_pmu->reloc_base = devm_platform_ioremap_resource(pdev, 1);
+		res_1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+		if (!res_1)
+			return dev_err_probe(dev, -ENOENT, "missing PMCG page 1 MMIO resource\n");
+
+		smmu_pmu->reloc_base = devm_ioremap(dev, res_1->start, resource_size(res_1));
 		if (IS_ERR(smmu_pmu->reloc_base))
 			return PTR_ERR(smmu_pmu->reloc_base);
 	} else {

-- 
2.37.1

Re: [PATCH 3/3] perf/arm-smmuv3: Avoid double-requesting shared SMMU MMIO for PMCG

[sashiko-bot]

Sashiko AI review found 1 potential issue(s):
- [High] Incorrect error checking for `devm_ioremap()` return value leads to potential NULL pointer dereference.
--

commit 9648b36d883f07ba004ca17984ae1bfebc0a29df
Author: Peng Fan <peng.fan@nxp.com>

perf/arm-smmuv3: Avoid double-requesting shared SMMU MMIO for PMCG

This commit maps the PMCG memory resources directly using devm_ioremap
to avoid double-requesting the SMMU MMIO space that is already requested
by the arm-smmu-v3 driver.

> diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
> index 621f02a7f43be..1c9585ef26183 100644
> --- a/drivers/perf/arm_smmuv3_pmu.c
> +++ b/drivers/perf/arm_smmuv3_pmu.c

[ ... ]

> @@ -877,7 +877,16 @@ static int smmu_pmu_probe(struct platform_device *pdev)
>  		.capabilities	= PERF_PMU_CAP_NO_EXCLUDE,
>  	};
>  
> -	smmu_pmu->reg_base = devm_platform_get_and_ioremap_resource(pdev, 0, &res_0);
> +	res_0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (!res_0)
> +		return dev_err_probe(dev, -ENOENT, "missing PMCG page 0 MMIO resource\n");
> +
> +	/*
> +	 * PMCG registers might be a sub-region of the parent SMMU MMIO window,
> +	 * which is already requested by the SMMU driver. Do not call
> +	 * devm_ioremap_resource() here to avoid double-requesting the region.
> +	 */
> +	smmu_pmu->reg_base = devm_ioremap(dev, res_0->start, resource_size(res_0));
>  	if (IS_ERR(smmu_pmu->reg_base))
>  		return PTR_ERR(smmu_pmu->reg_base);

Since devm_ioremap returns NULL on failure instead of an ERR_PTR, will this
IS_ERR check fail to catch unsuccessful mappings?

If devm_ioremap returns NULL, IS_ERR(NULL) evaluates to false, which would
allow the code to proceed and potentially dereference a NULL pointer shortly
after when reading cfgr.

Would it be better to check for !smmu_pmu->reg_base here and return
-ENOMEM?

>  
> @@ -885,7 +894,11 @@ static int smmu_pmu_probe(struct platform_device *pdev)
>  
>  	/* Determine if page 1 is present */
>  	if (cfgr & SMMU_PMCG_CFGR_RELOC_CTRS) {
> -		smmu_pmu->reloc_base = devm_platform_ioremap_resource(pdev, 1);
> +		res_1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> +		if (!res_1)
> +			return dev_err_probe(dev, -ENOENT, "missing PMCG page 1 MMIO resource\n");
> +
> +		smmu_pmu->reloc_base = devm_ioremap(dev, res_1->start, resource_size(res_1));
>  		if (IS_ERR(smmu_pmu->reloc_base))
>  			return PTR_ERR(smmu_pmu->reloc_base);

This appears to have the same issue. Does this IS_ERR check also need to be
updated to handle a NULL return from devm_ioremap?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260408-smmu-perf-v1-0-d75dac96e828@nxp.com?part=3

Re: [PATCH 0/3] arm-smmu-v3: Add PMCG child support and update PMU MMIO mapping

[Robin Murphy]

On 2026-04-08 8:51 am, Peng Fan (OSS) wrote:
> This patch series adds proper support for describing and probing the
> Arm SMMU v3 PMCG (Performance Monitor Control Group) as a child node of
> the SMMU in Devicetree, and updates the relevant drivers accordingly.
> 
> The SMMU v3 architecture allows an optional PMCG block, typically
> associated with TCUs, to be implemented within the SMMU register
> address space. For example, mmu700 PMCG is at the offset 0x2000 of the
> TCU page 0.

But what's wrong with the existing binding? Especially given that it 
even has an upstream user already:

https://git.kernel.org/torvalds/c/aef9703dcbf8

> Patch 1 updates the SMMU v3 Devicetree binding to allow PMCG child nodes,
> referencing the existing arm,smmu-v3-pmcg binding.
> 
> Patch 2 updates the arm-smmu-v3 driver to populate platform devices for
> child nodes described in DT once the SMMU probe succeeds.
> 
> Patch 3 updates the SMMUv3 PMU driver to correctly handle MMIO mapping when
> PMCG is described as a child node. The PMCG registers occupy a sub-region
> of the parent SMMU MMIO window, which is already requested by the SMMU

That has not been the case since 52f3fab0067d ("iommu/arm-smmu-v3: Don't 
reserve implementation defined register space") nearly 6 years ago, 
where the whole purpose was to support Arm's PMCG implementation 
properly. What kernel is this based on?

Thanks,
Robin.

> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> Peng Fan (3):
>        dt-bindings: iommu: arm-smmu-v3: Allow PMU child nodes
>        iommu/arm-smmu-v3: Populate PMU child devices from Devicetree
>        perf/arm-smmuv3: Avoid double-requesting shared SMMU MMIO for PMCG
> 
>   .../devicetree/bindings/iommu/arm,smmu-v3.yaml        | 10 ++++++++++
>   drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c           |  3 +++
>   drivers/perf/arm_smmuv3_pmu.c                         | 19 ++++++++++++++++---
>   3 files changed, 29 insertions(+), 3 deletions(-)
> ---
> base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
> change-id: 20260408-smmu-perf-754367fe66c8
> 
> Best regards,

Re: [PATCH 0/3] arm-smmu-v3: Add PMCG child support and update PMU MMIO mapping

[Peng Fan]

On Wed, Apr 08, 2026 at 12:15:31PM +0100, Robin Murphy wrote:
>On 2026-04-08 8:51 am, Peng Fan (OSS) wrote:
>> This patch series adds proper support for describing and probing the
>> Arm SMMU v3 PMCG (Performance Monitor Control Group) as a child node of
>> the SMMU in Devicetree, and updates the relevant drivers accordingly.
>> 
>> The SMMU v3 architecture allows an optional PMCG block, typically
>> associated with TCUs, to be implemented within the SMMU register
>> address space. For example, mmu700 PMCG is at the offset 0x2000 of the
>> TCU page 0.
>
>But what's wrong with the existing binding? Especially given that it even has
>an upstream user already:
>
>https://git.kernel.org/torvalds/c/aef9703dcbf8
>
>> Patch 1 updates the SMMU v3 Devicetree binding to allow PMCG child nodes,
>> referencing the existing arm,smmu-v3-pmcg binding.
>> 
>> Patch 2 updates the arm-smmu-v3 driver to populate platform devices for
>> child nodes described in DT once the SMMU probe succeeds.
>> 
>> Patch 3 updates the SMMUv3 PMU driver to correctly handle MMIO mapping when
>> PMCG is described as a child node. The PMCG registers occupy a sub-region
>> of the parent SMMU MMIO window, which is already requested by the SMMU
>
>That has not been the case since 52f3fab0067d ("iommu/arm-smmu-v3: Don't
>reserve implementation defined register space") nearly 6 years ago, where the
>whole purpose was to support Arm's PMCG implementation properly. What kernel
>is this based on?

Seems I am wrong. I thought PMCG is in page 0, so there were resource
conflicts. I just retest without this patchset, all goes well.

But from dt perspective, should the TCU PMCG node be child node of
SMMU node?

Thanks,
Peng

>
>Thanks,
>Robin.
>
>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>> ---
>> Peng Fan (3):
>>        dt-bindings: iommu: arm-smmu-v3: Allow PMU child nodes
>>        iommu/arm-smmu-v3: Populate PMU child devices from Devicetree
>>        perf/arm-smmuv3: Avoid double-requesting shared SMMU MMIO for PMCG
>> 
>>   .../devicetree/bindings/iommu/arm,smmu-v3.yaml        | 10 ++++++++++
>>   drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c           |  3 +++
>>   drivers/perf/arm_smmuv3_pmu.c                         | 19 ++++++++++++++++---
>>   3 files changed, 29 insertions(+), 3 deletions(-)
>> ---
>> base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
>> change-id: 20260408-smmu-perf-754367fe66c8
>> 
>> Best regards,
>
>