From: "Luka Gejak" <luka.gejak@linux.dev>
To: "Ping-Ke Shih" <pkshih@realtek.com>,
"Alastair D'Silva" <alastair@d-silva.org>,
linux-wireless@vger.kernel.org, "Kalle Valo" <kvalo@kernel.org>
Cc: "Martin Blumenstingl" <martin.blumenstingl@googlemail.com>,
"Jernej Skrabec" <jernej.skrabec@gmail.com>,
"Ulf Hansson" <ulfh@kernel.org>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
luka.gejak@linux.dev
Subject: Re: [PATCH rtw-next v4 2/4] wifi: rtw88: sdio: Track running state and cancel TX worker on stop
Date: Wed, 07 Oct 2026 05:21:23 +0000 [thread overview]
Message-ID: <9f5d3b374ac9793b745e96121fcfc875083dc873@linux.dev> (raw)
In-Reply-To: <1b8a86e84c474693bfa71f39e946e7e6@realtek.com>
October 7, 2026 at 03:26, "Ping-Ke Shih" <pkshih@realtek.com mailto:pkshi=
h@realtek.com?to=3D%22Ping-Ke%20Shih%22%20%3Cpkshih%40realtek.com%3E > wr=
ote:
>
> Luka Gejak <luka.gejak@linux.dev> wrote:
>
> >
> > > @@ -1703,6 +1712,9 @@ static void rtw_sdio_tx_handler(struct work=
_struct *work)
> > > rtwdev =3D work_data->rtwdev;
> > > rtwsdio =3D (struct rtw_sdio *)rtwdev->priv;
> > >
> > > + if (!rtwsdio->running)
> > > + return;
> > > +
> > >
> > I don't think we need this, since you added cancel_delayed_work_sync=
() in
> > rtw_sdio_stop().
> >
> > I think we should keep the check. The tx work arms the SDIO work a=
t the end,
> > and stop does not cancel it:
> >
> > rtw_hci_tx_kick_off(rtwdev);
> >
> > cancel_work_sync(&rtwdev->c2h_work);
> > cancel_work_sync(&rtwdev->update_beacon_work);
> > cancel_delayed_work_sync(&rtwdev->watch_dog_work);
> > cancel_delayed_work_sync(&coex->bt_relink_work);
> > cancel_delayed_work_sync(&coex->bt_reenable_work);
> > cancel_delayed_work_sync(&coex->defreeze_work);
> > cancel_delayed_work_sync(&coex->wl_remain_work);
> > cancel_delayed_work_sync(&coex->bt_remain_work);
> > cancel_delayed_work_sync(&coex->wl_connecting_work);
> > cancel_delayed_work_sync(&coex->bt_multi_link_remain_work);
> > cancel_delayed_work_sync(&coex->wl_ccklock_work);
> >
> In rtw_sdio_stop(), it does cancel_delayed_work_sync(&rtwsdio->tx_han=
dler_data->work);
> Is it not enough?
>
That is enough for a work item that is already armed. It does not cover=
an
arm that lands after the call, and that can happen:
[...]
> 1. rtwsdio->running =3D false;
> // prevent to schedule rtwsdio->tx_handler_data->work again
Nothing reads rtwsdio->running on the arming path. wake_tx_queue() tests
the flag at the top and queues the work at the bottom:
if (!test_bit(RTW_FLAG_RUNNING, rtwdev->flags))
return;
if (txq->ac =3D=3D IEEE80211_AC_VO)
__rtw_tx_work(rtwdev);
else
queue_work(rtwdev->tx_wq, &rtwdev->tx_work);
then __rtw_tx_work() kicks the SDIO work at the end:
rtw_hci_tx_kick_off(rtwdev);
The sequence:
1. wake_tx_queue() reads the flag while it is still set and queues
rtwdev->tx_work.
2. rtw_core_stop() clears the flag and cancels its list of works.
3. rtw_sdio_stop() sets running to false and disables the interrupts. The
cancel_delayed_work_sync() finds nothing armed and returns at once.
4. rtw_tx_work() runs now, nothing cancelled it, and it ends in
rtw_sdio_tx_kick_off(), which arms the delayed work again with
mod_delayed_work().
5. rtw_sdio_tx_handler() runs, and without the check it calls
rtw_sdio_deep_ps_leave() and then walks the queues on a MAC that is
being powered off.
So the cancel only orders against a kick that came before it, and the
check covers the other order.
Best regards,
Luka Gejak
next prev parent reply other threads:[~2026-10-07 6:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-05 8:48 [PATCH rtw-next v4 0/4] wifi: rtw88: sdio: Fix unhandled RX request interrupt storm Alastair D'Silva
2026-10-05 8:48 ` [PATCH rtw-next v4 1/4] wifi: rtw88: sdio: Handle allocation and read errors in rtw_sdio_rxfifo_recv Alastair D'Silva
2026-10-06 1:35 ` Ping-Ke Shih
2026-10-05 8:48 ` [PATCH rtw-next v4 2/4] wifi: rtw88: sdio: Track running state and cancel TX worker on stop Alastair D'Silva
2026-10-06 2:03 ` Ping-Ke Shih
2026-10-06 4:44 ` Luka Gejak
2026-10-06 14:03 ` Luka Gejak
2026-10-06 14:18 ` Luka Gejak
2026-10-07 1:26 ` Ping-Ke Shih
2026-10-07 4:37 ` Luka Gejak
2026-10-07 5:21 ` Luka Gejak [this message]
2026-10-07 6:18 ` Luka Gejak
2026-10-05 8:48 ` [PATCH rtw-next v4 3/4] wifi: rtw88: sdio: Fix unhandled RX request interrupt storm Alastair D'Silva
2026-10-06 2:05 ` Ping-Ke Shih
2026-10-05 8:48 ` [PATCH rtw-next v4 4/4] wifi: rtw88: sdio: Split rtw_sdio_rx_isr into 8051 and 3081 variants Alastair D'Silva
2026-10-06 2:08 ` Ping-Ke Shih
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9f5d3b374ac9793b745e96121fcfc875083dc873@linux.dev \
--to=luka.gejak@linux.dev \
--cc=alastair@d-silva.org \
--cc=jernej.skrabec@gmail.com \
--cc=kvalo@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=pkshih@realtek.com \
--cc=stable@vger.kernel.org \
--cc=ulfh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.