Re: [PATCH v2] arm_mpam: Only schedule mpam_enable work after first successful MSC probe

[Yin Li <yin.li@oss.qualcomm.com>]

On 9/10/2026 5:25 PM, Ben Horgan wrote:
> Hi Ping,
> 
> On 08/09/2026 03:48, ping.li wrote:
>> From: Ping Li <leeonion.muyu@gmail.com>
>>
>> mpam_discovery_cpu_online() sets new_device_probed unconditionally after
>> processing each reachable MSC. Once an MSC has already been probed
>> (msc->probed is true), later CPUs sharing it skip
>> mpam_msc_hw_probe() but still leave err at its default value of 0.
>> As a result, new_device_probed is still set to true, causing
>> mpam_enable_work to be scheduled again even though no new hardware was
>> probed.
> 
> This patch is an improvement but, thinking again, it looks there is scope getting rid of
> mpam_enable() altogether. Rather than walking the list after each hw probe we could increment an
> atomic variable, similar to what is done in mpam_msc_drv_probe(), and then just schedule
> mpam_enable_once(). What do you think?
> 

Hi Ben,

Seeing another atomic-counter based sequencing mechanism in this patch 
reminded me of a similar issue I explored while working on MPAM DT support.

At the time, I experimented with removing the fw_num_msc pre-counting 
logic and moving the discovery callback registration to a 
late_initcall() stage. The motivation was to avoid separate DT/ACPI 
counting paths and allow discovery to proceed based on successfully 
probed MSCs.

However, I eventually dropped that approach because it relied on 
synchronous probing and would not behave correctly in deferred-probe or 
future asynchronous-probe scenarios.

That made me curious about the motivation behind this change:
   - Is MPAM intentionally designed around the assumption that all 
firmware-described MSCs must probe successfully before discovery can 
proceed?
   - Is the count-and-compare model primarily retained to guarantee 
correct ordering under deferred/asynchronous probing?

I'm not suggesting changing the implementation, just interested in 
understanding the design rationale.

Thanks,
Yin


> Thanks,
> 
> Ben
> 
>>
>> Set new_device_probed only when mpam_msc_hw_probe() is called and
>> succeeds.
>>
>> Signed-off-by: Ping Li <leeonion.muyu@gmail.com>
>> ---
>> Changes in v2:
>> - Drop the Fixes: tag, as the extra mpam_enable() calls cause no real
>>    harm: schedule_work() merges the duplicate work, and mpam_enable()
>>    is a no-op until all MSCs have been probed. This is a cleanup, not a
>>    bug fix.
>>
>>   drivers/resctrl/mpam_devices.c | 6 ++++--
>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
>> index 2f09f4b78bd3..fefdcf588932 100644
>> --- a/drivers/resctrl/mpam_devices.c
>> +++ b/drivers/resctrl/mpam_devices.c
>> @@ -1866,13 +1866,15 @@ static int mpam_discovery_cpu_online(unsigned int cpu)
>>   			continue;
>>   
>>   		mutex_lock(&msc->probe_lock);
>> -		if (!msc->probed)
>> +		if (!msc->probed) {
>>   			err = mpam_msc_hw_probe(msc);
>> +			if (!err)
>> +				new_device_probed = true;
>> +		}
>>   		mutex_unlock(&msc->probe_lock);
>>   
>>   		if (err)
>>   			break;
>> -		new_device_probed = true;
>>   	}
>>   
>>   	if (new_device_probed && !err)
> 

-- 
Thx and BRs,
Yin