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

[James Morse]

Hi Shaopeng,

On 27/06/2025 06:54, Shaopeng Tan (Fujitsu) wrote:
>> On Fri, 13 Jun 2025 13:03:55 +0000
>> James Morse <james.morse at arm.com> 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.

>>> 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
>>> @@ -200,7 +200,7 @@ static void cache_of_set_id(struct cacheinfo *this_leaf,
>> struct device_node *np)
>>>  		id = arch_compact_of_hwid(id);
>>>  		if (FIELD_GET(GENMASK_ULL(63, 32), id)) {

> Since "id" was compressed into 32bits by the function arch_compact_of_hwid(),
> is this required?

The need for this is clearer in the patch that introduces it - arch_compact_of_hwid() may
not be implemented by all architectures that use OF, and arch_compact_of_hwid() needs to
be able to fail if it can't produce a 32bit version of the hwid. (on arm64 this would
happen if an aff4 was allocated in the RES0 bits of MPIDR_EL1 - which is why the helper
checks those bits are all zero).
This check ensures that if any cache-id is greater than 32 bits, then the platform doesn't
expose any cache-id to user-space, which will let use fix it up in some way without
changing the values user-space saw for the 'other' caches.


Thanks,

James