Re: [PATCH 4/5] cacheinfo: Expose the code to generate a cache-id from a device_node

From: James Morse
Date: Fri Jun 27 2025 - 12:41:29 EST


Hi Jonathan,

On 17/06/2025 17:21, Jonathan Cameron wrote:
> On Fri, 13 Jun 2025 13:03:55 +0000
> James Morse <james.morse@xxxxxxx> wrote:

>> The MPAM driver identifies caches by id for use with resctrl. It
>> needs to know the cache-id when probe-ing, but the value isn't set
>> in cacheinfo until the corresponding CPU comes online.
>>
>> Expose the code that generates the cache-id. This allows the MPAM
>> driver to determine the properties of the caches without waiting
>> for all CPUs to come online.

> Feels to me like this needs to come with the user.
> The earlier patches at least expose it via existing infrastructure
> this isn't used at all yet...

Yeah, I'm damned whatever I do here. I can move this (and patch 5) to the series with the
MPAM driver - this was me trying to reduce the number of people that get copied on that,
and the number of trees that it touches...


>> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
>> index d8e5b4c7156c..6316d80abab8 100644
>> --- a/drivers/base/cacheinfo.c
>> +++ b/drivers/base/cacheinfo.c
>> @@ -188,7 +188,7 @@ static bool cache_node_is_unified(struct cacheinfo *this_leaf,
>> #define arch_compact_of_hwid(_x) (_x)
>> #endif
>>
>> -static void cache_of_set_id(struct cacheinfo *this_leaf, struct device_node *np)
>> +unsigned long cache_of_get_id(struct device_node *np)

> Bit confusing to have cache_of_set_id() call cache_of_get_id() like this because
> they are in no way mirrors of each other. Rename?
> (and naturally I'm providing no suggestions :)

I'll try cache_of_calculate_id() ...


>> {
>> struct device_node *cpu;
>> u32 min_id = ~0;


Thanks,

James