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

[Dave Martin]

Hi James,

On Fri, Aug 22, 2025 at 03:29:42PM +0000, James Morse 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 device_initcall().
> 
> Expose the code that generates the cache-id. The parts of the MPAM
> driver that run early can use this to set up the resctrl structures
> before cacheinfo is ready in device_initcall().

Why can't the MPAM driver just consume the precomputed cache-id
information?

Possible reasons are that the MPAM driver probes too early, or that it
must parse the PPTT directly (which is true) and needs to label caches
consistently with the way the kernel does it.

> 
> Signed-off-by: James Morse <james.morse at arm.com>
> ---
> Changes since v1:
>  * Renamed cache_of_get_id() cache_of_calculate_id().
> ---
>  drivers/base/cacheinfo.c  | 19 +++++++++++++------
>  include/linux/cacheinfo.h |  1 +
>  2 files changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
> index 613410705a47..f6289d142ba9 100644
> --- a/drivers/base/cacheinfo.c
> +++ b/drivers/base/cacheinfo.c
> @@ -207,11 +207,10 @@ static bool match_cache_node(struct device_node *cpu,
>  #define arch_compact_of_hwid(_x)	(_x)
>  #endif
>  
> -static void cache_of_set_id(struct cacheinfo *this_leaf,
> -			    struct device_node *cache_node)
> +unsigned long cache_of_calculate_id(struct device_node *cache_node)
>  {
>  	struct device_node *cpu;
> -	u32 min_id = ~0;
> +	unsigned long min_id = ~0UL;

Why the change of type here?

This does mean that 0xffffffff can now be generated as a valid cache-id,
but if that is necessary then this patch is also fixing a bug in the
code -- but the commit message doesn't say anything about that.

For a patch that is just exposing an internal result, it may be
better to keep the original type.  ~(u32)0 is already used as an
exceptional value.

[...]

Otherwise, this looks reasonable to me.

Cheers
---Dave