Hi Fan,
On 06/08/2026 at 05:03:28 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.
>
> Release the FIFOP IRQ and cancel the work before unregistering and
> freeing the hardware. Keep the SFD IRQ active while
> ieee802154_unregister_hw() flushes the mac802154 workqueue: synchronous
> TX waits in cc2520_tx() for the completion signalled by the SFD handler.
> Release the SFD IRQ afterwards. 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. Move ieee802154_free_hw() to the probe cleanup.
>
> Found by an in-house static analysis tool.
>
> Fixes: 0da6bc8cc341 ("ieee802154: cc2520: adds driver for TI CC2520 radio")
> Cc: [email protected]
> Assisted-by: Codex:gpt-5.6
> Signed-off-by: Fan Wu <[email protected]>
While I may agree on the problem, I don't like the solution. It is
overly complex. If the problem is the fact that we might queue works,
what about disable_work[_sync]() ?
Thanks,
Miquèl
