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

[Sudeep Holla]

On Mon, Jul 27, 2026 at 02:48:47PM +0200, Lorenzo Pieralisi wrote:
> 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:
> > > 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 at 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...
> > 
> > 
> > >  	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.
> 

Yes, that was my initial thought as well. However, after looking into it
further, I could not find any device tree bindings in the upstream tree.
I am therefore unsure whether MPAM is supported on DT platforms.

The use of these device properties appears to have been based on DT bindings
that may never have been upstreamed. As [1] suggests, the bindings were
dropped before the initial merge.

Although we could rename these properties later to align with any DT bindings
that are introduced, I think it would be preferable to avoid adding new
properties unless they are strictly necessary.

-- 
Regards,
Sudeep

[1] https://lore.kernel.org/all/20251107123450.664001-1-ben.horgan@arm.com/