Re: [PATCH v3 8/8] riscv_cbqri: Add CBQRI capacity allocation platform driver

[Drew Fustini <fustini@kernel.org>]

On Sun, Jun 28, 2026 at 09:27:43PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] cbqri_capacity_probe() incorrectly uses get_cpu_cacheinfo_level() to find the cacheinfo, which will fail for split caches (e.g., L1I/L1D).
> --
> 
> commit 1a6b06fa1768e5d101b318b8e5167a959fc10696
> Author: Drew Fustini <fustini@kernel.org>
> 
> riscv_cbqri: Add CBQRI capacity allocation platform driver
> 
> This commit adds a device-tree platform driver for the RISC-V CBQRI capacity
> controller. It reads the cache level from the device tree and matches it
> against the system's cacheinfo to get the resctrl domain ID and shared harts.
> 
> > diff --git a/drivers/resctrl/cbqri_capacity.c b/drivers/resctrl/cbqri_capacity.c
> > new file mode 100644
> > index 0000000000000..2172432eb3287
> > --- /dev/null
> > +++ b/drivers/resctrl/cbqri_capacity.c
> [ ... ]
> > +static int cbqri_capacity_probe(struct platform_device *pdev)
> > +{
> [ ... ]
> > +	/*
> > +	 * Associate the controller with its cache instance via
> > +	 * cacheinfo. The matching cache provides the cache id and the
> > +	 * set of harts that share the cache.
> > +	 */
> > +	cache_id = -1;
> > +	cpus_read_lock();
> > +	for_each_online_cpu(cpu) {
> > +		struct cacheinfo *ci = get_cpu_cacheinfo_level(cpu, cache_level);
> 
> [Severity: Medium]
> Could this fail to match split caches, like an L1 data cache?
> 
> The get_cpu_cacheinfo_level() function unconditionally returns the first
> cacheinfo leaf it finds at the requested level and stops searching. If the
> given level has multiple leaves (for example, L1 instruction and L1 data),
> and the device tree node refers to the second leaf, this loop will miss it.
> This would cause the fw_token check to fail and the probe to return -ENODEV.

riscv,cbqri-cache points at a separate unified cache node. Split L1 I/D
come from i-cache-size/d-cache-size on the CPU node which have no
phandle. Per the CBQRI spec, the capacity controller governs a unified
shared cache, so a split private L1 is not a valid allocation target.

-Drew
~                                                                                                                                        
~                        

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv