Re: [PATCH v4 10/10] arm_mpam: detect and enable MPAM-Fb PCC support

On Fri, Jul 24, 2026 at 11:18:32AM +0100, Sudeep Holla wrote:

On Thu, Jul 23, 2026 at 05:54:54PM +0200, Andre Przywara wrote:

quoted

The Arm MPAM-Fb specification [1] describes a protocol to access MSC
registers through a firmware interface. This requires a shared memory
region to hold the message, and a mailbox to trigger the access.
For ACPI this is wrapped as a PCC channel, described using existing
ACPI abstractions.

Add code to parse those PCC table descriptions associated with an MSC,
and store the parsed information in the MSC struct.
There can be multiple PCC channels, and each channel can serve multiple
MSCs, so we need to keep track of the channel usage, using a list and
a refcount.
This will be used by the MPAM-Fb access wrapper code.

[1] https://developer.arm.com/documentation/den0144/latest

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/acpi/arm64/mpam.c      |   6 +-
 drivers/resctrl/mpam_devices.c | 127 ++++++++++++++++++++++++++++++++-
 2 files changed, 129 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/arm64/mpam.c b/drivers/acpi/arm64/mpam.c
index 84963a20c3e7..ca9b8754ae5f 100644
--- a/drivers/acpi/arm64/mpam.c
+++ b/drivers/acpi/arm64/mpam.c

@@ -220,8 +220,8 @@ static struct platform_device * __init acpi_mpam_parse_msc(struct acpi_mpam_msc_
 	struct platform_device *pdev __free(platform_device_put) =
 		platform_device_alloc("mpam_msc", tbl_msc->identifier);

Looks like tbl_msc->identifier is getting stashed as pdev->id...

quoted

 	int next_res = 0, next_prop = 0, err;
-	/* pcc, nrdy, affinity and a sentinel */
-	struct property_entry props[4] = { 0 };
+	/* pcc, msc-id, nrdy, affinity and a sentinel */
+	struct property_entry props[5] = { 0 };
 	/* mmio, 2xirq, no sentinel. */
 	struct resource res[3] = { 0 };
 	struct acpi_device *companion;

@@ -256,6 +256,8 @@ static struct platform_device * __init acpi_mpam_parse_msc(struct acpi_mpam_msc_
 	} else if (iface == MPAM_IFACE_PCC) {
 		props[next_prop++] = PROPERTY_ENTRY_U32("pcc-channel",
 							tbl_msc->base_address);
+		props[next_prop++] = PROPERTY_ENTRY_U32("msc-id",
+							tbl_msc->identifier);

Why is this needed then as you can fetch it as pdev->id ?

I suppose it is to have properties parity between OF and ACPI without
having to change the driver property parsing path.

Lorenzo