All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ping-Ke Shih <pkshih@realtek.com>
To: Luka Gejak <luka.gejak@linux.dev>,
	Alastair D'Silva <alastair@d-silva.org>,
	"linux-wireless@vger.kernel.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" <linux-kernel@vger.kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH rtw-next v4 2/4] wifi: rtw88: sdio: Track running state and cancel TX worker on stop
Date: Wed, 7 Oct 2026 01:26:54 +0000	[thread overview]
Message-ID: <1b8a86e84c474693bfa71f39e946e7e6@realtek.com> (raw)
In-Reply-To: <ccc69689fe2a2cccc39d40221056722e24263f2f@linux.dev>

Luka Gejak <luka.gejak@linux.dev> wrote:
> > >  @@ -1703,6 +1712,9 @@ static void rtw_sdio_tx_handler(struct work_struct *work)
> > >  rtwdev = work_data->rtwdev;
> > >  rtwsdio = (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 at 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_handler_data->work);
Is it not enough?

> 
> so a kick can land after the cancel has run, and only this flag
> keeps the item off the powered-down device.
> 
> Also I believe this series should be tested on hardware to ensure
> nothing breaks.

When calling rtw_sdio_stop(), I think mac80211 doesn't TX anymore
to driver, and then rtw_sdio_stop() does
 1. rtwsdio->running = false;
    // prevent to schedule rtwsdio->tx_handler_data->work again
 2. rtw_sdio_disable_interrupt(rtwdev);
    // prevent to run rtw_sdio_handle_interrupt again
 3. cancel_delayed_work_sync(&rtwsdio->tx_handler_data->work);
    // flush/wait the pending rtw_sdio_tx_handler

Anything I miss? Could you point out a case this is needed?

Ping-Ke


  parent reply	other threads:[~2026-10-07  1:27 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 [this message]
2026-10-07  4:37         ` Luka Gejak
2026-10-07  5:21         ` Luka Gejak
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=1b8a86e84c474693bfa71f39e946e7e6@realtek.com \
    --to=pkshih@realtek.com \
    --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=luka.gejak@linux.dev \
    --cc=martin.blumenstingl@googlemail.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.