* [PATCH v3 2/3] wifi: iwlwifi: fw: replace use of system_unbound_wq with system_dfl_wq
From: Marco Crivellari @ 2026-02-10 14:33 UTC (permalink / raw)
To: linux-kernel, linux-wireless
Cc: Tejun Heo, Lai Jiangshan, Frederic Weisbecker,
Sebastian Andrzej Siewior, Marco Crivellari, Michal Hocko,
Miri Korenblit, Johannes Berg
In-Reply-To: <20260210143332.206146-1-marco.crivellari@suse.com>
This patch continues the effort to refactor workqueue APIs, which has begun
with the changes introducing new workqueues and a new alloc_workqueue flag:
commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
The point of the refactoring is to eventually alter the default behavior of
workqueues to become unbound by default so that their workload placement is
optimized by the scheduler.
Before that to happen after a careful review and conversion of each individual
case, workqueue users must be converted to the better named new workqueues with
no intended behaviour changes:
system_wq -> system_percpu_wq
system_unbound_wq -> system_dfl_wq
This way the old obsolete workqueues (system_wq, system_unbound_wq) can be
removed in the future.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
---
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
index 2ce55859641c..e5f31b82339a 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
+++ b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
@@ -2933,7 +2933,7 @@ int iwl_fw_dbg_collect_desc(struct iwl_fw_runtime *fwrt,
IWL_WARN(fwrt, "Collecting data: trigger %d fired.\n",
le32_to_cpu(desc->trig_desc.type));
- queue_delayed_work(system_unbound_wq, &wk_data->wk,
+ queue_delayed_work(system_dfl_wq, &wk_data->wk,
usecs_to_jiffies(delay));
return 0;
@@ -3237,7 +3237,7 @@ int iwl_fw_dbg_ini_collect(struct iwl_fw_runtime *fwrt,
if (sync)
iwl_fw_dbg_collect_sync(fwrt, idx);
else
- queue_delayed_work(system_unbound_wq,
+ queue_delayed_work(system_dfl_wq,
&fwrt->dump.wks[idx].wk,
usecs_to_jiffies(delay));
--
2.52.0
^ permalink raw reply related
* [PATCH v3 3/3] wifi: iwlwifi: mvm: replace use of system_wq with system_percpu_wq
From: Marco Crivellari @ 2026-02-10 14:33 UTC (permalink / raw)
To: linux-kernel, linux-wireless
Cc: Tejun Heo, Lai Jiangshan, Frederic Weisbecker,
Sebastian Andrzej Siewior, Marco Crivellari, Michal Hocko,
Miri Korenblit, Johannes Berg
In-Reply-To: <20260210143332.206146-1-marco.crivellari@suse.com>
This patch continues the effort to refactor workqueue APIs, which has begun
with the changes introducing new workqueues and a new alloc_workqueue flag:
commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
The point of the refactoring is to eventually alter the default behavior of
workqueues to become unbound by default so that their workload placement is
optimized by the scheduler.
Before that to happen after a careful review and conversion of each individual
case, workqueue users must be converted to the better named new workqueues with
no intended behaviour changes:
system_wq -> system_percpu_wq
system_unbound_wq -> system_dfl_wq
This way the old obsolete workqueues (system_wq, system_unbound_wq) can be
removed in the future.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/tdls.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tdls.c b/drivers/net/wireless/intel/iwlwifi/mvm/tdls.c
index 36379b738de1..0df31639fa5e 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tdls.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tdls.c
@@ -234,7 +234,7 @@ void iwl_mvm_rx_tdls_notif(struct iwl_mvm *mvm, struct iwl_rx_cmd_buffer *rxb)
* Also convert TU to msec.
*/
delay = TU_TO_MS(vif->bss_conf.dtim_period * vif->bss_conf.beacon_int);
- mod_delayed_work(system_wq, &mvm->tdls_cs.dwork,
+ mod_delayed_work(system_percpu_wq, &mvm->tdls_cs.dwork,
msecs_to_jiffies(delay));
iwl_mvm_tdls_update_cs_state(mvm, IWL_MVM_TDLS_SW_ACTIVE);
@@ -548,7 +548,7 @@ iwl_mvm_tdls_channel_switch(struct ieee80211_hw *hw,
*/
delay = 2 * TU_TO_MS(vif->bss_conf.dtim_period *
vif->bss_conf.beacon_int);
- mod_delayed_work(system_wq, &mvm->tdls_cs.dwork,
+ mod_delayed_work(system_percpu_wq, &mvm->tdls_cs.dwork,
msecs_to_jiffies(delay));
return 0;
}
@@ -659,6 +659,6 @@ iwl_mvm_tdls_recv_channel_switch(struct ieee80211_hw *hw,
/* register a timeout in case we don't succeed in switching */
delay = vif->bss_conf.dtim_period * vif->bss_conf.beacon_int *
1024 / 1000;
- mod_delayed_work(system_wq, &mvm->tdls_cs.dwork,
+ mod_delayed_work(system_percpu_wq, &mvm->tdls_cs.dwork,
msecs_to_jiffies(delay));
}
--
2.52.0
^ permalink raw reply related
* RE: [PATCH v3 1/3] wifi: iwlwifi: replace use of system_unbound_wq with system_dfl_wq
From: Korenblit, Miriam Rachel @ 2026-02-10 14:38 UTC (permalink / raw)
To: Marco Crivellari, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org
Cc: Tejun Heo, Lai Jiangshan, Frederic Weisbecker,
Sebastian Andrzej Siewior, Michal Hocko, Johannes Berg
In-Reply-To: <20260210143332.206146-2-marco.crivellari@suse.com>
> -----Original Message-----
> From: Marco Crivellari <marco.crivellari@suse.com>
> Sent: Tuesday, February 10, 2026 4:34 PM
> To: linux-kernel@vger.kernel.org; linux-wireless@vger.kernel.org
> Cc: Tejun Heo <tj@kernel.org>; Lai Jiangshan <jiangshanlai@gmail.com>; Frederic
> Weisbecker <frederic@kernel.org>; Sebastian Andrzej Siewior
> <bigeasy@linutronix.de>; Marco Crivellari <marco.crivellari@suse.com>; Michal
> Hocko <mhocko@suse.com>; Korenblit, Miriam Rachel
> <miriam.rachel.korenblit@intel.com>; Johannes Berg
> <johannes@sipsolutions.net>
> Subject: [PATCH v3 1/3] wifi: iwlwifi: replace use of system_unbound_wq with
> system_dfl_wq
>
> This patch continues the effort to refactor workqueue APIs, which has begun with
> the changes introducing new workqueues and a new alloc_workqueue flag:
>
> commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and
> system_dfl_wq")
> commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
>
> The point of the refactoring is to eventually alter the default behavior of
> workqueues to become unbound by default so that their workload placement is
> optimized by the scheduler.
>
> Before that to happen after a careful review and conversion of each individual
> case, workqueue users must be converted to the better named new workqueues
> with no intended behaviour changes:
>
> system_wq -> system_percpu_wq
> system_unbound_wq -> system_dfl_wq
>
> This way the old obsolete workqueues (system_wq, system_unbound_wq) can be
> removed in the future.
>
> Suggested-by: Tejun Heo <tj@kernel.org>
> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
> ---
> drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
> b/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
> index a552669db6e2..2f24b639c133 100644
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
> @@ -1092,7 +1092,7 @@ static inline void iwl_trans_schedule_reset(struct
> iwl_trans *trans,
> */
> trans->restart.during_reset = test_bit(STATUS_IN_SW_RESET,
> &trans->status);
> - queue_delayed_work(system_unbound_wq, &trans->restart.wk, 0);
> + queue_delayed_work(system_dfl_wq, &trans->restart.wk, 0);
> }
>
> static inline void iwl_trans_fw_error(struct iwl_trans *trans,
> --
> 2.52.0
>
Already took this in its previous version, I sent an email with "Acked-by" 😊
Same for the other one. Only the mvm one needed to be fixed
^ permalink raw reply
* RE: [PATCH v3 3/3] wifi: iwlwifi: mvm: replace use of system_wq with system_percpu_wq
From: Korenblit, Miriam Rachel @ 2026-02-10 14:40 UTC (permalink / raw)
To: Marco Crivellari, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org
Cc: Tejun Heo, Lai Jiangshan, Frederic Weisbecker,
Sebastian Andrzej Siewior, Michal Hocko, Johannes Berg
In-Reply-To: <20260210143332.206146-4-marco.crivellari@suse.com>
> -----Original Message-----
> From: Marco Crivellari <marco.crivellari@suse.com>
> Sent: Tuesday, February 10, 2026 4:34 PM
> To: linux-kernel@vger.kernel.org; linux-wireless@vger.kernel.org
> Cc: Tejun Heo <tj@kernel.org>; Lai Jiangshan <jiangshanlai@gmail.com>; Frederic
> Weisbecker <frederic@kernel.org>; Sebastian Andrzej Siewior
> <bigeasy@linutronix.de>; Marco Crivellari <marco.crivellari@suse.com>; Michal
> Hocko <mhocko@suse.com>; Korenblit, Miriam Rachel
> <miriam.rachel.korenblit@intel.com>; Johannes Berg
> <johannes@sipsolutions.net>
> Subject: [PATCH v3 3/3] wifi: iwlwifi: mvm: replace use of system_wq with
> system_percpu_wq
>
> This patch continues the effort to refactor workqueue APIs, which has begun with
> the changes introducing new workqueues and a new alloc_workqueue flag:
>
> commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and
> system_dfl_wq")
> commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
>
> The point of the refactoring is to eventually alter the default behavior of
> workqueues to become unbound by default so that their workload placement is
> optimized by the scheduler.
>
> Before that to happen after a careful review and conversion of each individual
> case, workqueue users must be converted to the better named new workqueues
> with no intended behaviour changes:
>
> system_wq -> system_percpu_wq
> system_unbound_wq -> system_dfl_wq
>
> This way the old obsolete workqueues (system_wq, system_unbound_wq) can be
> removed in the future.
>
> Suggested-by: Tejun Heo <tj@kernel.org>
> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
> ---
> drivers/net/wireless/intel/iwlwifi/mvm/tdls.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tdls.c
> b/drivers/net/wireless/intel/iwlwifi/mvm/tdls.c
> index 36379b738de1..0df31639fa5e 100644
> --- a/drivers/net/wireless/intel/iwlwifi/mvm/tdls.c
> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/tdls.c
> @@ -234,7 +234,7 @@ void iwl_mvm_rx_tdls_notif(struct iwl_mvm *mvm,
> struct iwl_rx_cmd_buffer *rxb)
> * Also convert TU to msec.
> */
> delay = TU_TO_MS(vif->bss_conf.dtim_period * vif-
> >bss_conf.beacon_int);
> - mod_delayed_work(system_wq, &mvm->tdls_cs.dwork,
> + mod_delayed_work(system_percpu_wq, &mvm->tdls_cs.dwork,
> msecs_to_jiffies(delay));
>
> iwl_mvm_tdls_update_cs_state(mvm, IWL_MVM_TDLS_SW_ACTIVE);
> @@ -548,7 +548,7 @@ iwl_mvm_tdls_channel_switch(struct ieee80211_hw
> *hw,
> */
> delay = 2 * TU_TO_MS(vif->bss_conf.dtim_period *
> vif->bss_conf.beacon_int);
> - mod_delayed_work(system_wq, &mvm->tdls_cs.dwork,
> + mod_delayed_work(system_percpu_wq, &mvm->tdls_cs.dwork,
> msecs_to_jiffies(delay));
> return 0;
> }
> @@ -659,6 +659,6 @@ iwl_mvm_tdls_recv_channel_switch(struct
> ieee80211_hw *hw,
> /* register a timeout in case we don't succeed in switching */
> delay = vif->bss_conf.dtim_period * vif->bss_conf.beacon_int *
> 1024 / 1000;
> - mod_delayed_work(system_wq, &mvm->tdls_cs.dwork,
> + mod_delayed_work(system_percpu_wq, &mvm->tdls_cs.dwork,
> msecs_to_jiffies(delay));
> }
> --
> 2.52.0
Acked-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
^ permalink raw reply
* Re: [PATCH ath-current] wifi: ath12k: fix incorrect channel survey index
From: Remi Pommarel @ 2026-02-10 15:38 UTC (permalink / raw)
To: Yingying Tang; +Cc: ath12k, linux-wireless, yintang
In-Reply-To: <20260210024440.3422264-1-yingying.tang@oss.qualcomm.com>
On Tue, Feb 10, 2026 at 10:44:40AM +0800, Yingying Tang wrote:
> A wrong channel survey index was introduced in
> ath12k_mac_op_get_survey by [1], which can cause ACS to fail.
>
> The index is decremented before being used, resulting in an
> incorrect value when accessing the channel survey data.
>
> Fix the index handling to ensure the correct survey entry is
> used and avoid ACS failures.
>
> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
>
> Fixes: 4f242b1d6996 ("wifi: ath12k: support get_survey mac op for single wiphy") # [1]
> Signed-off-by: Yingying Tang <yingying.tang@oss.qualcomm.com>
>
> ---
> drivers/net/wireless/ath/ath12k/mac.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
> index e0e49f782bf8..86ce7d87b5a5 100644
> --- a/drivers/net/wireless/ath/ath12k/mac.c
> +++ b/drivers/net/wireless/ath/ath12k/mac.c
> @@ -13086,6 +13086,7 @@ static int ath12k_mac_op_get_survey(struct ieee80211_hw *hw, int idx,
> struct ath12k *ar;
> struct ieee80211_supported_band *sband;
> struct survey_info *ar_survey;
> + int orig_idx = idx;
>
> lockdep_assert_wiphy(hw->wiphy);
>
> @@ -13120,7 +13121,7 @@ static int ath12k_mac_op_get_survey(struct ieee80211_hw *hw, int idx,
> return -ENOENT;
> }
>
> - ar_survey = &ar->survey[idx];
> + ar_survey = &ar->survey[orig_idx];
>
> ath12k_mac_update_bss_chan_survey(ar, &sband->channels[idx]);
>
This change appears to break channel survey data on the QCN9274 (a
dual-band device), because each radio has its own ar (ath12k_radio)
instance.
A proper fix, for both single and dual band, could need to fetch the
survey index info from the frequency. Maybe reusing the freq_to_idx()
from wmi.c that already does the conversion as below ?
ar_survey = &ar->survey[freq_to_idx(ar, sband->channels[idx].center_freq)];
Another solution could be to keep your patch and just remove the
following bits from freq_to_idx() as below.
diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
index 3ce5fcb0e460..d05b837f7d47 100644
--- a/drivers/net/wireless/ath/ath12k/wmi.c
+++ b/drivers/net/wireless/ath/ath12k/wmi.c
@@ -6568,9 +6568,6 @@ static int freq_to_idx(struct ath12k *ar, int freq)
int band, ch, idx = 0;
for (band = NL80211_BAND_2GHZ; band < NUM_NL80211_BANDS; band++) {
- if (!ar->mac.sbands[band].channels)
- continue;
-
sband = hw->wiphy->bands[band];
if (!sband)
continue;
With that being said, there might be cleaner ways to do that though
(e.g. keeping survey result in ath12k_hw instead of per radio, ...).
Thanks,
--
Remi
^ permalink raw reply related
* Re: [RFC PATCH] ath11k: add ath11k_mac_op_flush_sta to properly flush pending packets
From: Vasanthakumar Thiagarajan @ 2026-02-10 17:09 UTC (permalink / raw)
To: Florian Maurer, Jeff Johnson, ath11k; +Cc: linux-wireless
In-Reply-To: <GV1P250MB14333A5BF24623C4753A10E1E8E0A@GV1P250MB1433.EURP250.PROD.OUTLOOK.COM>
On 10/7/2025 1:41 PM, Florian Maurer wrote:
> When a STA is marked as no longer authorized, if the driver doesn't
> implement flush_sta(), mac80211 calls ieee80211_flush_queues() to
> flush hardware queues to avoid sending unencrypted frames.
>
> This has became a problem for ath11k because ieee80211_flush_queues()
> will stop all traffic and call ath11k_flush, which waits until the
> whole HW queue is empty. In a busy environment this will trigger a
> timeout warning and stalls other STAs.
>
> Fix this by implementing flush_sta method using WMI command to flush
> frames of a specific STA.
> Flushed frames will be marked as discard in tx complete indication.
>
> warning print "ath11k c000000.wifi: failed to flush transmit queue 0"
> was observed on various openwrt devices, and is fixed through this patch.
>
> Signed-off-by: Florian Maurer <f.maurer@outlook.de>
> Tested-by: Florian Maurer <f.maurer@outlook.de>
> Co-authored-by: Benjamin Berg <benjamin@sipsolutions.net>
> Tested-by: Flole <flole@flole.de>
> ---
> We tested this patch and it solved the problem of flushing the transmit
> queues taking too long when the AP is busy.
> We did not confirm if this flush is implemented to guarantee that no
> unencrypted frames are sent out on station removal.
> Could someone with more knowledge about the firmware behavior check
> wether this approach is feasible or if a different approach should be
> taken.
> It is not clear to me if the approach taken in "wifi: ath10k: Flush
> only requested txq in ath10k_flush()" might be better.
> https://lore.kernel.org/linux-wireless/01d859e8e574a1f5d0b916333fe0b5cda859af9b.1732293922.git.repk@triplefau.lt/
>
> Regards
> Florian
>
> drivers/net/wireless/ath/ath11k/mac.c | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
> index 106e2530b64e..a94649edd4ed 100644
> --- a/drivers/net/wireless/ath/ath11k/mac.c
> +++ b/drivers/net/wireless/ath/ath11k/mac.c
> @@ -8330,6 +8330,24 @@ static void ath11k_mac_op_flush(struct ieee80211_hw *hw, struct ieee80211_vif *v
> ath11k_mac_flush_tx_complete(ar);
> }
>
> +static void ath11k_mac_op_flush_sta(struct ieee80211_hw *hw,
> + struct ieee80211_vif *vif,
> + struct ieee80211_sta *sta)
> +{
> + struct ath11k_vif *arvif = (void *)vif->drv_priv;
> + struct ath11k *ar = hw->priv;
> + struct peer_flush_params params = {
> + .peer_tid_bitmap = 0xFF,
The recommendation from the firmware developers is that all 32-bit has to be sent
in WMI_PEER_FLUSH_TIDS_CMDID for both AP and STA mode, otherwise some of the tid
queues may still have pending packets. Firmware does the intersection and gracefully
ignores the inactive tid queues when all the bits are set. We may need to check the
firmware crash dump to understand the issue with 0xffffffff bitmap.
Vasanth
^ permalink raw reply
* Re: [PATCH v3 2/2] dt-bindings: net: wireless: mt76: clarify backoff limit format
From: Ryder Lee @ 2026-02-10 18:12 UTC (permalink / raw)
To: robh@kernel.org, nbd@nbd.name
Cc: linux-wireless@vger.kernel.org,
linux-mediatek@lists.infradead.org,
Allen Ye (葉芷勳), devicetree@vger.kernel.org
In-Reply-To: <69521aebefef405bad5117d4d5d5fef4a5dfb7e8.1770746444.git.ryder.lee@mediatek.com>
On Tue, 2026-02-10 at 10:08 -0800, Ryder Lee wrote:
> Clarify the format of path backoff limit properties in mt76 binding.
> Add explicit documentation for connac2 (mt7915, mt7981, mt7986) and
> connac3 (mt7990, mt7992, mt7996...) devices, including the difference
> in beamforming and non-beamforming entries.
>
> Also reformat the description to make is more precise.
>
> Signed-off-by: Allen Ye <allen.ye@mediatek.com>
> Co-developed-by: Allen Ye <allen.ye@mediatek.com>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
> .../bindings/net/wireless/mediatek,mt76.yaml | 20
> +++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
> b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
> index ae6b97cdc..4156e1c97 100644
> ---
> a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
> +++
> b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
> @@ -252,6 +252,16 @@ properties:
> followed by 10 power limit values. The order
> of the
> channel resource unit settings is RU26, RU52,
> RU106,
> RU242/SU20, RU484/SU40, RU996/SU80 and
> RU2x996/SU160.
> + - For connac2
> + - Beamforming entries for BW20~BW160 and
> OFDM do not
> + include 1T1ss.
> + - When 1T1ss is not used, it should be
> filled with 0.
> + - For connac3
> + - Beamforming entries for BW20~BW160 and RU
> include
> + 1T1ss, but OFDM does not include 1T1ss.
> + - 1T1ss is taken into account, so no need to
> fill with 0.
> + Non-beamforming and RU entries for both
> connac2 and
> + connac3 include 1T1ss.
> minItems: 1
> maxItems: 7
> items:
> @@ -270,6 +280,16 @@ properties:
> followed by 10 power limit values. The order
> of the
> channel resource unit settings is RU26, RU52,
> RU106,
> RU242/SU20, RU484/SU40, RU996/SU80 and
> RU2x996/SU160.
> + - For connac2
> + - Beamforming entries for BW20~BW160 and
> OFDM do not
> + include 1T1ss.
> + - When 1T1ss is not used, it should be
> filled with 0.
> + - For connac3
> + - Beamforming entries for BW20~BW160 and RU
> include
> + 1T1ss, but OFDM does not include 1T1ss.
> + - 1T1ss is taken into account, so no need to
> fill with 0.
> + Non-beamforming and RU entries for both
> connac2 and
> + connac3 include 1T1ss.
> minItems: 1
> maxItems: 7
> items:
Oops. Please ignore this patch, I mistakenly added the wrong entries.
Ryder
^ permalink raw reply
* Re: [PATCH v3 2/2] dt-bindings: net: wireless: mt76: clarify backoff limit format
From: Ryder Lee @ 2026-02-10 18:16 UTC (permalink / raw)
To: robh@kernel.org, nbd@nbd.name
Cc: linux-wireless@vger.kernel.org,
linux-mediatek@lists.infradead.org,
Allen Ye (葉芷勳), devicetree@vger.kernel.org
In-Reply-To: <52244d9cbd63ff6b660074d0f44724896d1e88e3.camel@mediatek.com>
On Tue, 2026-02-10 at 18:12 +0000, Ryder Lee wrote:
> On Tue, 2026-02-10 at 10:08 -0800, Ryder Lee wrote:
> > Clarify the format of path backoff limit properties in mt76
> > binding.
> > Add explicit documentation for connac2 (mt7915, mt7981, mt7986) and
> > connac3 (mt7990, mt7992, mt7996...) devices, including the
> > difference
> > in beamforming and non-beamforming entries.
> >
> > Also reformat the description to make is more precise.
> >
> > Signed-off-by: Allen Ye <allen.ye@mediatek.com>
> > Co-developed-by: Allen Ye <allen.ye@mediatek.com>
> > Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> > ---
> > .../bindings/net/wireless/mediatek,mt76.yaml | 20
> > +++++++++++++++++++
> > 1 file changed, 20 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
> > b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
> > index ae6b97cdc..4156e1c97 100644
> > ---
> > a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
> > +++
> > b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
> > @@ -252,6 +252,16 @@ properties:
> > followed by 10 power limit values. The order
> > of the
> > channel resource unit settings is RU26,
> > RU52,
> > RU106,
> > RU242/SU20, RU484/SU40, RU996/SU80 and
> > RU2x996/SU160.
> > + - For connac2
> > + - Beamforming entries for BW20~BW160 and
> > OFDM do not
> > + include 1T1ss.
> > + - When 1T1ss is not used, it should be
> > filled with 0.
> > + - For connac3
> > + - Beamforming entries for BW20~BW160 and
> > RU
> > include
> > + 1T1ss, but OFDM does not include 1T1ss.
> > + - 1T1ss is taken into account, so no need
> > to
> > fill with 0.
> > + Non-beamforming and RU entries for both
> > connac2 and
> > + connac3 include 1T1ss.
> > minItems: 1
> > maxItems: 7
> > items:
> > @@ -270,6 +280,16 @@ properties:
> > followed by 10 power limit values. The order
> > of the
> > channel resource unit settings is RU26,
> > RU52,
> > RU106,
> > RU242/SU20, RU484/SU40, RU996/SU80 and
> > RU2x996/SU160.
> > + - For connac2
> > + - Beamforming entries for BW20~BW160 and
> > OFDM do not
> > + include 1T1ss.
> > + - When 1T1ss is not used, it should be
> > filled with 0.
> > + - For connac3
> > + - Beamforming entries for BW20~BW160 and
> > RU
> > include
> > + 1T1ss, but OFDM does not include 1T1ss.
> > + - 1T1ss is taken into account, so no need
> > to
> > fill with 0.
> > + Non-beamforming and RU entries for both
> > connac2 and
> > + connac3 include 1T1ss.
> > minItems: 1
> > maxItems: 7
> > items:
>
> Oops. Please ignore this patch, I mistakenly added the wrong entries.
>
> Ryder
Oh, never mind. This is actually correct. I must have been a bit dizzy.
Ryder
^ permalink raw reply
* [PATCH v3 1/2] wifi: mt76: fix backoff fields and max_power calculation
From: Ryder Lee @ 2026-02-10 18:08 UTC (permalink / raw)
To: Felix Fietkau, Rob Herring
Cc: devicetree, linux-mediatek, linux-wireless, Allen Ye, Ryder Lee
From: Allen Ye <allen.ye@mediatek.com>
The maximum power value may exist in either the data or backoff field.
Previously, backoff power limits were not considered in txpower reporting.
This patch ensures mt76 also considers backoff values in the SKU table.
Also, each RU entry (RU26, RU52, RU106, BW20, ...) in the DTS corresponds
to 10 stream combinations (1T1ss, 2T1ss, 3T1ss, 4T1ss, 2T2ss, 3T2ss,
4T2ss, 3T3ss, 4T3ss, 4T4ss).
For beamforming tables:
- In connac2, beamforming entries for BW20~BW160, and OFDM do not include
1T1ss.
- In connac3, beamforming entries for BW20~BW160, and RU include 1T1ss,
but OFDM beamforming does not include 1T1ss.
Non-beamforming and RU entries for both connac2 and connac3 include 1T1ss.
Fixes: b05ab4be9fd7 ("wifi: mt76: mt7915: add bf backoff limit table support")
Signed-off-by: Allen Ye <allen.ye@mediatek.com>
Co-developed-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
---
v1:
- Add "wifi:" prefix to the subject.
v2:
- Fix checkpatch errors.
- Remove unnecessary style changes.
- Add explanation for connac2 index adjustment.
v3:
- Fix "case"s for MT76_SKU_BACKOFF_BF_OFFSET and MT76_SKU_BACKOFF.
- add more explanation for connac2/connac3 tables.
---
drivers/net/wireless/mediatek/mt76/eeprom.c | 154 ++++++++++++++------
drivers/net/wireless/mediatek/mt76/mt76.h | 1 -
2 files changed, 109 insertions(+), 46 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/eeprom.c b/drivers/net/wireless/mediatek/mt76/eeprom.c
index 573400d57..afdb73661 100644
--- a/drivers/net/wireless/mediatek/mt76/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/eeprom.c
@@ -9,6 +9,13 @@
#include <linux/nvmem-consumer.h>
#include <linux/etherdevice.h>
#include "mt76.h"
+#include "mt76_connac.h"
+
+enum mt76_sku_type {
+ MT76_SKU_RATE,
+ MT76_SKU_BACKOFF,
+ MT76_SKU_BACKOFF_BF_OFFSET,
+};
static int mt76_get_of_eeprom_data(struct mt76_dev *dev, void *eep, int len)
{
@@ -292,7 +299,6 @@ mt76_find_channel_node(struct device_node *np, struct ieee80211_channel *chan)
}
EXPORT_SYMBOL_GPL(mt76_find_channel_node);
-
static s8
mt76_get_txs_delta(struct device_node *np, u8 nss)
{
@@ -306,9 +312,24 @@ mt76_get_txs_delta(struct device_node *np, u8 nss)
return be32_to_cpu(val[nss - 1]);
}
+static inline u8 mt76_backoff_n_chains(struct mt76_dev *dev, u8 idx)
+{
+ /* 0:1T1ss, 1:2T1ss, ..., 14:5T5ss */
+ static const u8 connac3_table[] = {
+ 1, 2, 3, 4, 5, 2, 3, 4, 5, 3, 4, 5, 4, 5, 5};
+ static const u8 connac2_table[] = {
+ 1, 2, 3, 4, 2, 3, 4, 3, 4, 4, 0, 0, 0, 0, 0};
+
+ if (idx >= ARRAY_SIZE(connac3_table))
+ return 0;
+
+ return is_mt799x(dev) ? connac3_table[idx] : connac2_table[idx];
+}
+
static void
-mt76_apply_array_limit(s8 *pwr, size_t pwr_len, const s8 *data,
- s8 target_power, s8 nss_delta, s8 *max_power)
+mt76_apply_array_limit(struct mt76_dev *dev, s8 *pwr, size_t pwr_len,
+ const s8 *data, s8 target_power, s8 nss_delta,
+ s8 *max_power, int n_chains, enum mt76_sku_type type)
{
int i;
@@ -316,18 +337,51 @@ mt76_apply_array_limit(s8 *pwr, size_t pwr_len, const s8 *data,
return;
for (i = 0; i < pwr_len; i++) {
- pwr[i] = min_t(s8, target_power, data[i] + nss_delta);
+ u8 backoff_chain_idx = i;
+ int backoff_n_chains;
+ s8 backoff_delta;
+ s8 delta;
+
+ switch (type) {
+ case MT76_SKU_RATE:
+ delta = 0;
+ backoff_delta = 0;
+ backoff_n_chains = 0;
+ break;
+ case MT76_SKU_BACKOFF_BF_OFFSET:
+ backoff_chain_idx += 1;
+ fallthrough;
+ case MT76_SKU_BACKOFF:
+ delta = mt76_tx_power_path_delta(n_chains);
+ backoff_n_chains = mt76_backoff_n_chains(dev, backoff_chain_idx);
+ backoff_delta = mt76_tx_power_path_delta(backoff_n_chains);
+ break;
+ default:
+ return;
+ }
+
+ pwr[i] = min_t(s8, target_power + delta - backoff_delta, data[i] + nss_delta);
+
+ /* used for padding, doesn't need to be considered */
+ if (data[i] >= S8_MAX - 1)
+ continue;
+
+ /* only consider backoff value for the configured chain number */
+ if (type != MT76_SKU_RATE && n_chains != backoff_n_chains)
+ continue;
+
*max_power = max(*max_power, pwr[i]);
}
}
static void
-mt76_apply_multi_array_limit(s8 *pwr, size_t pwr_len, s8 pwr_num,
- const s8 *data, size_t len, s8 target_power,
- s8 nss_delta)
+mt76_apply_multi_array_limit(struct mt76_dev *dev, s8 *pwr, size_t pwr_len,
+ s8 pwr_num, const s8 *data, size_t len,
+ s8 target_power, s8 nss_delta, s8 *max_power,
+ int n_chains, enum mt76_sku_type type)
{
+ static const int connac2_backoff_ru_idx = 2;
int i, cur;
- s8 max_power = -128;
if (!data)
return;
@@ -337,8 +391,26 @@ mt76_apply_multi_array_limit(s8 *pwr, size_t pwr_len, s8 pwr_num,
if (len < pwr_len + 1)
break;
- mt76_apply_array_limit(pwr + pwr_len * i, pwr_len, data + 1,
- target_power, nss_delta, &max_power);
+ /* Each RU entry (RU26, RU52, RU106, BW20, ...) in the DTS
+ * corresponds to 10 stream combinations (1T1ss, 2T1ss, 3T1ss,
+ * 4T1ss, 2T2ss, 3T2ss, 4T2ss, 3T3ss, 4T3ss, 4T4ss).
+ *
+ * For beamforming tables:
+ * - In connac2, beamforming entries for BW20~BW160 and OFDM
+ * do not include 1T1ss.
+ * - In connac3, beamforming entries for BW20~BW160 and RU
+ * include 1T1ss, but OFDM beamforming does not include 1T1ss.
+ *
+ * Non-beamforming and RU entries for both connac2 and connac3
+ * include 1T1ss.
+ */
+ if (!is_mt799x(dev) && type == MT76_SKU_BACKOFF &&
+ i > connac2_backoff_ru_idx)
+ type = MT76_SKU_BACKOFF_BF_OFFSET;
+
+ mt76_apply_array_limit(dev, pwr + pwr_len * i, pwr_len, data + 1,
+ target_power, nss_delta, max_power,
+ n_chains, type);
if (--cur > 0)
continue;
@@ -360,18 +432,11 @@ s8 mt76_get_rate_power_limits(struct mt76_phy *phy,
struct device_node *np;
const s8 *val;
char name[16];
- u32 mcs_rates = dev->drv->mcs_rates;
- u32 ru_rates = ARRAY_SIZE(dest->ru[0]);
char band;
size_t len;
- s8 max_power = 0;
- s8 max_power_backoff = -127;
+ s8 max_power = -127;
s8 txs_delta;
int n_chains = hweight16(phy->chainmask);
- s8 target_power_combine = target_power + mt76_tx_power_path_delta(n_chains);
-
- if (!mcs_rates)
- mcs_rates = 10;
memset(dest, target_power, sizeof(*dest) - sizeof(dest->path));
memset(&dest->path, 0, sizeof(dest->path));
@@ -409,46 +474,45 @@ s8 mt76_get_rate_power_limits(struct mt76_phy *phy,
txs_delta = mt76_get_txs_delta(np, hweight16(phy->chainmask));
val = mt76_get_of_array_s8(np, "rates-cck", &len, ARRAY_SIZE(dest->cck));
- mt76_apply_array_limit(dest->cck, ARRAY_SIZE(dest->cck), val,
- target_power, txs_delta, &max_power);
+ mt76_apply_array_limit(dev, dest->cck, ARRAY_SIZE(dest->cck), val,
+ target_power, txs_delta, &max_power, n_chains, MT76_SKU_RATE);
- val = mt76_get_of_array_s8(np, "rates-ofdm",
- &len, ARRAY_SIZE(dest->ofdm));
- mt76_apply_array_limit(dest->ofdm, ARRAY_SIZE(dest->ofdm), val,
- target_power, txs_delta, &max_power);
+ val = mt76_get_of_array_s8(np, "rates-ofdm", &len, ARRAY_SIZE(dest->ofdm));
+ mt76_apply_array_limit(dev, dest->ofdm, ARRAY_SIZE(dest->ofdm), val,
+ target_power, txs_delta, &max_power, n_chains, MT76_SKU_RATE);
- val = mt76_get_of_array_s8(np, "rates-mcs", &len, mcs_rates + 1);
- mt76_apply_multi_array_limit(dest->mcs[0], ARRAY_SIZE(dest->mcs[0]),
- ARRAY_SIZE(dest->mcs), val, len,
- target_power, txs_delta);
+ val = mt76_get_of_array_s8(np, "rates-mcs", &len, ARRAY_SIZE(dest->mcs[0]) + 1);
+ mt76_apply_multi_array_limit(dev, dest->mcs[0], ARRAY_SIZE(dest->mcs[0]),
+ ARRAY_SIZE(dest->mcs), val, len, target_power,
+ txs_delta, &max_power, n_chains, MT76_SKU_RATE);
- val = mt76_get_of_array_s8(np, "rates-ru", &len, ru_rates + 1);
- mt76_apply_multi_array_limit(dest->ru[0], ARRAY_SIZE(dest->ru[0]),
- ARRAY_SIZE(dest->ru), val, len,
- target_power, txs_delta);
+ val = mt76_get_of_array_s8(np, "rates-ru", &len, ARRAY_SIZE(dest->ru[0]) + 1);
+ mt76_apply_multi_array_limit(dev, dest->ru[0], ARRAY_SIZE(dest->ru[0]),
+ ARRAY_SIZE(dest->ru), val, len, target_power,
+ txs_delta, &max_power, n_chains, MT76_SKU_RATE);
- max_power_backoff = max_power;
val = mt76_get_of_array_s8(np, "paths-cck", &len, ARRAY_SIZE(dest->path.cck));
- mt76_apply_array_limit(dest->path.cck, ARRAY_SIZE(dest->path.cck), val,
- target_power_combine, txs_delta, &max_power_backoff);
+ mt76_apply_array_limit(dev, dest->path.cck, ARRAY_SIZE(dest->path.cck), val,
+ target_power, txs_delta, &max_power, n_chains, MT76_SKU_BACKOFF);
val = mt76_get_of_array_s8(np, "paths-ofdm", &len, ARRAY_SIZE(dest->path.ofdm));
- mt76_apply_array_limit(dest->path.ofdm, ARRAY_SIZE(dest->path.ofdm), val,
- target_power_combine, txs_delta, &max_power_backoff);
+ mt76_apply_array_limit(dev, dest->path.ofdm, ARRAY_SIZE(dest->path.ofdm), val,
+ target_power, txs_delta, &max_power, n_chains, MT76_SKU_BACKOFF);
val = mt76_get_of_array_s8(np, "paths-ofdm-bf", &len, ARRAY_SIZE(dest->path.ofdm_bf));
- mt76_apply_array_limit(dest->path.ofdm_bf, ARRAY_SIZE(dest->path.ofdm_bf), val,
- target_power_combine, txs_delta, &max_power_backoff);
+ mt76_apply_array_limit(dev, dest->path.ofdm_bf, ARRAY_SIZE(dest->path.ofdm_bf), val,
+ target_power, txs_delta, &max_power, n_chains,
+ MT76_SKU_BACKOFF_BF_OFFSET);
val = mt76_get_of_array_s8(np, "paths-ru", &len, ARRAY_SIZE(dest->path.ru[0]) + 1);
- mt76_apply_multi_array_limit(dest->path.ru[0], ARRAY_SIZE(dest->path.ru[0]),
- ARRAY_SIZE(dest->path.ru), val, len,
- target_power_combine, txs_delta);
+ mt76_apply_multi_array_limit(dev, dest->path.ru[0], ARRAY_SIZE(dest->path.ru[0]),
+ ARRAY_SIZE(dest->path.ru), val, len, target_power,
+ txs_delta, &max_power, n_chains, MT76_SKU_BACKOFF);
val = mt76_get_of_array_s8(np, "paths-ru-bf", &len, ARRAY_SIZE(dest->path.ru_bf[0]) + 1);
- mt76_apply_multi_array_limit(dest->path.ru_bf[0], ARRAY_SIZE(dest->path.ru_bf[0]),
- ARRAY_SIZE(dest->path.ru_bf), val, len,
- target_power_combine, txs_delta);
+ mt76_apply_multi_array_limit(dev, dest->path.ru_bf[0], ARRAY_SIZE(dest->path.ru_bf[0]),
+ ARRAY_SIZE(dest->path.ru_bf), val, len, target_power,
+ txs_delta, &max_power, n_chains, MT76_SKU_BACKOFF);
return max_power;
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index d05e83ea1..32876eab2 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -540,7 +540,6 @@ struct mt76_driver_ops {
u32 survey_flags;
u16 txwi_size;
u16 token_size;
- u8 mcs_rates;
unsigned int link_data_size;
--
2.45.2
^ permalink raw reply related
* [PATCH v3 2/2] dt-bindings: net: wireless: mt76: clarify backoff limit format
From: Ryder Lee @ 2026-02-10 18:08 UTC (permalink / raw)
To: Felix Fietkau, Rob Herring
Cc: devicetree, linux-mediatek, linux-wireless, Ryder Lee, Allen Ye
In-Reply-To: <8fa8ec500b3d4de7b1966c6887f1dfbe5c46a54c.1770746444.git.ryder.lee@mediatek.com>
Clarify the format of path backoff limit properties in mt76 binding.
Add explicit documentation for connac2 (mt7915, mt7981, mt7986) and
connac3 (mt7990, mt7992, mt7996...) devices, including the difference
in beamforming and non-beamforming entries.
Also reformat the description to make is more precise.
Signed-off-by: Allen Ye <allen.ye@mediatek.com>
Co-developed-by: Allen Ye <allen.ye@mediatek.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
---
.../bindings/net/wireless/mediatek,mt76.yaml | 20 +++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
index ae6b97cdc..4156e1c97 100644
--- a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
@@ -252,6 +252,16 @@ properties:
followed by 10 power limit values. The order of the
channel resource unit settings is RU26, RU52, RU106,
RU242/SU20, RU484/SU40, RU996/SU80 and RU2x996/SU160.
+ - For connac2
+ - Beamforming entries for BW20~BW160 and OFDM do not
+ include 1T1ss.
+ - When 1T1ss is not used, it should be filled with 0.
+ - For connac3
+ - Beamforming entries for BW20~BW160 and RU include
+ 1T1ss, but OFDM does not include 1T1ss.
+ - 1T1ss is taken into account, so no need to fill with 0.
+ Non-beamforming and RU entries for both connac2 and
+ connac3 include 1T1ss.
minItems: 1
maxItems: 7
items:
@@ -270,6 +280,16 @@ properties:
followed by 10 power limit values. The order of the
channel resource unit settings is RU26, RU52, RU106,
RU242/SU20, RU484/SU40, RU996/SU80 and RU2x996/SU160.
+ - For connac2
+ - Beamforming entries for BW20~BW160 and OFDM do not
+ include 1T1ss.
+ - When 1T1ss is not used, it should be filled with 0.
+ - For connac3
+ - Beamforming entries for BW20~BW160 and RU include
+ 1T1ss, but OFDM does not include 1T1ss.
+ - 1T1ss is taken into account, so no need to fill with 0.
+ Non-beamforming and RU entries for both connac2 and
+ connac3 include 1T1ss.
minItems: 1
maxItems: 7
items:
--
2.45.2
^ permalink raw reply related
* [PATCH mt76] wifi: mt76: mt7915: sync station power save state
From: David Bauer @ 2026-02-10 20:19 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek
Host receives a power save state change event everytime a station enters
or leaves PS mode. Use this unsolicited event to stop filling up TX
queues in firmware, as the hardware will buffer frames for stations in
power safe indefinitely.
Limit packets to be enqueued for sleeping STAs in order to manage the
packet backlog in the host-system while still being able to indicate
pending traffic to said STAs.
Signed-off-by: David Bauer <mail@david-bauer.net>
---
.../net/wireless/mediatek/mt76/mt7915/main.c | 1 +
.../net/wireless/mediatek/mt76/mt7915/mcu.c | 28 +++++++++++++++++++
.../net/wireless/mediatek/mt76/mt7915/mcu.h | 9 ++++++
3 files changed, 38 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/main.c b/drivers/net/wireless/mediatek/mt76/mt7915/main.c
index 90d5e79fbf74d..71b94db64ef6d 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7915/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7915/main.c
@@ -1783,6 +1783,7 @@ const struct ieee80211_ops mt7915_ops = {
.sw_scan_complete = mt76_sw_scan_complete,
.release_buffered_frames = mt76_release_buffered_frames,
.get_txpower = mt76_get_txpower,
+ .set_tim = mt76_set_tim,
.set_sar_specs = mt7915_set_sar_specs,
.channel_switch_beacon = mt7915_channel_switch_beacon,
.get_stats = mt7915_get_stats,
diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
index 00bff4d3aab80..8b4a5973b240c 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
@@ -402,6 +402,31 @@ mt7915_mcu_rx_bcc_notify(struct mt7915_dev *dev, struct sk_buff *skb)
mt7915_mcu_cca_finish, mphy->hw);
}
+static void mt7915_mcu_rx_ps_sync(struct mt7915_dev *dev, struct sk_buff *skb)
+{
+ struct mt7915_mcu_ps_notify *p;
+ struct ieee80211_sta *sta;
+ struct mt76_wcid *wcid;
+ u16 wcid_idx;
+
+ p = (struct mt7915_mcu_ps_notify *)skb->data;
+ wcid_idx = p->wtbl_lower | (p->wtbl_higher) << 8;
+
+ rcu_read_lock();
+ wcid = mt76_wcid_ptr(dev, wcid_idx);
+ if (!wcid)
+ goto out;
+
+ sta = wcid_to_sta(wcid);
+ if (!sta)
+ goto out;
+
+ ieee80211_sta_ps_transition_ni(sta, !!p->ps_bit);
+
+out:
+ rcu_read_unlock();
+}
+
static void
mt7915_mcu_rx_ext_event(struct mt7915_dev *dev, struct sk_buff *skb)
{
@@ -424,6 +449,9 @@ mt7915_mcu_rx_ext_event(struct mt7915_dev *dev, struct sk_buff *skb)
case MCU_EXT_EVENT_BCC_NOTIFY:
mt7915_mcu_rx_bcc_notify(dev, skb);
break;
+ case MCU_EXT_EVENT_PS_SYNC:
+ mt7915_mcu_rx_ps_sync(dev, skb);
+ break;
default:
break;
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.h b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.h
index 3af11a075a2f4..836fe46393256 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.h
@@ -54,6 +54,15 @@ struct mt7915_mcu_bcc_notify {
u8 rsv;
} __packed;
+struct mt7915_mcu_ps_notify {
+ struct mt76_connac2_mcu_rxd_hdr rxd;
+
+ u8 wtbl_lower;
+ u8 ps_bit;
+ u8 wtbl_higher;
+ u8 rsv;
+} __packed;
+
struct mt7915_mcu_rdd_report {
struct mt76_connac2_mcu_rxd_hdr rxd;
--
2.51.0
^ permalink raw reply related
* Re: [PATCH rtw-next] wifi: rtw88: Ignore TX report sequence number from the 8051 chips
From: Bitterblue Smith @ 2026-02-10 21:33 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless@vger.kernel.org
In-Reply-To: <442b0555b369487b81ba96dcf410cf7d@realtek.com>
On 10/02/2026 08:44, Ping-Ke Shih wrote:
> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>> On 09/02/2026 10:19, Ping-Ke Shih wrote:
>>> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>>>> When connected to a network in the 2.4 GHz band, wpa_supplicant (or
>>>> NetworkManager?) triggers a scan every five minutes. During these scans
>>>> mac80211 transmits many QoS Null frames in quick succession. Because
>>>> these frames are marked with IEEE80211_TX_CTL_REQ_TX_STATUS, rtw88
>>>> asks the firmware to report the TX ACK status for each of these frames.
>>>> Sometimes the firmware can't process the TX status requests quickly
>>>> enough, they add up, it only processes some of them, and then marks
>>>> every subsequent TX status report with the wrong number.
>>>
>>> Does it mean number of reports is correct? But with incorrect sequence number?
>>> Then, you just ignore checking 'sn' but assume 'st' is correct.
>>>
>>
>> The number of reports is correct most of the time. Only when the firmware
>> is overwhelmed (?) it doesn't provide every report, but later it recovers.
>>
>
> I was not aware that this happened while scanning, so we might apply this loose
> checking under scan condition -- test_bit(RTW_FLAG_SCANNING, rtwdev->flags)"?
> If TX report is because of re-key, it can still use original rule.
>
> [...]
>
We can't do that because the sequence number is permanently messed up.
I thought about ignoring IEEE80211_TX_CTL_REQ_TX_STATUS on null frames
sent during scans, but unfortunately the last 2 or 3 QOS Null frames
are sent after RTW_FLAG_SCANNING is unset, and they still trigger the
problem.
While poking around today I noticed that only non-QOS null frames are
treated like management frames. QOS null frames are treated like data
frames. So I tried this change:
diff --git a/drivers/net/wireless/realtek/rtw88/tx.c b/drivers/net/wireless/realtek/rtw88/tx.c
index 783975acdcff..ea83daa9d60d 100644
--- a/drivers/net/wireless/realtek/rtw88/tx.c
+++ b/drivers/net/wireless/realtek/rtw88/tx.c
@@ -424,7 +424,7 @@ void rtw_tx_pkt_info_update(struct rtw_dev *rtwdev,
pkt_info->mac_id = rtwvif->mac_id;
}
- if (ieee80211_is_mgmt(fc) || ieee80211_is_nullfunc(fc))
+ if (ieee80211_is_mgmt(fc) || ieee80211_is_any_nullfunc(fc))
rtw_tx_mgmt_pkt_info_update(rtwdev, pkt_info, sta, skb);
else if (ieee80211_is_data(fc))
rtw_tx_data_pkt_info_update(rtwdev, pkt_info, sta, skb);
With this I can't trigger the problem anymore. The sequence numbers
are normal every time. Well, it's too soon to be sure, so I will keep
testing for a few days.
>>
>>>>
>>>> The symptom is that after a while the warning "failed to get tx report
>>>> from firmware" appears every five minutes.
>>>>
>>>> This problem apparently happens only with the older RTL8723D, RTL8821A,
>>>> RTL8812A, and probably RTL8703B chips. Ignore the TX report sequence
>>>> number reported by these chips and match the reports with the requests
>>>> in the order they come in.
>>>>
>>>> Tested with RTL8821AU and RTL8723DU.
>>>>
>>>> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
>>>> ---
>>>> drivers/net/wireless/realtek/rtw88/tx.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/wireless/realtek/rtw88/tx.c b/drivers/net/wireless/realtek/rtw88/tx.c
>>>> index c04ff31d0f1e..98215ecc884a 100644
>>>> --- a/drivers/net/wireless/realtek/rtw88/tx.c
>>>> +++ b/drivers/net/wireless/realtek/rtw88/tx.c
>>>> @@ -248,7 +248,7 @@ void rtw_tx_report_handle(struct rtw_dev *rtwdev, struct sk_buff *skb, int src)
>>>> spin_lock_irqsave(&tx_report->q_lock, flags);
>>>> skb_queue_walk_safe(&tx_report->queue, cur, tmp) {
>>>> n = (u8 *)IEEE80211_SKB_CB(cur)->status.status_driver_data;
>>>> - if (*n == sn) {
>>>> + if (*n == sn || rtw_chip_wcpu_8051(rtwdev)) {
>>>
>>> Can we only limit to USB devices (or non-PCI devices)?
>>>
>>
>> I don't think so. RTL8821AE also has this problem. I didn't mention it
>> in the commit message because support for RTL8821AE in rtw88 is
>> unofficial. (I modified rtw88_pci to handle the older generation, see
>> the use_new_trx_flow=false code path in rtlwifi.)
>
> How about official RTL8723DE?
>
I don't have RTL8723DE. I can try with RTL8723DS, although it's annoying
to use. (The host is some kind of single board computer. It has only a
serial interface and when I connect that to my laptop it makes the
touchpad slow for some reason.)
>>
>>>> __skb_unlink(cur, &tx_report->queue);
>>>> rtw_tx_report_tx_status(rtwdev, cur, st == 0);
>>>> break;
>>>> --
>>>> 2.52.0
>>>
>
^ permalink raw reply related
* RE: [PATCH rtw-next] wifi: rtw88: Ignore TX report sequence number from the 8051 chips
From: Ping-Ke Shih @ 2026-02-11 2:03 UTC (permalink / raw)
To: Bitterblue Smith, linux-wireless@vger.kernel.org
In-Reply-To: <9110568d-419b-46a7-b0f0-808f958a6efc@gmail.com>
Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> On 10/02/2026 08:44, Ping-Ke Shih wrote:
> > Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> >> On 09/02/2026 10:19, Ping-Ke Shih wrote:
> >>> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> >>>> When connected to a network in the 2.4 GHz band, wpa_supplicant (or
> >>>> NetworkManager?) triggers a scan every five minutes. During these scans
> >>>> mac80211 transmits many QoS Null frames in quick succession. Because
> >>>> these frames are marked with IEEE80211_TX_CTL_REQ_TX_STATUS, rtw88
> >>>> asks the firmware to report the TX ACK status for each of these frames.
> >>>> Sometimes the firmware can't process the TX status requests quickly
> >>>> enough, they add up, it only processes some of them, and then marks
> >>>> every subsequent TX status report with the wrong number.
> >>>
> >>> Does it mean number of reports is correct? But with incorrect sequence number?
> >>> Then, you just ignore checking 'sn' but assume 'st' is correct.
> >>>
> >>
> >> The number of reports is correct most of the time. Only when the firmware
> >> is overwhelmed (?) it doesn't provide every report, but later it recovers.
> >>
> >
> > I was not aware that this happened while scanning, so we might apply this loose
> > checking under scan condition -- test_bit(RTW_FLAG_SCANNING, rtwdev->flags)"?
> > If TX report is because of re-key, it can still use original rule.
> >
> > [...]
> >
>
> We can't do that because the sequence number is permanently messed up.
Indeed...
>
> I thought about ignoring IEEE80211_TX_CTL_REQ_TX_STATUS on null frames
> sent during scans, but unfortunately the last 2 or 3 QOS Null frames
> are sent after RTW_FLAG_SCANNING is unset, and they still trigger the
> problem.
>
> While poking around today I noticed that only non-QOS null frames are
> treated like management frames. QOS null frames are treated like data
> frames. So I tried this change:
>
> diff --git a/drivers/net/wireless/realtek/rtw88/tx.c b/drivers/net/wireless/realtek/rtw88/tx.c
> index 783975acdcff..ea83daa9d60d 100644
> --- a/drivers/net/wireless/realtek/rtw88/tx.c
> +++ b/drivers/net/wireless/realtek/rtw88/tx.c
> @@ -424,7 +424,7 @@ void rtw_tx_pkt_info_update(struct rtw_dev *rtwdev,
> pkt_info->mac_id = rtwvif->mac_id;
> }
>
> - if (ieee80211_is_mgmt(fc) || ieee80211_is_nullfunc(fc))
> + if (ieee80211_is_mgmt(fc) || ieee80211_is_any_nullfunc(fc))
> rtw_tx_mgmt_pkt_info_update(rtwdev, pkt_info, sta, skb);
> else if (ieee80211_is_data(fc))
> rtw_tx_data_pkt_info_update(rtwdev, pkt_info, sta, skb);
>
> With this I can't trigger the problem anymore. The sequence numbers
> are normal every time. Well, it's too soon to be sure, so I will keep
> testing for a few days.
Good finding. Please keep testing it.
FYI. Having the lunar New Year next week, I will not reply your mail soon.
>
> >>
> >>>>
> >>>> The symptom is that after a while the warning "failed to get tx report
> >>>> from firmware" appears every five minutes.
> >>>>
> >>>> This problem apparently happens only with the older RTL8723D, RTL8821A,
> >>>> RTL8812A, and probably RTL8703B chips. Ignore the TX report sequence
> >>>> number reported by these chips and match the reports with the requests
> >>>> in the order they come in.
> >>>>
> >>>> Tested with RTL8821AU and RTL8723DU.
> >>>>
> >>>> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
> >>>> ---
> >>>> drivers/net/wireless/realtek/rtw88/tx.c | 2 +-
> >>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/drivers/net/wireless/realtek/rtw88/tx.c b/drivers/net/wireless/realtek/rtw88/tx.c
> >>>> index c04ff31d0f1e..98215ecc884a 100644
> >>>> --- a/drivers/net/wireless/realtek/rtw88/tx.c
> >>>> +++ b/drivers/net/wireless/realtek/rtw88/tx.c
> >>>> @@ -248,7 +248,7 @@ void rtw_tx_report_handle(struct rtw_dev *rtwdev, struct sk_buff *skb, int src)
> >>>> spin_lock_irqsave(&tx_report->q_lock, flags);
> >>>> skb_queue_walk_safe(&tx_report->queue, cur, tmp) {
> >>>> n = (u8 *)IEEE80211_SKB_CB(cur)->status.status_driver_data;
> >>>> - if (*n == sn) {
> >>>> + if (*n == sn || rtw_chip_wcpu_8051(rtwdev)) {
> >>>
> >>> Can we only limit to USB devices (or non-PCI devices)?
> >>>
> >>
> >> I don't think so. RTL8821AE also has this problem. I didn't mention it
> >> in the commit message because support for RTL8821AE in rtw88 is
> >> unofficial. (I modified rtw88_pci to handle the older generation, see
> >> the use_new_trx_flow=false code path in rtlwifi.)
> >
> > How about official RTL8723DE?
> >
>
> I don't have RTL8723DE. I can try with RTL8723DS, although it's annoying
> to use. (The host is some kind of single board computer. It has only a
> serial interface and when I connect that to my laptop it makes the
> touchpad slow for some reason.)
I found a RTL8723DE and tested scan during connection over 10 times
(with local modification to print TX-sn/RX-sn).
I'd say RTL8723DE doesn't have this problem.
>
> >>
> >>>> __skb_unlink(cur, &tx_report->queue);
> >>>> rtw_tx_report_tx_status(rtwdev, cur, st == 0);
> >>>> break;
> >>>> --
> >>>> 2.52.0
> >>>
> >
^ permalink raw reply
* Re: New warning `ath10k_pci 0000:3a:00.0: not found station for peer stats`
From: Baochen Qiang @ 2026-02-11 5:43 UTC (permalink / raw)
To: Paul Menzel, Jeff Johnson; +Cc: linux-wireless, ath10k
In-Reply-To: <2c722676-98c6-4162-96cb-9bea06672153@molgen.mpg.de>
On 2/10/2026 6:31 AM, Paul Menzel wrote:
> Dear Baochen,
>
>
> Am 09.02.26 um 03:44 schrieb Baochen Qiang:
>
>> On 2/7/2026 1:55 PM, Paul Menzel wrote:
>
>>> Am 19.01.26 um 17:41 schrieb Paul Menzel:
>>>
>>>> Since January 10th, I have started seeing the warning below in
>>>> my Linux logs, that reach back to September 24th, 2025:
>>>>
>>>> [ 37.108902] ath10k_pci 0000:3a:00.0: not found station for peer stats
>>>> [ 37.108906] ath10k_pci 0000:3a:00.0: failed to parse stats info tlv: -22
>>>>
>>>> It started appearing with 6.19.0-rc4-00282-gb6151c4e60e5, the
>>>> version running before is 6.19.0-rc4-00003-g3609fa95fb0f, but I
>>>> do not see anything related in the commit list:>>>
>>>> git log --oneline 3609fa95fb0f...b6151c4e60e5
>>>>
>>>> The warning log from `drivers/net/wireless/ath/ath10k/wmi-tlv.c` has also been there
>>>> since 2021.
>>>>
>>>> Do you have an idea? Please find the output of `dmesg` attached.
>>>
>>> Looking through the commit list from above again, commit
>>> a203dbeeca15 (wifi: mac80211: collect station statistics earlier
>>> when disconnect) probably introduced the new behavior.
>>
>> is this error seen when disconnecting from AP?
>
> I attached the logs in my first message. But yes, it looks like this:
sorry, didn't notice there was an attachment.
>
> Feb 07 06:32:52 abreu kernel: wlp58s0: deauthenticating from 74:1a:e0:e7:b4:c8 by
> local choice (Reason: 3=DEAUTH_LEAVING)
> Feb 07 06:32:52 abreu kernel: ath10k_pci 0000:3a:00.0: not found station for peer stats
> Feb 07 06:32:52 abreu kernel: ath10k_pci 0000:3a:00.0: failed to parse stats info tlv:
> -22
> Feb 07 06:32:52 abreu wpa_supplicant[846]: wlp58s0: CTRL-EVENT-DISCONNECTED
> bssid=74:1a:e0:e7:b4:c8 reason=3 locally_generated=1
> Feb 07 06:32:52 abreu wpa_supplicant[846]: BSSID 74:1a:e0:e7:b4:c8 ignore list count
> incremented to 2, ignoring for 10 seconds
>
>> did you try with that commit reverted?
> Yes, I tried it now with Linux 6.19 and reverting the commit. The warnings are gone now.
>
> Are you able to reproduce the issue? What devices are you testing with?
I managed to reproduce this issue locally. Will submit a patch fixing it.
>
>
> Kind regards,
>
> Paul
^ permalink raw reply
* Re: [PATCH v3 2/2] dt-bindings: net: wireless: mt76: clarify backoff limit format
From: Krzysztof Kozlowski @ 2026-02-11 6:31 UTC (permalink / raw)
To: Ryder Lee
Cc: Felix Fietkau, Rob Herring, devicetree, linux-mediatek,
linux-wireless, Allen Ye
In-Reply-To: <69521aebefef405bad5117d4d5d5fef4a5dfb7e8.1770746444.git.ryder.lee@mediatek.com>
On Tue, Feb 10, 2026 at 10:08:56AM -0800, Ryder Lee wrote:
> Clarify the format of path backoff limit properties in mt76 binding.
> Add explicit documentation for connac2 (mt7915, mt7981, mt7986) and
> connac3 (mt7990, mt7992, mt7996...) devices, including the difference
> in beamforming and non-beamforming entries.
I do not see any reformatting happening.
>
> Also reformat the description to make is more precise.
>
> Signed-off-by: Allen Ye <allen.ye@mediatek.com>
> Co-developed-by: Allen Ye <allen.ye@mediatek.com>
Incorrect SoB chain. Read submitting patches.
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
> .../bindings/net/wireless/mediatek,mt76.yaml | 20 +++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
> index ae6b97cdc..4156e1c97 100644
> --- a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
> @@ -252,6 +252,16 @@ properties:
> followed by 10 power limit values. The order of the
> channel resource unit settings is RU26, RU52, RU106,
> RU242/SU20, RU484/SU40, RU996/SU80 and RU2x996/SU160.
> + - For connac2
There is no such term as connac2 in this binding at all.
What is the point of adding new terms?
> + - Beamforming entries for BW20~BW160 and OFDM do not
> + include 1T1ss.
> + - When 1T1ss is not used, it should be filled with 0.
> + - For connac3
> + - Beamforming entries for BW20~BW160 and RU include
> + 1T1ss, but OFDM does not include 1T1ss.
> + - 1T1ss is taken into account, so no need to fill with 0.
> + Non-beamforming and RU entries for both connac2 and
> + connac3 include 1T1ss.
Why this cannot be a schema?
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH 2/2] wifi: mac80211: improve station iteration ergonomics
From: Ping-Ke Shih @ 2026-02-11 6:49 UTC (permalink / raw)
To: Johannes Berg, linux-wireless@vger.kernel.org; +Cc: Johannes Berg
In-Reply-To: <20260108143431.d2b641f6f6af.I4470024f7404446052564b15bcf8b3f1ada33655@changeid>
Hi Johannes,
> +/**
> + * for_each_station - iterate stations under wiphy mutex
> + * @sta: the iterator variable
> + * @hw: the HW to iterate for
> + */
> +#define for_each_station(sta, hw) \
> + for (sta = __ieee80211_iterate_stations(hw, NULL); \
> + sta; \
> + sta = __ieee80211_iterate_stations(hw, sta))
> +
I'm going to use for_each_station() in rtw89 driver, and the code in driver side
looks very simple! Thanks for this new API.
However, without other callers rather than ieee80211_iterate_xxx(), I'd like
to know if it is expected that driver uses for_each_station()? Since help
text is added, I think it can be, right?
Another question is that adding ieee80211_ prefix would be consistent with
other API? If you agree, I can make patches.
As well as for_each_interface().
Ping-Ke
^ permalink raw reply
* Re: [PATCH 2/2] wifi: mac80211: improve station iteration ergonomics
From: Johannes Berg @ 2026-02-11 7:54 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless@vger.kernel.org
In-Reply-To: <fb7526f0a2e64e229446e3faa03edc3a@realtek.com>
On Wed, 2026-02-11 at 06:49 +0000, Ping-Ke Shih wrote:
> Hi Johannes,
>
> > +/**
> > + * for_each_station - iterate stations under wiphy mutex
> > + * @sta: the iterator variable
> > + * @hw: the HW to iterate for
> > + */
> > +#define for_each_station(sta, hw) \
> > + for (sta = __ieee80211_iterate_stations(hw, NULL); \
> > + sta; \
> > + sta = __ieee80211_iterate_stations(hw, sta))
> > +
>
> I'm going to use for_each_station() in rtw89 driver, and the code in driver side
> looks very simple! Thanks for this new API.
>
> However, without other callers rather than ieee80211_iterate_xxx(), I'd like
> to know if it is expected that driver uses for_each_station()? Since help
> text is added, I think it can be, right?
Yeah definitely, I wouldn't have added it to mac80211.h otherwise. I'm
already using it in our driver, those patches just haven't gone upstream
yet.
> Another question is that adding ieee80211_ prefix would be consistent with
> other API? If you agree, I can make patches.
>
> As well as for_each_interface().
Yeah that's a good question I guess. There's some precedent either way,
e.g. for_each_netdev() and netdev_for_each_uc_addr(), though it's a bit
more along the lines of "object_for_each_member()" rather than
"subsystem_for_each_something()" - which would be more like
ieee80211_hw_for_each_station() here? The notable exception to this
being damon_*. And objects are also missing, we have for_each_netdev(),
not netns_for_each_netdev().
Oh and the order of arguments is also not consistent anywhere it seems.
list_for_each_entry() is "iter, list, member", whereas for_each_netdev()
is "net, iter".
I suppose I have no strong opinion about it, there doesn't really seem
to be _any_ consistency around it. Maybe we should be consistent overall
with them though in mac80211.h, and if renaming not just do the new
ones? And maybe that's not worth the churn?
Yeah I don't know what to say I guess, I suppose that means if you feel
strongly one or the other is better I'm happy to adjust :)
johannes
^ permalink raw reply
* RE: [PATCH 2/2] wifi: mac80211: improve station iteration ergonomics
From: Ping-Ke Shih @ 2026-02-11 8:08 UTC (permalink / raw)
To: Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <ba29951035ed17f666687db24debbb9c2dd6f30f.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> wrote:
> On Wed, 2026-02-11 at 06:49 +0000, Ping-Ke Shih wrote:
> > Hi Johannes,
> >
> > > +/**
> > > + * for_each_station - iterate stations under wiphy mutex
> > > + * @sta: the iterator variable
> > > + * @hw: the HW to iterate for
> > > + */
> > > +#define for_each_station(sta, hw) \
> > > + for (sta = __ieee80211_iterate_stations(hw, NULL); \
> > > + sta; \
> > > + sta = __ieee80211_iterate_stations(hw, sta))
> > > +
> >
> > I'm going to use for_each_station() in rtw89 driver, and the code in driver side
> > looks very simple! Thanks for this new API.
> >
> > However, without other callers rather than ieee80211_iterate_xxx(), I'd like
> > to know if it is expected that driver uses for_each_station()? Since help
> > text is added, I think it can be, right?
>
> Yeah definitely, I wouldn't have added it to mac80211.h otherwise. I'm
> already using it in our driver, those patches just haven't gone upstream
> yet.
>
> > Another question is that adding ieee80211_ prefix would be consistent with
> > other API? If you agree, I can make patches.
> >
> > As well as for_each_interface().
>
> Yeah that's a good question I guess. There's some precedent either way,
> e.g. for_each_netdev() and netdev_for_each_uc_addr(), though it's a bit
> more along the lines of "object_for_each_member()" rather than
> "subsystem_for_each_something()" - which would be more like
> ieee80211_hw_for_each_station() here? The notable exception to this
> being damon_*. And objects are also missing, we have for_each_netdev(),
> not netns_for_each_netdev().
>
> Oh and the order of arguments is also not consistent anywhere it seems.
> list_for_each_entry() is "iter, list, member", whereas for_each_netdev()
> is "net, iter".
>
> I suppose I have no strong opinion about it, there doesn't really seem
> to be _any_ consistency around it. Maybe we should be consistent overall
> with them though in mac80211.h, and if renaming not just do the new
> ones? And maybe that's not worth the churn?
>
> Yeah I don't know what to say I guess, I suppose that means if you feel
> strongly one or the other is better I'm happy to adjust :)
I don't have strong opinion to either one. Let's keep as it was. :)
Ping-Ke
^ permalink raw reply
* Re: [PATCH v3 2/2] dt-bindings: net: wireless: mt76: clarify backoff limit format
From: Ryder Lee @ 2026-02-11 8:13 UTC (permalink / raw)
To: krzk@kernel.org
Cc: robh@kernel.org, nbd@nbd.name, linux-mediatek@lists.infradead.org,
devicetree@vger.kernel.org, Allen Ye (葉芷勳),
linux-wireless@vger.kernel.org
In-Reply-To: <20260211-miniature-chital-of-plenty-1a71df@quoll>
On Wed, 2026-02-11 at 07:31 +0100, Krzysztof Kozlowski wrote:
> On Tue, Feb 10, 2026 at 10:08:56AM -0800, Ryder Lee wrote:
> > Clarify the format of path backoff limit properties in mt76
> > binding.
> > Add explicit documentation for connac2 (mt7915, mt7981, mt7986) and
> > connac3 (mt7990, mt7992, mt7996...) devices, including the
> > difference
> > in beamforming and non-beamforming entries.
>
> I do not see any reformatting happening.
>
Maybe I should use "rephrase" here.
> >
> > Also reformat the description to make is more precise.
> >
> > Signed-off-by: Allen Ye <allen.ye@mediatek.com>
> > Co-developed-by: Allen Ye <allen.ye@mediatek.com>
>
> Incorrect SoB chain. Read submitting patches.
>
Will fix.
> > Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> > ---
> > .../bindings/net/wireless/mediatek,mt76.yaml | 20
> > +++++++++++++++++++
> > 1 file changed, 20 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
> > b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
> > index ae6b97cdc..4156e1c97 100644
> > ---
> > a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
> > +++
> > b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
> > @@ -252,6 +252,16 @@ properties:
> > followed by 10 power limit values. The order
> > of the
> > channel resource unit settings is RU26,
> > RU52, RU106,
> > RU242/SU20, RU484/SU40, RU996/SU80 and
> > RU2x996/SU160.
> > + - For connac2
>
> There is no such term as connac2 in this binding at all.
>
> What is the point of adding new terms?
I didn’t think it was needed at first, but other reviewers suggested
adding it.
The commit message talks about mt7915, mt7990, mt7992, and mt7996,
which are all PCIe WiFi devices, so their names aren’t included in the
platform binding. Only WiFi integrated SoCs like mt7981 and mt7986 are
listed.
These descriptions are meant to explain how a platform configures TX
power for the connected WiFi devices, whether it’s a PCIe NIC (like
Connac3 devices I listed) or an integrated SoC itself (like
mt7981/mt7986).
What do you suggest? I’m actually okay with keeping everything as is.
You can also look at the v2 discussion.
[v2] wifi: mt76: fix backoff fields and max_power calculation
https://patchwork.kernel.org/project/linux-mediatek/patch/54627282cfb8e5a89fe753da66552c0a084f6387.1769557863.git.ryder.lee@mediatek.com/
>
> > + - Beamforming entries for BW20~BW160 and
> > OFDM do not
> > + include 1T1ss.
> > + - When 1T1ss is not used, it should be
> > filled with 0.
> > + - For connac3
> > + - Beamforming entries for BW20~BW160 and
> > RU include
> > + 1T1ss, but OFDM does not include 1T1ss.
> > + - 1T1ss is taken into account, so no need
> > to fill with 0.
> > + Non-beamforming and RU entries for both
> > connac2 and
> > + connac3 include 1T1ss.
>
> Why this cannot be a schema?
>
>
Well, actually, it's already a schema. This is just an expanded
explanation of the differences in handling between different
devices/generations.
But actually, the differences between these generations can be fully
handled in the driver (that's exactly what my [1/2] is doing), so
whether to update the documentation is really just a matter of personal
preference.
I'm also not sure how to describe a Connac3 PCIe device (non-SoC type)
that isn't mentioned in the documentation.
If we need to drop the DTS change, I’m okay with that and will leave it
up to the reviewers. Or, we can just apply [1/2] on its own, which
won’t affect the documentation’s description or usage.
Ryder
^ permalink raw reply
* Re: [PATCH v3 2/2] dt-bindings: net: wireless: mt76: clarify backoff limit format
From: Krzysztof Kozlowski @ 2026-02-11 8:16 UTC (permalink / raw)
To: Ryder Lee
Cc: robh@kernel.org, nbd@nbd.name, linux-mediatek@lists.infradead.org,
devicetree@vger.kernel.org, Allen Ye (葉芷勳),
linux-wireless@vger.kernel.org
In-Reply-To: <bd4da0a8522db2991ec0844233efe068323c2578.camel@mediatek.com>
On 11/02/2026 09:13, Ryder Lee wrote:
> On Wed, 2026-02-11 at 07:31 +0100, Krzysztof Kozlowski wrote:
>> On Tue, Feb 10, 2026 at 10:08:56AM -0800, Ryder Lee wrote:
>>> Clarify the format of path backoff limit properties in mt76
>>> binding.
>>> Add explicit documentation for connac2 (mt7915, mt7981, mt7986) and
>>> connac3 (mt7990, mt7992, mt7996...) devices, including the
>>> difference
>>> in beamforming and non-beamforming entries.
>>
>> I do not see any reformatting happening.
>>
> Maybe I should use "rephrase" here.
>
>>>
>>> Also reformat the description to make is more precise.
>>>
>>> Signed-off-by: Allen Ye <allen.ye@mediatek.com>
>>> Co-developed-by: Allen Ye <allen.ye@mediatek.com>
>>
>> Incorrect SoB chain. Read submitting patches.
>>
>
> Will fix.
>
>>> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
>>> ---
>>> .../bindings/net/wireless/mediatek,mt76.yaml | 20
>>> +++++++++++++++++++
>>> 1 file changed, 20 insertions(+)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
>>> b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
>>> index ae6b97cdc..4156e1c97 100644
>>> ---
>>> a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
>>> +++
>>> b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
>>> @@ -252,6 +252,16 @@ properties:
>>> followed by 10 power limit values. The order
>>> of the
>>> channel resource unit settings is RU26,
>>> RU52, RU106,
>>> RU242/SU20, RU484/SU40, RU996/SU80 and
>>> RU2x996/SU160.
>>> + - For connac2
>>
>> There is no such term as connac2 in this binding at all.
>>
>> What is the point of adding new terms?
>
> I didn’t think it was needed at first, but other reviewers suggested
> adding it.
Adding secret terms in the binding is not helping.
>
> The commit message talks about mt7915, mt7990, mt7992, and mt7996,
> which are all PCIe WiFi devices, so their names aren’t included in the
> platform binding. Only WiFi integrated SoCs like mt7981 and mt7986 are
> listed.
>
> These descriptions are meant to explain how a platform configures TX
> power for the connected WiFi devices, whether it’s a PCIe NIC (like
> Connac3 devices I listed) or an integrated SoC itself (like
> mt7981/mt7986).
>
> What do you suggest? I’m actually okay with keeping everything as is.
I have no clue what you want to achieve.
>
> You can also look at the v2 discussion.
> [v2] wifi: mt76: fix backoff fields and max_power calculation
> https://patchwork.kernel.org/project/linux-mediatek/patch/54627282cfb8e5a89fe753da66552c0a084f6387.1769557863.git.ryder.lee@mediatek.com/
That's driver code.
>
>>
>>> + - Beamforming entries for BW20~BW160 and
>>> OFDM do not
>>> + include 1T1ss.
>>> + - When 1T1ss is not used, it should be
>>> filled with 0.
>>> + - For connac3
>>> + - Beamforming entries for BW20~BW160 and
>>> RU include
>>> + 1T1ss, but OFDM does not include 1T1ss.
>>> + - 1T1ss is taken into account, so no need
>>> to fill with 0.
>>> + Non-beamforming and RU entries for both
>>> connac2 and
>>> + connac3 include 1T1ss.
>>
>> Why this cannot be a schema?
>>
>>
> Well, actually, it's already a schema. This is just an expanded
Where exactly?
But if it is, then this patch is redundant. Don't repeat constraints in
free form text.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/2] dt-bindings: net: wireless: mt76: clarify backoff limit format
From: Ryder Lee @ 2026-02-11 8:33 UTC (permalink / raw)
To: krzk@kernel.org
Cc: robh@kernel.org, nbd@nbd.name, linux-mediatek@lists.infradead.org,
devicetree@vger.kernel.org, Allen Ye (葉芷勳),
linux-wireless@vger.kernel.org
In-Reply-To: <b00c8c18-930b-4cb9-975d-b15118bfc854@kernel.org>
On Wed, 2026-02-11 at 09:16 +0100, Krzysztof Kozlowski wrote:
> On 11/02/2026 09:13, Ryder Lee wrote:
> > On Wed, 2026-02-11 at 07:31 +0100, Krzysztof Kozlowski wrote:
> > > On Tue, Feb 10, 2026 at 10:08:56AM -0800, Ryder Lee wrote:
> > > > Clarify the format of path backoff limit properties in mt76
> > > > binding.
> > > > Add explicit documentation for connac2 (mt7915, mt7981, mt7986)
> > > > and
> > > > connac3 (mt7990, mt7992, mt7996...) devices, including the
> > > > difference
> > > > in beamforming and non-beamforming entries.
> > >
> > > I do not see any reformatting happening.
> > >
> > Maybe I should use "rephrase" here.
> >
> > > >
> > > > Also reformat the description to make is more precise.
> > > >
> > > > Signed-off-by: Allen Ye <allen.ye@mediatek.com>
> > > > Co-developed-by: Allen Ye <allen.ye@mediatek.com>
> > >
> > > Incorrect SoB chain. Read submitting patches.
> > >
> >
> > Will fix.
> >
> > > > Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> > > > ---
> > > > .../bindings/net/wireless/mediatek,mt76.yaml | 20
> > > > +++++++++++++++++++
> > > > 1 file changed, 20 insertions(+)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.
> > > > yaml
> > > > b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.
> > > > yaml
> > > > index ae6b97cdc..4156e1c97 100644
> > > > ---
> > > > a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.
> > > > yaml
> > > > +++
> > > > b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.
> > > > yaml
> > > > @@ -252,6 +252,16 @@ properties:
> > > > followed by 10 power limit values. The
> > > > order
> > > > of the
> > > > channel resource unit settings is RU26,
> > > > RU52, RU106,
> > > > RU242/SU20, RU484/SU40, RU996/SU80 and
> > > > RU2x996/SU160.
> > > > + - For connac2
> > >
> > > There is no such term as connac2 in this binding at all.
> > >
> > > What is the point of adding new terms?
> >
> > I didn’t think it was needed at first, but other reviewers
> > suggested
> > adding it.
>
>
> Adding secret terms in the binding is not helping.
>
> >
> > The commit message talks about mt7915, mt7990, mt7992, and mt7996,
> > which are all PCIe WiFi devices, so their names aren’t included in
> > the
> > platform binding. Only WiFi integrated SoCs like mt7981 and mt7986
> > are
> > listed.
> >
> > These descriptions are meant to explain how a platform configures
> > TX
> > power for the connected WiFi devices, whether it’s a PCIe NIC (like
> > Connac3 devices I listed) or an integrated SoC itself (like
> > mt7981/mt7986).
> >
> > What do you suggest? I’m actually okay with keeping everything as
> > is.
>
> I have no clue what you want to achieve.
> >
> > You can also look at the v2 discussion.
> > [v2] wifi: mt76: fix backoff fields and max_power calculation
> > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/54627282cfb8e5a89fe753da66552c0a084f6387.1769557863.git.ryder.lee@mediatek.com/__;!!CTRNKA9wMg0ARbw!kDXm7YfZY9fDiYPEWx7FWevmY3AqYGd2m9MlwoMZLHZuq8JBgfm2n02oFJ0ag692SgETTmtSSW1F-Q$
> >
>
> That's driver code.
>
The driver code used to parse the DTS. You can look at the final
discussion—that’s why we need to change this DTS (if you’re
interested). This whole section is a discussion about the differences
in how the driver parses the DTS. But this part is already getting into
WiFi-specific details
"Each field corresponds to: 1T1ss, 2T1ss, 3T1ss, 4T1ss, 2T2ss, 3T2ss,
4T2ss, 3T3ss, 4T3ss, and 4T4ss, for a total of 10 values.
For beamform case, mt76 does not need to fill in the value for 1T1ss,
so the length is 9.
For non-beamform case, mt76 needs to fill in the value for 1T1ss, so
the length is 10.
The DTS still needs to provide 1 + 10 because mt76 does not
specifically check for this when parsing DTS.
So a connac2 DTS would be filled like this:
paths-ru-bf =
<1 20 22 38 36 24 30 23 21 28 29>,
<1 20 39 31 25 26 25 28 30 39 39>,
<1 37 34 26 26 25 21 34 23 34 24>,
<1 0 20 23 31 23 30 39 28 29 36>,
<1 0 27 34 33 34 29 38 33 33 22>,
<1 0 30 23 39 28 21 25 29 28 21>,
<1 0 34 20 38 32 35 33 37 26 36>;
When 1T1ss is not used, it should be filled with 0. For connac3, since
1T1ss is taken into account, we don’t need to fill it with 0.
The unused 1T1ss still needs to be written in the DTS. This is to make
parsing easier.
So the number indicated in the current document is correct; it’s just
that the description isn’t precise enough."
> >
> > >
> > > > + - Beamforming entries for BW20~BW160
> > > > and
> > > > OFDM do not
> > > > + include 1T1ss.
> > > > + - When 1T1ss is not used, it should be
> > > > filled with 0.
> > > > + - For connac3
> > > > + - Beamforming entries for BW20~BW160
> > > > and
> > > > RU include
> > > > + 1T1ss, but OFDM does not include
> > > > 1T1ss.
> > > > + - 1T1ss is taken into account, so no
> > > > need
> > > > to fill with 0.
> > > > + Non-beamforming and RU entries for both
> > > > connac2 and
> > > > + connac3 include 1T1ss.
> > >
> > > Why this cannot be a schema?
> > >
> > >
> > Well, actually, it's already a schema. This is just an expanded
>
> Where exactly?
>
How 1T1ss is used across different generations is what my example above
was talking about.
> But if it is, then this patch is redundant. Don't repeat constraints
> in
> free form text.
>
Alright then, let’s drop this change. Felix, please ignore this one.
Ryder
^ permalink raw reply
* [PATCH v2] wifi: cfg80211: cancel rfkill_block work in wiphy_unregister()
From: Daniil Dulov @ 2026-02-11 8:20 UTC (permalink / raw)
To: Johannes Berg
Cc: Daniil Dulov, linux-wireless, linux-kernel, lvc-project, stable
There is a use-after-free error in cfg80211_shutdown_all_interfaces found
by syzkaller:
BUG: KASAN: use-after-free in cfg80211_shutdown_all_interfaces+0x213/0x220
Read of size 8 at addr ffff888112a78d98 by task kworker/0:5/5326
CPU: 0 UID: 0 PID: 5326 Comm: kworker/0:5 Not tainted 6.19.0-rc2 #2 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: events cfg80211_rfkill_block_work
Call Trace:
<TASK>
dump_stack_lvl+0x116/0x1f0
print_report+0xcd/0x630
kasan_report+0xe0/0x110
cfg80211_shutdown_all_interfaces+0x213/0x220
cfg80211_rfkill_block_work+0x1e/0x30
process_one_work+0x9cf/0x1b70
worker_thread+0x6c8/0xf10
kthread+0x3c5/0x780
ret_from_fork+0x56d/0x700
ret_from_fork_asm+0x1a/0x30
</TASK>
The problem arises due to the rfkill_block work is not cancelled when wiphy
is being unregistered. In order to fix the issue cancel the corresponding
work in wiphy_unregister().
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Fixes: 1f87f7d3a3b4 ("cfg80211: add rfkill support")
Cc: stable@vger.kernel.org
Signed-off-by: Daniil Dulov <d.dulov@aladdin.ru>
---
v2: move cancel_work_sync() from cfg80211_dev_free() to wiphy_unregister()
as suggested by Johannes Berg <johannes@sipsolutions.net>
net/wireless/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 9a420d627d3c..8628e0eefadc 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -1214,6 +1214,7 @@ void wiphy_unregister(struct wiphy *wiphy)
/* this has nothing to do now but make sure it's gone */
cancel_work_sync(&rdev->wiphy_work);
+ cancel_work_sync(&rdev->rfkill_block);
cancel_work_sync(&rdev->conn_work);
flush_work(&rdev->event_work);
cancel_delayed_work_sync(&rdev->dfs_update_channels_wk);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 2/2] dt-bindings: net: wireless: mt76: clarify backoff limit format
From: Krzysztof Kozlowski @ 2026-02-11 8:41 UTC (permalink / raw)
To: Ryder Lee
Cc: robh@kernel.org, nbd@nbd.name, linux-mediatek@lists.infradead.org,
devicetree@vger.kernel.org, Allen Ye (葉芷勳),
linux-wireless@vger.kernel.org
In-Reply-To: <0dceffe2e1344830c12bc1f6516d13c7bb488b99.camel@mediatek.com>
On 11/02/2026 09:33, Ryder Lee wrote:
>>>> Why this cannot be a schema?
>>>>
>>>>
>>> Well, actually, it's already a schema. This is just an expanded
>>
>> Where exactly?
>>
>
> How 1T1ss is used across different generations is what my example above
> was talking about.
Where exactly it is already a schema? Please point me line encoding this.
>
>> But if it is, then this patch is redundant. Don't repeat constraints
>> in
>> free form text.
>>
>
> Alright then, let’s drop this change. Felix, please ignore this one.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/2] dt-bindings: net: wireless: mt76: clarify backoff limit format
From: Ryder Lee @ 2026-02-11 8:59 UTC (permalink / raw)
To: krzk@kernel.org
Cc: robh@kernel.org, nbd@nbd.name, linux-mediatek@lists.infradead.org,
devicetree@vger.kernel.org, Allen Ye (葉芷勳),
linux-wireless@vger.kernel.org
In-Reply-To: <23561f00-9f3f-4d4d-81ae-aab9958bd797@kernel.org>
On Wed, 2026-02-11 at 09:41 +0100, Krzysztof Kozlowski wrote:
> On 11/02/2026 09:33, Ryder Lee wrote:
> > > > > Why this cannot be a schema?
> > > > >
> > > > >
> > > > Well, actually, it's already a schema. This is just an expanded
> > >
> > > Where exactly?
> > >
> >
> > How 1T1ss is used across different generations is what my example
> > above
> > was talking about.
>
> Where exactly it is already a schema? Please point me line encoding
> this.
>
>
line 243 paths-ru
line 261 paths-ru-bf
1T1ss refers to the second row in the example below
Previously, we were mainly discussing how the driver should handle
parsing 0 versus non-zero cases, but this can be fully managed by the
driver itself. My [1/2] patch already explains this clearly.
paths-ru-bf =
<1 20 22 38 36 24 30 23 21 28 29>,
<1 20 39 31 25 26 25 28 30 39 39>,
<1 37 34 26 26 25 21 34 23 34 24>,
<1 0 20 23 31 23 30 39 28 29 36>,
<1 0 27 34 33 34 29 38 33 33 22>,
<1 0 30 23 39 28 21 25 29 28 21>,
<1 0 34 20 38 32 35 33 37 26 36>;
Whether the DTS needs to interpret it is really up to personal
preference. Personally, I don’t think it’s needed but I respect
everyone's opinion.
Our newer IC generations are only going to get more complex. If we
hardcode too many definitions now, you’ll end up having to change them
repeatedly. It’s better to let the driver handle this logic.
Ryder
^ permalink raw reply
* Re: [PATCH v3 2/2] dt-bindings: net: wireless: mt76: clarify backoff limit format
From: Chen-Yu Tsai @ 2026-02-11 9:01 UTC (permalink / raw)
To: Ryder Lee
Cc: Krzysztof Kozlowski, robh@kernel.org, nbd@nbd.name,
linux-mediatek@lists.infradead.org, devicetree@vger.kernel.org,
Allen Ye (葉芷勳),
linux-wireless@vger.kernel.org
In-Reply-To: <23561f00-9f3f-4d4d-81ae-aab9958bd797@kernel.org>
On Wed, Feb 11, 2026 at 4:41 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 11/02/2026 09:33, Ryder Lee wrote:
> >>>> Why this cannot be a schema?
> >>>>
> >>>>
> >>> Well, actually, it's already a schema. This is just an expanded
> >>
> >> Where exactly?
> >>
> >
> > How 1T1ss is used across different generations is what my example above
> > was talking about.
>
> Where exactly it is already a schema? Please point me line encoding this.
I think what Krzysztof is asking is why can't you have different compatible
strings for each generation (connac, connac2, connac3), and then have
conditionals in this document to describe in proper DT schema, not text,
the length requirements of each property for each generation.
ChenYu
> >
> >> But if it is, then this patch is redundant. Don't repeat constraints
> >> in
> >> free form text.
> >>
> >
> > Alright then, let’s drop this change. Felix, please ignore this one.
>
>
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox