Re: [PATCH v5 08/23] dmaengine: ste_dma40: Return IRQ_NONE when no interrupt is pending

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dmaengine: ste_dma40: spurious IRQ regression due to returning IRQ_NONE
--

commit b3869fd527499e9a4f208caed7dc53effe8c70c3
Author: Linus Walleij <linusw@kernel.org>

dmaengine: ste_dma40: Return IRQ_NONE when no interrupt is pending

The commit modifies d40_handle_interrupt() to return IRQ_NONE when no status
bits are pending. This is intended to allow the generic IRQ core to diagnose
stuck interrupts and eventually disable the line.

> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 9e8879e3e8d1f..0c3f837fe5867 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -1819,6 +1819,7 @@ static void dma_tasklet(struct tasklet_struct *t)
>  
>  static irqreturn_t d40_handle_interrupt(int irq, void *data)
>  {
> +	irqreturn_t handled = IRQ_NONE;
>  	int i;
>  	u32 idx;
>  	u32 row;

[ ... ]

> @@ -1884,7 +1891,7 @@ static irqreturn_t d40_handle_interrupt(int irq, void *data)
>  	if (ret > 0)
>  		pm_runtime_put_autosuspend(base->dev);
>  
> -	return IRQ_HANDLED;
> +	return handled;

[Severity: High]
Could returning IRQ_NONE when 0 status bits are found cause the generic IRQ
subsystem to permanently disable the DMA40 interrupt line ('irq xx: nobody
cared')?

As noted in the commit message, the hardware interrupt is shared with other
SoC cores. When a foreign core's DMA channel asserts the interrupt, both
cores may wake up. If the foreign core clears its status register before
Linux's d40_handle_interrupt() executes its readl(), Linux will read 0
status bits.

Also, when Linux clears an interrupt via writel() earlier in this handler,
the posted write may be delayed over the bus because there is no flushing
readl(). The CPU might exit the handler and re-enable interrupts before the
write reaches the hardware, causing an immediate spurious re-entry where
Linux again reads 0 status bits.

Will these transient delays now be counted as unhandled interrupts,
eventually breaking the DMA controller and dependent peripherals once
100,000 unhandled interrupts accumulate?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923-dma40-fixes-v5-0-709d160cde76@kernel.org?part=8