Re: [PATCH rtw-next v6 2/4] wifi: rtw88: sdio: Track running state and cancel TX worker on stop

[Luka Gejak]

Hi Alastair,

October 14, 2026 at 9:44 AM, "Alastair D'Silva" <alastair@xxxxxxxxxxx> wrote:

>  static void rtw_sdio_stop(struct rtw_dev *rtwdev)
>  {                                                                                            > -     rtw_sdio_disable_interrupt(rtwdev);
> +     struct rtw_sdio *rtwsdio = (struct rtw_sdio *)rtwdev->priv;                             > +
> +     sdio_claim_host(rtwsdio->sdio_func);
> +     scoped_guard(mutex, &rtwsdio->irq_lock) {
> +             rtwsdio->running = false;
> +             rtw_sdio_disable_interrupt(rtwdev);
> +     }
> +     sdio_release_host(rtwsdio->sdio_func);
> +
> +     cancel_delayed_work_sync(&rtwsdio->tx_handler_data->work);
>  }

One thing about that cancel. The delayed work is the back pressure retry:
rtw_sdio_8723bs_reschedule_tx() re-arms it with queue_delayed_work() when
a page shortage parks a frame, and rtw_sdio_tx_kick_off() re-arms it with
mod_delayed_work() for every new frame. On 8723bs the frames that fill the
software FIFO past the watermark also stop the matching mac80211 queue
(ieee80211_stop_queue() in rtw_sdio_8723bs_stop_tx_queue()), and
rtw_sdio_start() undoes neither that nor tx_queue_stopped[]. The flag is
cleared in rtw_sdio_init_tx() and in rtw_sdio_8723bs_wake_tx_queue(), and
the second of those only runs after a write has gone out.

So a stop that lands while an access category is held back leaves the
queue stopped and its frames parked in rtwsdio->tx_queue[] with no work
queued to come back for them. It recovers as soon as anything transmits
on any queue, because that kicks the worker again and the handler walks
all queues, so I could not make it a permanent wedge. It does mean an
idle link can sit on those frames for a long time. Would it be worth
re-arming the worker at the end of rtw_sdio_start(), or clearing
tx_queue_stopped[] and waking the queues there?

Best regards,
Luka Gejak