[PATCH v2 1/7] spi: spi-mem: Add support for panic mem writes

[Paul Cercueil]

Hi Sashiko,

Le mardi 13 octobre 2026 à 14:23 +0000, sashiko-bot at kernel.org a écrit :
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s)
> to consider:
> - [High] spi: spi-mem: inverted pm_runtime_get_if_active() return check
> - [High] spi: spi-mem: fallback path deadlocks during panic_write on -
> EOPNOTSUPP
> - [High] spi: deadlock in panic context from pm_runtime_get_if_active()
> --
> 
> commit 3d801ffb98468bd4b61d20480140ce8dbbcf4ae2
> Author: Tanmay Jagdale <tanmay at marvell.com>
> 
> spi: spi-mem: Add support for panic mem writes
> 
> Add a 'panic_write' flag to the controller's capabilities struct.
> When set, the SPI controller indicates that it will be able to send
> commands to a connected NOR or NAND memory in the context of a kernel
> panic, which means without sleeping and without relying on IRQs.
> 
> > diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
> > index b94680b60af95..3b6fa44e45504 100644
> > --- a/drivers/spi/spi-mem.c
> > +++ b/drivers/spi/spi-mem.c
> 
> [ ... ]
> 
> > @@ -420,7 +445,10 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct
> > spi_mem_op *op)
> >  		return -EOPNOTSUPP;
> >  
> >  	if (ctlr->mem_ops && ctlr->mem_ops->exec_op &&
> > !spi_get_csgpiod(mem->spi, 0)) {
> > -		ret = spi_mem_access_start(mem);
> > +		if (!op->panic_write)
> > +			ret = spi_mem_access_start(mem);
> > +		else if (ctlr->auto_runtime_pm)
> > +			ret = pm_runtime_get_if_active(ctlr->dev.parent);
> >  		if (ret)
> >  			return ret;
> 
> [Severity: High]
> Is it safe to call pm_runtime_get_if_active() here during a kernel panic?
> 
> pm_runtime_get_if_active() relies on pm_runtime_get_conditional(), which
> unconditionally acquires dev->power.lock via spin_lock_irqsave(). In a panic
> context with NMIs or IRQs disabled, trying to acquire a spinlock that may be
> held by a halted CPU causes an infinite spin. On PREEMPT_RT,
> spin_lock_irqsave()
> maps to a sleeping rt_mutex, which is strictly forbidden in atomic context.

ACK, I'll just drop pm_runtime_get_if_active() here, and restore the return -
EOPNOTSUPP that was in v1 when ctlr->auto_runtime_pm is set.

> [Severity: High]
> If the controller's exec_op implementation dynamically returns -EOPNOTSUPP
> during a panic write, could this fallback path cause a deadlock?

Good point, dear bot. We do not want to go to the fallback code.

Cheers,
-Paul