From: Ping-Ke Shih <pkshih@realtek.com>
To: Mehmet Fide <mehmet.fide@gmail.com>
Cc: Luka Gejak <luka.gejak@linux.dev>,
Bitterblue Smith <rtl8821cerfe2@gmail.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mehmet.fide@screeningeagle.com" <mehmet.fide@screeningeagle.com>
Subject: RE: [PATCH rtw-next v4 2/2] wifi: rtw88: support channel switch in AP mode
Date: Wed, 7 Oct 2026 06:39:09 +0000 [thread overview]
Message-ID: <63ac6992e6614de1a085131964974ff1@realtek.com> (raw)
In-Reply-To: <20261007061113.2083449-3-mehmet.fide@gmail.com>
Mehmet Fide <mehmet.fide@gmail.com> wrote:
[...]
> --- a/drivers/net/wireless/realtek/rtw88/fw.c
> +++ b/drivers/net/wireless/realtek/rtw88/fw.c
> @@ -1802,14 +1802,76 @@ int rtw_fw_download_rsvd_page(struct rtw_dev *rtwdev)
> return ret;
> }
>
> +bool rtw_fw_csa_active(struct rtw_dev *rtwdev)
> +{
add lockdep_assert_wiphy(wiphy) to rtw_fw_csa_{active,start,stop}?
Since they access rtwdev->csa_vif.
> + return rtwdev->csa_vif && rtwdev->csa_vif->bss_conf.csa_active;
> +}
> +
> +void rtw_fw_csa_start(struct rtw_dev *rtwdev, struct ieee80211_vif *vif)
> +{
> + u32 interval = ieee80211_tu_to_usec(vif->bss_conf.beacon_int);
> +
> + rtwdev->csa_vif = vif;
> + wiphy_delayed_work_queue(rtwdev->hw->wiphy, &rtwdev->csa_beacon_work,
> + usecs_to_jiffies(interval));
> +}
> +
> +void rtw_fw_csa_stop(struct rtw_dev *rtwdev, struct ieee80211_vif *vif)
> +{
> + if (!vif || rtwdev->csa_vif != vif)
> + return;
> +
> + wiphy_delayed_work_cancel(rtwdev->hw->wiphy, &rtwdev->csa_beacon_work);
> + rtwdev->csa_vif = NULL;
> +}
> +
[...]
> diff --git a/drivers/net/wireless/realtek/rtw88/mac80211.c
> b/drivers/net/wireless/realtek/rtw88/mac80211.c
> index 2a9b09fa76e7..087268909f5f 100644
> --- a/drivers/net/wireless/realtek/rtw88/mac80211.c
> +++ b/drivers/net/wireless/realtek/rtw88/mac80211.c
> @@ -235,6 +235,8 @@ static void rtw_ops_remove_interface(struct ieee80211_hw *hw,
> rtw_dbg(rtwdev, RTW_DBG_STATE, "stop vif %pM mac_id %d on port %d\n",
> vif->addr, rtwvif->mac_id, rtwvif->port);
>
> + rtw_fw_csa_stop(rtwdev, vif);
> +
> mutex_lock(&rtwdev->mutex);
>
> rtw_leave_lps_deep(rtwdev);
> @@ -395,8 +397,10 @@ static void rtw_ops_bss_info_changed(struct ieee80211_hw *hw,
> if (vif->cfg.assoc) {
> rtw_coex_connect_notify(rtwdev, COEX_ASSOCIATE_FINISH);
>
> - rtw_fw_download_rsvd_page(rtwdev);
> - rtw_send_rsvd_page_h2c(rtwdev);
> + if (!rtw_fw_csa_active(rtwdev)) {
Does it actually happen to AP mode?
If it could happen, check the condition by conf->csa_active (like below)?
> + rtw_fw_download_rsvd_page(rtwdev);
> + rtw_send_rsvd_page_h2c(rtwdev);
> + }
> rtw_fw_default_port(rtwdev, rtwvif);
> rtw_coex_media_status_notify(rtwdev, vif->cfg.assoc);
> if (rtw_bf_support)
> @@ -438,6 +442,8 @@ static void rtw_ops_bss_info_changed(struct ieee80211_hw *hw,
> rtw_set_dtim_period(rtwdev, conf->dtim_period);
> rtw_fw_download_rsvd_page(rtwdev);
> rtw_send_rsvd_page_h2c(rtwdev);
> + if (conf->csa_active)
> + rtw_fw_csa_start(rtwdev, vif);
> }
>
> if (changed & BSS_CHANGED_BEACON_ENABLED) {
> @@ -489,6 +495,8 @@ static void rtw_ops_stop_ap(struct ieee80211_hw *hw,
> {
> struct rtw_dev *rtwdev = hw->priv;
>
> + rtw_fw_csa_stop(rtwdev, vif);
> +
> mutex_lock(&rtwdev->mutex);
> rtw_write32_clr(rtwdev, REG_TCR, BIT_TCR_UPDATE_HGQMD);
> rtw_write16(rtwdev, REG_ATIMWND, ATIMWND_DEFAULT);
> @@ -556,6 +564,15 @@ static int rtw_ops_set_tim(struct ieee80211_hw *hw, struct ieee80211_sta *sta,
> return 0;
> }
>
> +static void rtw_ops_channel_switch_beacon(struct ieee80211_hw *hw,
> + struct ieee80211_vif *vif,
> + struct cfg80211_chan_def *chandef)
> +{
> + struct rtw_dev *rtwdev = hw->priv;
> +
> + rtw_fw_csa_start(rtwdev, vif);
> +}
> +
> static int rtw_ops_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
> struct ieee80211_vif *vif, struct ieee80211_sta *sta,
> struct ieee80211_key_conf *key)
> @@ -626,7 +643,8 @@ static int rtw_ops_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
> }
>
> /* download new cam settings for PG to backup */
> - if (rtw_get_lps_deep_mode(rtwdev) == LPS_DEEP_MODE_PG)
> + if (rtw_get_lps_deep_mode(rtwdev) == LPS_DEEP_MODE_PG &&
> + !rtw_fw_csa_active(rtwdev))
Think of this deeper.... Is it existing race between set_key and !csa->active?
> rtw_fw_download_rsvd_page(rtwdev);
>
> out:
> @@ -846,6 +864,7 @@ static int rtw_ops_suspend(struct ieee80211_hw *hw,
> int ret;
>
> mutex_lock(&rtwdev->mutex);
> + rtw_fw_csa_stop(rtwdev, rtwdev->csa_vif);
Since you access rtwdev->csa_vif, should this take wiphy_lock?
> ret = rtw_wow_suspend(rtwdev, wowlan);
> if (ret)
> rtw_err(rtwdev, "failed to suspend for wow %d\n", ret);
> @@ -893,19 +912,30 @@ static int rtw_ops_hw_scan(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
> struct rtw_dev *rtwdev = hw->priv;
> int ret;
>
> - if (!rtw_fw_feature_check(&rtwdev->fw, FW_FEATURE_SCAN_OFFLOAD))
> - return 1;
> + mutex_lock(&rtwdev->mutex);
guard(mutex)( &rtwdev->mutex); ?
>
> - if (test_bit(RTW_FLAG_SCANNING, rtwdev->flags))
> - return -EBUSY;
> + if (rtw_fw_csa_active(rtwdev)) {
> + ret = -EBUSY;
> + goto out;
> + }
> +
> + if (!rtw_fw_feature_check(&rtwdev->fw, FW_FEATURE_SCAN_OFFLOAD)) {
> + ret = 1;
> + goto out;
> + }
> +
> + if (test_bit(RTW_FLAG_SCANNING, rtwdev->flags)) {
> + ret = -EBUSY;
> + goto out;
> + }
>
> - mutex_lock(&rtwdev->mutex);
> rtw_hw_scan_start(rtwdev, vif, req);
> ret = rtw_hw_scan_offload(rtwdev, vif, true);
> if (ret) {
> rtw_hw_scan_abort(rtwdev);
> rtw_err(rtwdev, "HW scan failed with status: %d\n", ret);
> }
> +out:
> mutex_unlock(&rtwdev->mutex);
>
> return ret;
next prev parent reply other threads:[~2026-10-07 6:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-07 6:11 [PATCH rtw-next v4 0/2] wifi: rtw88: channel switch in AP mode Mehmet Fide
2026-10-07 6:11 ` [PATCH rtw-next v4 1/2] wifi: rtw88: download the beacon the reserved page was built with Mehmet Fide
2026-10-07 6:11 ` [PATCH rtw-next v4 2/2] wifi: rtw88: support channel switch in AP mode Mehmet Fide
2026-10-07 6:39 ` Ping-Ke Shih [this message]
2026-10-07 8:09 ` Mehmet Fide
2026-10-07 8:17 ` 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=63ac6992e6614de1a085131964974ff1@realtek.com \
--to=pkshih@realtek.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=luka.gejak@linux.dev \
--cc=mehmet.fide@gmail.com \
--cc=mehmet.fide@screeningeagle.com \
--cc=rtl8821cerfe2@gmail.com \
/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.