Re: [PATCH RFC 02/15] cacheinfo: Expose the code to generate a cache-id from a device_node

[Drew Fustini]

On Tue, Aug 11, 2026 at 09:30:31PM +0800, Yin Li wrote:
> From: James Morse <james.morse@xxxxxxx>
> 
> 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(). Even after device_initcall(),
> the cache-id is only available if at least one CPU associated with
> the cache is online.
> 
> Instead of making the driver wait, 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().

This patch would also be helpful for resctrl support on RISC-V, too. The
probe function in the CBQRI capacity allocation platform driver [1] has
the same problem. The current solution is to scan the online CPUs for a
cacheinfo leaf whose fw_token is the cache node from the phandle.
However, that does not work if no cpu sharing that cache is online yet.

[..]
> +u32 cache_of_calculate_id(struct device_node *cache_node)
>  {
>  	struct device_node *cpu;
>  	u32 min_id = ~0;
> @@ -238,15 +237,23 @@ static void cache_of_set_id(struct cacheinfo *this_leaf,
>  		id = arch_compact_of_hwid(id);
>  		if (FIELD_GET(GENMASK_ULL(63, 32), id)) {
>  			of_node_put(cpu);
> -			return;
> +			return ~0;

Maybe this should be U32_MAX instead?

Thanks,
Drew

[1] https://lore.kernel.org/all/20260729-dfustini-atl-sc-cbqri-dt-v6-8-7c22b05d461b@xxxxxxxxxx/