[PATCH] cache: sifive_ccache: propagate IRQ count errors

[Conor Dooley]

On Tue, Oct 13, 2026 at 12:57:56PM +0300, Avi Weiss wrote:
> platform_irq_count() returns -EPROBE_DEFER when the
> interrupt provider is not ready, but
> sifive_ccache_probe() only checks for a zero count.
> 
> -EPROBE_DEFER seems to be the only negative return
> code possible here (currently).
> 
> A negative count skips the IRQ registration loop and
> allows the probe to return success without requesting
> a deferred retry.
> 
> Return negative IRQ counts so the driver is reprobed
> when the interrupt provider becomes available.
> 
> Fixes: c90847bcbfb6 ("cache: sifive_ccache: Partially convert to a platform driver")
> Signed-off-by: Avi Weiss <thnkslprpt at gmail.com>
> ---
>  drivers/cache/sifive_ccache.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/cache/sifive_ccache.c b/drivers/cache/sifive_ccache.c
> index 2acb8bdf06d52..b4033110f34e5 100644
> --- a/drivers/cache/sifive_ccache.c
> +++ b/drivers/cache/sifive_ccache.c
> @@ -262,6 +262,9 @@ static int sifive_ccache_probe(struct platform_device *pdev)
>  	quirks = (unsigned long)device_get_match_data(dev);
>  
>  	intr_num = platform_irq_count(pdev);
> +	if (intr_num < 0)
> +		return dev_err_probe(dev, intr_num,
> +				     "Failed to count interrupts\n");
>  	if (!intr_num)
>  		return dev_err_probe(dev, -ENODEV, "No interrupts property\n");

I normally hate putting ternary operators in things, but I really don't
like how this looks, especially since the new dev_err_probe() will never
actually ever emit that warning given the behaviour of
platform_irq_count().

Can we do

if (intr_num <= 0)
	return dev_err_probe(dev, ret ?: -ENODEV, "No interrupts property\n");

instead?

Cheers,
Conor.

>  
> 
> base-commit: 24a19b953e2a3d0ea5a8c4951a0ab8f32720c907
> -- 
> 2.43.0
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20261013/e593d310/attachment.sig>