Re: [PATCH] wifi: brcmfmac: avoid sleeping tx locks in netpoll contextg

[Karl Mehltretter <kmehltretter@gmail.com>]

On Fri, Oct 09, 2026 at 06:00:15PM +0100, Sebastian Andrzej Siewior wrote:
> > 
> > Source inspection also identified 8139too and macb as candidates: their
> > transmit paths take ordinary spinlock_t locks. I have not reproduced the
> > warning with either driver.
> 
> I just replied to the netconsole thread where I did suggest to lift the
> local_irq_save() part. This would obsolete this.

I've replied in the netpoll thread [1]. The netpoll candidate's RT
locking tests look good so far on Pi 400 with unmodified brcmfmac.

> 
> > The earlier netpoll/NBCON discussion concerns NAPI polling and
> > scheduler-lock deadlocks, rather than this driver-lock warning:
> > 
> > https://lore.kernel.org/linux-rt-devel/20260618111554.2n0pP_O9@linutronix.de/
> 
> There was no fan club behind this change and PeterZ hated it so I
> dropped it.
> But this deadlock should not happen with nbcon or do I mix up things?

No, you're not mixing things up.

> I don't mind if you have something to optimise the driver. But as far as
> the netconsole part goes, I would try to kill it at the upper level so
> the driver is not affected.

Agreed. I'll hold the driver revision while we discuss the generic fix.

The generic fix still doesn't address calls to brcmfmac with
interrupts disabled from non-RT netconsole or atomic writes.

I still need to compare the unmodified kernel and the netpoll candidate
on hardware with firmware flow control enabled (brcmfmac.fcmode=1 or 2).

[1] https://lore.kernel.org/r/asveuLDEf6a44bkD@gmail.com/

Karl