Hi, On 09/08/2026 at 02:19:17 GMT, Fan Wu <[email protected]> wrote:
> The FIFOP interrupt handler queues cc2520_fifop_irqwork. On removal, > cc2520_remove() only flushes the work. The devm-managed FIFOP IRQ > remains active until after ->remove() returns and can queue the work > again after that flush, allowing it to run after the private data is > released. > > Disable the work with disable_work_sync() instead of flushing it, so > the handler can no longer queue it once removal begins. Destroy > buffer_mutex last, since unregistering can invoke the driver's stop > callback, which uses it. > > Install the SFD IRQ before cc2520_register(), so it is available when > the netdev becomes visible. Install the FIFOP IRQ afterwards, so a > registration failure cannot schedule RX work while its hardware is > being released; cc2520_register() no longer frees the hardware on its > own failure, leaving that to the probe cleanup. This is a cleanup mixed with a fix. These must be two different patches, because I don't think you need the cleanup for the fix to make sense. Thanks, Miquèl
