All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: Sudeep Holla <sudeep.holla@kernel.org>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Hanjun Guo <guohanjun@huawei.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Len Brown <lenb@kernel.org>, James Morse <james.morse@arm.com>,
	Ben Horgan <ben.horgan@arm.com>,
	Reinette Chatre <reinette.chatre@intel.com>,
	Fenghua Yu <fenghuay@nvidia.com>,
	Jonathan Cameron <jic23@kernel.org>,
	linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] arm_mpam: detect and enable MPAM-Fb PCC support
Date: Thu, 30 Apr 2026 11:20:42 +0200	[thread overview]
Message-ID: <fc96c088-f767-4bf2-b58b-d4e91b0acde4@arm.com> (raw)
In-Reply-To: <20260430-brave-hoatzin-of-fascination-e7d4ad@sudeepholla>

Hi Sudeep,

thanks for having a look!

On 4/30/26 10:35, Sudeep Holla wrote:
> On Wed, Apr 29, 2026 at 04:13:39PM +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.
>> 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      |  2 ++
>>   drivers/resctrl/mpam_devices.c | 46 +++++++++++++++++++++++++++++++---
>>   2 files changed, 45 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/acpi/arm64/mpam.c b/drivers/acpi/arm64/mpam.c
>> index 99c2bdbb3314..edb4d10e8dc3 100644
>> --- a/drivers/acpi/arm64/mpam.c
>> +++ b/drivers/acpi/arm64/mpam.c
>> @@ -341,6 +341,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);
> 
> I may be looking at the wrong documents, but neither DEN0065 nor DEN0144 carry
> any definitions of pcc-channel and msc-id for the device with HID
> "“ARMHAA5C". Since "pcc-channel" is already merged, I think I am looking at
> wrong documents, please point me to the right one.

Please excuse my ignorance, but I was under the assumption that the 
strings used here are just unique identifiers that need to match the 
property_get calls in the MPAM code. Is there any requirement to match 
those property_entry.name fields with the names given in some spec? And 
those strings are kernel-internal only, right? But for DT would match 
exactly the property names?

Those properties correspond to fields in table 4 in DEN0065, as also 
described in struct acpi_mpam_msc_node in include/acpi/actbl2.h:
- There is "Identifier", that uses distinct IDs for PCC and native MSCs. 
I named it msc-id, because I'd assume that to be a good name for any 
(yet to be defined) DT property.
- Then there is "Base address", which doubles as the "subspace ID of the 
PCC channel", when MPAM-Fb is used. As you mentioned, this is already 
in, and the original spec name would be very misleading, I think.

So shall those strings be renamed to match the struct names? Or shall I 
keep the more readable names as of now, and add comments linking them to 
the spec/struct?

Cheers,
Andre

  reply	other threads:[~2026-04-30  9:20 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-29 14:13 [PATCH 0/5] arm_mpam: Add MPAM-Fb firmware support Andre Przywara
2026-04-29 14:13 ` [PATCH 1/5] arm_mpam: Parse the rest of the ACPI table Andre Przywara
2026-05-08 10:21   ` Ben Horgan
2026-05-12 16:13     ` Andre Przywara
2026-04-29 14:13 ` [PATCH 2/5] arm_mpam: Split the locking around the mon_sel registers Andre Przywara
2026-05-08 10:23   ` Ben Horgan
2026-04-29 14:13 ` [PATCH 3/5] arm_mpam: add MPAM-Fb MSC firmware access support Andre Przywara
2026-05-08 10:33   ` Ben Horgan
2026-05-15 16:04     ` Andre Przywara
2026-05-14  9:30   ` Ben Horgan
2026-04-29 14:13 ` [PATCH 4/5] arm_mpam: prevent MPAM-Fb accesses inside IRQ handler Andre Przywara
2026-04-29 14:13 ` [PATCH 5/5] arm_mpam: detect and enable MPAM-Fb PCC support Andre Przywara
2026-04-30  8:35   ` Sudeep Holla
2026-04-30  9:20     ` Andre Przywara [this message]
2026-04-30 10:25       ` Sudeep Holla
2026-05-08 10:48   ` Ben Horgan
2026-05-13 14:51     ` Andre Przywara
2026-05-14  9:10       ` Ben Horgan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fc96c088-f767-4bf2-b58b-d4e91b0acde4@arm.com \
    --to=andre.przywara@arm.com \
    --cc=ben.horgan@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=fenghuay@nvidia.com \
    --cc=guohanjun@huawei.com \
    --cc=james.morse@arm.com \
    --cc=jic23@kernel.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=rafael@kernel.org \
    --cc=reinette.chatre@intel.com \
    --cc=sudeep.holla@kernel.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.