Re: [PATCH v2 11/29] arm_mpam: Probe hardware to find the supported partid/pmg values

James Morse
2025-09-29T17:44:42Z

On 11/09/2025 16:18, Jonathan Cameron wrote:
> On Wed, 10 Sep 2025 20:42:51 +0000
> James Morse <james.morse@arm.com> wrote:
>
>> CPUs can generate traffic with a range of PARTID and PMG values,
>> but each MSC may also have its own maximum size for these fields.
>> Before MPAM can be used, the driver needs to probe each RIS on
>> each MSC, to find the system-wide smallest value that can be used.
>> The limits from requestors (e.g. CPUs) also need taking into account.
>>
>> While doing this, RIS entries that firmware didn't describe are created
>> under MPAM_CLASS_UNKNOWN.
>>
>> While we're here, implement the mpam_register_requestor() call
>> for the arch code to register the CPU limits. Future callers of this
>> will tell us about the SMMU and ITS.
>>
>> Signed-off-by: James Morse <james.morse@arm.com>

> Trivial stuff inline.
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>

Thanks!

>> drivers/resctrl/mpam_devices.c | 150 +++++++++++++++++++++++++++++++-
>> drivers/resctrl/mpam_internal.h | 6 ++
>> include/linux/arm_mpam.h | 14 +++
>> 3 files changed, 169 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
>> index c265376d936b..24dc81c15ec8 100644
>> --- a/drivers/resctrl/mpam_devices.c
>> +++ b/drivers/resctrl/mpam_devices.c
>
>
>> +int mpam_register_requestor(u16 partid_max, u8 pmg_max)
>> +{
>> + int err = 0;
>> +
>> + spin_lock(&partid_max_lock);

> guard() perhaps so you can return early in the error pat and avoid
> need for local variable err.

Negh ... okay. I dislike the guard thing as its never clear when the lock is unlocked.
I'm not a fan of spooky action at a distance!

>> + if (!partid_max_init) {
>> + mpam_partid_max = partid_max;
>> + mpam_pmg_max = pmg_max;
>> + partid_max_init = true;
>> + } else if (!partid_max_published) {
>> + mpam_partid_max = min(mpam_partid_max, partid_max);
>> + mpam_pmg_max = min(mpam_pmg_max, pmg_max);
>> + } else {
>> + /* New requestors can't lower the values */
>> + if (partid_max < mpam_partid_max || pmg_max < mpam_pmg_max)
>> + err = -EBUSY;
>> + }
>> + spin_unlock(&partid_max_lock);
>> +
>> + return err;
>> +}
>> +EXPORT_SYMBOL(mpam_register_requestor);
>
>> @@ -470,9 +547,37 @@ int mpam_ris_create(struct mpam_msc *msc, u8 ris_idx,
>> +static struct mpam_msc_ris *mpam_get_or_create_ris(struct mpam_msc *msc,
>> + u8 ris_idx)
>> +{
>> + int err;
>> + struct mpam_msc_ris *ris, *found = ERR_PTR(-ENOENT);
>> +
>> + lockdep_assert_held(&mpam_list_lock);
>> +
>> + if (!test_bit(ris_idx, &msc->ris_idxs)) {
>> + err = mpam_ris_create_locked(msc, ris_idx, MPAM_CLASS_UNKNOWN,
>> + 0, 0);
>> + if (err)
>> + return ERR_PTR(err);
>> + }
>> +
>> + list_for_each_entry(ris, &msc->ris, msc_list) {
>> + if (ris->ris_idx == ris_idx) {
>> + found = ris;
> I'd return ris;
>
> Then can do return ERR_PTR(-ENOENT) below and not bother with found.
>
> Ignore if this gets more complex later.

Thank - this is another relic of more complex locking...
Fixed as you suggested.

>> + break;
>> + }
>> + }
>> +
>> + return found;
>> +}
>
>> @@ -675,9 +813,18 @@ static struct platform_driver mpam_msc_driver = {
>>
>> static void mpam_enable_once(void)
>> {
>> + /*
>> + * Once the cpuhp callbacks have been changed, mpam_partid_max can no
>> + * longer change.
>> + */
>> + spin_lock(&partid_max_lock);
>> + partid_max_published = true;
>> + spin_unlock(&partid_max_lock);
>> +
>> mpam_register_cpuhp_callbacks(mpam_cpu_online, mpam_cpu_offline);
>>
>> - pr_info("MPAM enabled\n");
>> + printk(KERN_INFO "MPAM enabled with %u PARTIDs and %u PMGs\n",
>> + mpam_partid_max + 1, mpam_pmg_max + 1);

> Not sure why pr_info before and printk now.

That looks like a conflict gone wrong!
Fixed.

Thanks,

James