* [PATCH v4 06/21] wifi: mt76: mt7925: add error handling for AMPDU MCU commands
From: Zac @ 2026-01-16 1:05 UTC (permalink / raw)
To: sean.wang
Cc: deren.wu, kvalo, linux-kernel, linux-mediatek, linux-wireless,
lorenzo, nbd, linux, ryder.lee, sean.wang, Zac Bowling,
Zac Bowling
In-Reply-To: <20260116010519.37001-1-zac@zacbowling.com>
From: Zac Bowling <zbowling@gmail.com>
Check return values of mt7925_mcu_uni_rx_ba() and mt7925_mcu_uni_tx_ba()
in mt7925_ampdu_action() and propagate errors to the caller.
Previously, failures in these MCU commands were silently ignored, which
could leave block aggregation in an inconsistent state between the driver
and firmware.
For IEEE80211_AMPDU_TX_STOP_CONT, only call the completion callback
ieee80211_stop_tx_ba_cb_irqsafe() if the MCU command succeeded, to avoid
signaling completion when the firmware operation failed.
Found through code review - pattern of ignored return values throughout
AMPDU handling.
Reported-by: Zac Bowling <zac@zacbowling.com>
Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
Signed-off-by: Zac Bowling <zac@zacbowling.com>
---
drivers/net/wireless/mediatek/mt76/mt7925/main.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/main.c b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
index 7d3322461b..d966e5ab50 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
@@ -1271,22 +1271,22 @@ mt7925_ampdu_action(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
case IEEE80211_AMPDU_RX_START:
mt76_rx_aggr_start(&dev->mt76, &msta->deflink.wcid, tid, ssn,
params->buf_size);
- mt7925_mcu_uni_rx_ba(dev, params, true);
+ ret = mt7925_mcu_uni_rx_ba(dev, params, true);
break;
case IEEE80211_AMPDU_RX_STOP:
mt76_rx_aggr_stop(&dev->mt76, &msta->deflink.wcid, tid);
- mt7925_mcu_uni_rx_ba(dev, params, false);
+ ret = mt7925_mcu_uni_rx_ba(dev, params, false);
break;
case IEEE80211_AMPDU_TX_OPERATIONAL:
mtxq->aggr = true;
mtxq->send_bar = false;
- mt7925_mcu_uni_tx_ba(dev, params, true);
+ ret = mt7925_mcu_uni_tx_ba(dev, params, true);
break;
case IEEE80211_AMPDU_TX_STOP_FLUSH:
case IEEE80211_AMPDU_TX_STOP_FLUSH_CONT:
mtxq->aggr = false;
clear_bit(tid, &msta->deflink.wcid.ampdu_state);
- mt7925_mcu_uni_tx_ba(dev, params, false);
+ ret = mt7925_mcu_uni_tx_ba(dev, params, false);
break;
case IEEE80211_AMPDU_TX_START:
set_bit(tid, &msta->deflink.wcid.ampdu_state);
@@ -1295,8 +1295,9 @@ mt7925_ampdu_action(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
case IEEE80211_AMPDU_TX_STOP_CONT:
mtxq->aggr = false;
clear_bit(tid, &msta->deflink.wcid.ampdu_state);
- mt7925_mcu_uni_tx_ba(dev, params, false);
- ieee80211_stop_tx_ba_cb_irqsafe(vif, sta->addr, tid);
+ ret = mt7925_mcu_uni_tx_ba(dev, params, false);
+ if (!ret)
+ ieee80211_stop_tx_ba_cb_irqsafe(vif, sta->addr, tid);
break;
}
mt792x_mutex_release(dev);
--
2.52.0
^ permalink raw reply related
* [PATCH v4 05/21] wifi: mt76: mt7925: add NULL checks for link_conf and mlink in main.c
From: Zac @ 2026-01-16 1:05 UTC (permalink / raw)
To: sean.wang
Cc: deren.wu, kvalo, linux-kernel, linux-mediatek, linux-wireless,
lorenzo, nbd, linux, ryder.lee, sean.wang, Zac Bowling,
Zac Bowling
In-Reply-To: <20260116010519.37001-1-zac@zacbowling.com>
From: Zac Bowling <zbowling@gmail.com>
Add NULL pointer checks throughout main.c for functions that call
mt792x_vif_to_bss_conf(), mt792x_vif_to_link(), and mt792x_sta_to_link()
without verifying the return value before dereferencing.
Functions fixed:
- mt7925_set_key(): Check link_conf, mconf, and mlink before use
- mt7925_mac_link_sta_add(): Check link_conf before BSS info update
- mt7925_mac_link_sta_assoc(): Check mlink and link_conf before use
- mt7925_mac_link_sta_remove(): Check mlink and link_conf, add goto
label for proper cleanup path
- mt7925_change_vif_links(): Check link_conf before adding BSS
These functions can receive NULL when the link configuration in mac80211
is not yet synchronized with the driver's link tracking during MLO
operations or state transitions.
Without these checks, the driver crashes during station add/remove/
association operations with NULL pointer dereference:
BUG: kernel NULL pointer dereference, address: 0000000000000010
Call Trace:
mt7925_mac_link_sta_add+0x...
...
Found through static analysis and triggered during BSSID roaming on
systems with multiple access points.
Reported-by: Zac Bowling <zac@zacbowling.com>
Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
Signed-off-by: Zac Bowling <zac@zacbowling.com>
---
.../net/wireless/mediatek/mt76/mt7925/main.c | 27 ++++++++++++++++---
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/main.c b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
index 9f17b21aef..7d3322461b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
@@ -604,6 +604,10 @@ static int mt7925_set_link_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
link_sta = sta ? mt792x_sta_to_link_sta(vif, sta, link_id) : NULL;
mconf = mt792x_vif_to_link(mvif, link_id);
mlink = mt792x_sta_to_link(msta, link_id);
+
+ if (!link_conf || !mconf || !mlink)
+ return -EINVAL;
+
wcid = &mlink->wcid;
wcid_keyidx = &wcid->hw_key_idx;
@@ -889,6 +893,8 @@ static int mt7925_mac_link_sta_add(struct mt76_dev *mdev,
MT_WTBL_UPDATE_ADM_COUNT_CLEAR);
link_conf = mt792x_vif_to_bss_conf(vif, link_id);
+ if (!link_conf)
+ return -EINVAL;
/* should update bss info before STA add */
if (vif->type == NL80211_IFTYPE_STATION && !link_sta->sta->tdls) {
@@ -1034,6 +1040,8 @@ static void mt7925_mac_link_sta_assoc(struct mt76_dev *mdev,
msta = (struct mt792x_sta *)link_sta->sta->drv_priv;
mlink = mt792x_sta_to_link(msta, link_sta->link_id);
+ if (!mlink)
+ return;
mt792x_mutex_acquire(dev);
@@ -1043,12 +1051,13 @@ static void mt7925_mac_link_sta_assoc(struct mt76_dev *mdev,
link_conf = mt792x_vif_to_bss_conf(vif, vif->bss_conf.link_id);
}
- if (vif->type == NL80211_IFTYPE_STATION && !link_sta->sta->tdls) {
+ if (link_conf && vif->type == NL80211_IFTYPE_STATION && !link_sta->sta->tdls) {
struct mt792x_bss_conf *mconf;
mconf = mt792x_link_conf_to_mconf(link_conf);
- mt7925_mcu_add_bss_info(&dev->phy, mconf->mt76.ctx,
- link_conf, link_sta, true);
+ if (mconf)
+ mt7925_mcu_add_bss_info(&dev->phy, mconf->mt76.ctx,
+ link_conf, link_sta, true);
}
ewma_avg_signal_init(&mlink->avg_ack_signal);
@@ -1095,6 +1104,8 @@ static void mt7925_mac_link_sta_remove(struct mt76_dev *mdev,
msta = (struct mt792x_sta *)link_sta->sta->drv_priv;
mlink = mt792x_sta_to_link(msta, link_id);
+ if (!mlink)
+ return;
mt7925_roc_abort_sync(dev);
@@ -1108,10 +1119,12 @@ static void mt7925_mac_link_sta_remove(struct mt76_dev *mdev,
link_conf = mt792x_vif_to_bss_conf(vif, link_id);
- if (vif->type == NL80211_IFTYPE_STATION && !link_sta->sta->tdls) {
+ if (link_conf && vif->type == NL80211_IFTYPE_STATION && !link_sta->sta->tdls) {
struct mt792x_bss_conf *mconf;
mconf = mt792x_link_conf_to_mconf(link_conf);
+ if (!mconf)
+ goto out;
if (ieee80211_vif_is_mld(vif))
mt792x_mac_link_bss_remove(dev, mconf, mlink);
@@ -1119,6 +1132,7 @@ static void mt7925_mac_link_sta_remove(struct mt76_dev *mdev,
mt7925_mcu_add_bss_info(&dev->phy, mconf->mt76.ctx, link_conf,
link_sta, false);
}
+out:
spin_lock_bh(&mdev->sta_poll_lock);
if (!list_empty(&mlink->wcid.poll_list))
@@ -2031,6 +2045,11 @@ mt7925_change_vif_links(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
mlink = mlinks[link_id];
link_conf = mt792x_vif_to_bss_conf(vif, link_id);
+ if (!link_conf) {
+ err = -EINVAL;
+ goto free;
+ }
+
rcu_assign_pointer(mvif->link_conf[link_id], mconf);
rcu_assign_pointer(mvif->sta.link[link_id], mlink);
--
2.52.0
^ permalink raw reply related
* [PATCH v4 04/21] wifi: mt76: mt7925: add NULL checks in MCU STA TLV functions
From: Zac @ 2026-01-16 1:05 UTC (permalink / raw)
To: sean.wang
Cc: deren.wu, kvalo, linux-kernel, linux-mediatek, linux-wireless,
lorenzo, nbd, linux, ryder.lee, sean.wang, Zac Bowling,
Zac Bowling
In-Reply-To: <20260116010519.37001-1-zac@zacbowling.com>
From: Zac Bowling <zbowling@gmail.com>
Add NULL pointer checks for link_conf and mconf in:
- mt7925_mcu_sta_phy_tlv(): builds PHY capability TLV for station record
- mt7925_mcu_sta_rate_ctrl_tlv(): builds rate control TLV for station record
Both functions call mt792x_vif_to_bss_conf() and mt792x_vif_to_link()
which can return NULL during MLO link state transitions when the link
configuration in mac80211 is not yet synchronized with the driver's
link tracking.
Without these checks, the driver will crash with a NULL pointer
dereference when accessing link_conf->chanreq.oper or link_conf->basic_rates.
Found through static analysis (clang-tidy pattern matching for unchecked
return values from functions known to return NULL).
Reported-by: Zac Bowling <zac@zacbowling.com>
Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
Signed-off-by: Zac Bowling <zac@zacbowling.com>
---
drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
index cf0fdea45c..d61a7fbda7 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
@@ -1773,6 +1773,10 @@ mt7925_mcu_sta_phy_tlv(struct sk_buff *skb,
link_conf = mt792x_vif_to_bss_conf(vif, link_sta->link_id);
mconf = mt792x_vif_to_link(mvif, link_sta->link_id);
+
+ if (!link_conf || !mconf)
+ return;
+
chandef = mconf->mt76.ctx ? &mconf->mt76.ctx->def :
&link_conf->chanreq.oper;
@@ -1851,6 +1855,10 @@ mt7925_mcu_sta_rate_ctrl_tlv(struct sk_buff *skb,
link_conf = mt792x_vif_to_bss_conf(vif, link_sta->link_id);
mconf = mt792x_vif_to_link(mvif, link_sta->link_id);
+
+ if (!link_conf || !mconf)
+ return;
+
chandef = mconf->mt76.ctx ? &mconf->mt76.ctx->def :
&link_conf->chanreq.oper;
band = chandef->chan->band;
--
2.52.0
^ permalink raw reply related
* [PATCH v4 03/21] wifi: mt76: mt7925: fix missing mutex protection in runtime PM and MLO PM
From: Zac @ 2026-01-16 1:05 UTC (permalink / raw)
To: sean.wang
Cc: deren.wu, kvalo, linux-kernel, linux-mediatek, linux-wireless,
lorenzo, nbd, linux, ryder.lee, sean.wang, Zac Bowling,
Zac Bowling
In-Reply-To: <20260116010519.37001-1-zac@zacbowling.com>
From: Zac Bowling <zbowling@gmail.com>
Two additional code paths iterate over active interfaces and call MCU
functions without proper mutex protection:
1. mt7925_set_runtime_pm(): Called when runtime PM settings change.
The callback mt7925_pm_interface_iter() calls mt7925_mcu_set_beacon_filter()
which in turn calls mt7925_mcu_set_rxfilter(). These MCU functions require
the device mutex to be held.
2. mt7925_mlo_pm_work(): A workqueue function for MLO power management.
The callback mt7925_mlo_pm_iter() was acquiring mutex internally, which
is inconsistent with the rest of the driver where the caller holds the
mutex during interface iteration.
These bugs can cause deadlocks when:
- Power management settings are changed while WiFi is active
- MLO power save state transitions occur during roaming
Move the mutex to the caller in mt7925_mlo_pm_work() for consistency
with the rest of the driver, and add mutex protection in
mt7925_set_runtime_pm().
Found through static analysis (clang-tidy) and comparison with the
MT7615 driver which correctly acquires mutex before interface iteration.
Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
Reported-by: Zac Bowling <zac@zacbowling.com>
Tested-by: Zac Bowling <zac@zacbowling.com>
Signed-off-by: Zac Bowling <zac@zacbowling.com>
---
drivers/net/wireless/mediatek/mt76/mt7925/main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/main.c b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
index 3001a62a8b..9f17b21aef 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
@@ -751,9 +751,11 @@ void mt7925_set_runtime_pm(struct mt792x_dev *dev)
bool monitor = !!(hw->conf.flags & IEEE80211_CONF_MONITOR);
pm->enable = pm->enable_user && !monitor;
+ mt792x_mutex_acquire(dev);
ieee80211_iterate_active_interfaces(hw,
IEEE80211_IFACE_ITER_RESUME_ALL,
mt7925_pm_interface_iter, dev);
+ mt792x_mutex_release(dev);
pm->ds_enable = pm->ds_enable_user && !monitor;
mt7925_mcu_set_deep_sleep(dev, pm->ds_enable);
}
@@ -1301,14 +1303,12 @@ mt7925_mlo_pm_iter(void *priv, u8 *mac, struct ieee80211_vif *vif)
if (mvif->mlo_pm_state != MT792x_MLO_CHANGED_PS)
return;
- mt792x_mutex_acquire(dev);
for_each_set_bit(i, &valid, IEEE80211_MLD_MAX_NUM_LINKS) {
bss_conf = mt792x_vif_to_bss_conf(vif, i);
if (!bss_conf)
continue;
mt7925_mcu_uni_bss_ps(dev, bss_conf);
}
- mt792x_mutex_release(dev);
}
void mt7925_mlo_pm_work(struct work_struct *work)
@@ -1317,9 +1317,11 @@ void mt7925_mlo_pm_work(struct work_struct *work)
mlo_pm_work.work);
struct ieee80211_hw *hw = mt76_hw(dev);
+ mt792x_mutex_acquire(dev);
ieee80211_iterate_active_interfaces(hw,
IEEE80211_IFACE_ITER_RESUME_ALL,
mt7925_mlo_pm_iter, dev);
+ mt792x_mutex_release(dev);
}
void mt7925_scan_work(struct work_struct *work)
--
2.52.0
^ permalink raw reply related
* [PATCH v4 02/21] wifi: mt76: mt7925: fix missing mutex protection in reset and ROC abort
From: Zac @ 2026-01-16 1:05 UTC (permalink / raw)
To: sean.wang
Cc: deren.wu, kvalo, linux-kernel, linux-mediatek, linux-wireless,
lorenzo, nbd, linux, ryder.lee, sean.wang, Zac Bowling,
Zac Bowling
In-Reply-To: <20260116010519.37001-1-zac@zacbowling.com>
From: Zac Bowling <zbowling@gmail.com>
During firmware recovery and ROC (Remain On Channel) abort operations,
the driver iterates over active interfaces and calls MCU functions that
require the device mutex to be held, but the mutex was not acquired.
This causes system-wide deadlocks where the system becomes completely
unresponsive. From logs on affected systems:
INFO: task kworker/u128:0:48737 blocked for more than 122 seconds.
Workqueue: mt76 mt7925_mac_reset_work [mt7925_common]
Call Trace:
__schedule+0x426/0x12c0
schedule+0x27/0xf0
schedule_preempt_disabled+0x15/0x30
__mutex_lock.constprop.0+0x3d0/0x6d0
mt7925_mac_reset_work+0x85/0x170 [mt7925_common]
The deadlock manifests approximately every 5 minutes when the adapter
tries to hop to a better BSSID, triggering firmware reset. Network
commands (ip, ifconfig, etc.) hang indefinitely, processes get stuck
in uninterruptible sleep (D state), and reboot hangs as well.
Add mutex protection around interface iteration in:
- mt7925_mac_reset_work(): Called during firmware recovery after MCU
timeouts to reconnect all interfaces
- mt7925_roc_abort_sync() in suspend path: Called during suspend to
clean up Remain On Channel operations
This matches the pattern used in mt7615 and other MediaTek drivers where
interface iteration callbacks invoke MCU functions with mutex held:
// mt7615/main.c - roc_work has mutex protection
mt7615_mutex_acquire(phy->dev);
ieee80211_iterate_active_interfaces(...);
mt7615_mutex_release(phy->dev);
Note: Sean Wang from MediaTek has submitted an alternative fix for the
ROC path using cancel_delayed_work() instead of cancel_delayed_work_sync().
Both approaches address the deadlock; this one adds explicit mutex
protection which may be superseded by the upstream fix.
Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
Link: https://community.frame.work/t/kernel-panic-from-wifi-mediatek-mt7925-nullptr-dereference/79301
Reported-by: Zac Bowling <zac@zacbowling.com>
Tested-by: Zac Bowling <zac@zacbowling.com>
Signed-off-by: Zac Bowling <zac@zacbowling.com>
---
drivers/net/wireless/mediatek/mt76/mt7925/mac.c | 2 ++
drivers/net/wireless/mediatek/mt76/mt7925/pci.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mac.c b/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
index 184efe8afa..06420ac6ed 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
@@ -1331,9 +1331,11 @@ void mt7925_mac_reset_work(struct work_struct *work)
dev->hw_full_reset = false;
pm->suspended = false;
ieee80211_wake_queues(hw);
+ mt792x_mutex_acquire(dev);
ieee80211_iterate_active_interfaces(hw,
IEEE80211_IFACE_ITER_RESUME_ALL,
mt7925_vif_connect_iter, NULL);
+ mt792x_mutex_release(dev);
mt76_connac_power_save_sched(&dev->mt76.phy, pm);
mt7925_regd_change(&dev->phy, "00");
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/pci.c b/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
index c4161754c0..e9d62c6aee 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
@@ -455,7 +455,9 @@ static int mt7925_pci_suspend(struct device *device)
cancel_delayed_work_sync(&pm->ps_work);
cancel_work_sync(&pm->wake_work);
+ mt792x_mutex_acquire(dev);
mt7925_roc_abort_sync(dev);
+ mt792x_mutex_release(dev);
err = mt792x_mcu_drv_pmctrl(dev);
if (err < 0)
--
2.52.0
^ permalink raw reply related
* [PATCH v4 01/21] wifi: mt76: mt7925: fix NULL pointer dereference in vif iteration
From: Zac @ 2026-01-16 1:04 UTC (permalink / raw)
To: sean.wang
Cc: deren.wu, kvalo, linux-kernel, linux-mediatek, linux-wireless,
lorenzo, nbd, linux, ryder.lee, sean.wang, Zac Bowling,
Zac Bowling
In-Reply-To: <20260116010519.37001-1-zac@zacbowling.com>
From: Zac Bowling <zbowling@gmail.com>
mt792x_vif_to_bss_conf() can return NULL when iterating over valid_links
during HW reset or other state transitions, because the link configuration
in mac80211 may not be set up yet even though the driver's valid_links
bitmap has the link marked as valid.
This causes a NULL pointer dereference in mt76_connac_mcu_uni_add_dev()
when it tries to access bss_conf->vif->type, and similar crashes in other
functions that use bss_conf without checking.
This crash was observed on Framework Desktop (AMD Ryzen AI Max 300) with
MT7925 (RZ717) running kernel 6.17. The panic occurs during BSSID roaming
when the adapter attempts to switch to a better access point:
BUG: kernel NULL pointer dereference, address: 0000000000000010
CPU: 1 UID: 0 PID: 8362 Comm: kworker/u128:10 Tainted: G OE
Workqueue: mt76 mt7925_mac_reset_work [mt7925_common]
RIP: 0010:mt76_connac_mcu_uni_add_dev+0x9c/0x780 [mt76_connac_lib]
Call Trace:
mt7925_vif_connect_iter+0xcb/0x240 [mt7925_common]
__iterate_interfaces+0x92/0x130 [mac80211]
ieee80211_iterate_interfaces+0x3d/0x60 [mac80211]
mt7925_mac_reset_work+0x105/0x190 [mt7925_common]
process_one_work+0x18b/0x370
worker_thread+0x317/0x450
The issue manifests approximately every 5 minutes when the adapter tries
to hop to a better BSSID, causing system-wide hangs where network commands
(ip, ifconfig, etc.) hang indefinitely.
Add NULL checks for bss_conf before using it in:
- mt7925_vif_connect_iter()
- mt7925_change_vif_links()
- mt7925_mac_sta_assoc()
- mt7925_mac_sta_remove_links()
Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
Link: https://community.frame.work/t/kernel-panic-from-wifi-mediatek-mt7925-nullptr-dereference/79301
Reported-by: Zac Bowling <zac@zacbowling.com>
Tested-by: Zac Bowling <zac@zacbowling.com>
Signed-off-by: Zac Bowling <zac@zacbowling.com>
---
drivers/net/wireless/mediatek/mt76/mt7925/mac.c | 6 ++++++
drivers/net/wireless/mediatek/mt76/mt7925/main.c | 8 ++++++++
2 files changed, 14 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mac.c b/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
index 871b671019..184efe8afa 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
@@ -1271,6 +1271,12 @@ mt7925_vif_connect_iter(void *priv, u8 *mac,
bss_conf = mt792x_vif_to_bss_conf(vif, i);
mconf = mt792x_vif_to_link(mvif, i);
+ /* Skip links that don't have bss_conf set up yet in mac80211.
+ * This can happen during HW reset when link state is inconsistent.
+ */
+ if (!bss_conf)
+ continue;
+
mt76_connac_mcu_uni_add_dev(&dev->mphy, bss_conf, &mconf->mt76,
&mvif->sta.deflink.wcid, true);
mt7925_mcu_set_tx(dev, bss_conf);
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/main.c b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
index 2d358a9664..3001a62a8b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
@@ -1304,6 +1304,8 @@ mt7925_mlo_pm_iter(void *priv, u8 *mac, struct ieee80211_vif *vif)
mt792x_mutex_acquire(dev);
for_each_set_bit(i, &valid, IEEE80211_MLD_MAX_NUM_LINKS) {
bss_conf = mt792x_vif_to_bss_conf(vif, i);
+ if (!bss_conf)
+ continue;
mt7925_mcu_uni_bss_ps(dev, bss_conf);
}
mt792x_mutex_release(dev);
@@ -1630,6 +1632,8 @@ static void mt7925_ipv6_addr_change(struct ieee80211_hw *hw,
for_each_set_bit(i, &valid, IEEE80211_MLD_MAX_NUM_LINKS) {
bss_conf = mt792x_vif_to_bss_conf(vif, i);
+ if (!bss_conf)
+ continue;
__mt7925_ipv6_addr_change(hw, bss_conf, idev);
}
}
@@ -1861,6 +1865,8 @@ static void mt7925_vif_cfg_changed(struct ieee80211_hw *hw,
if (changed & BSS_CHANGED_ARP_FILTER) {
for_each_set_bit(i, &valid, IEEE80211_MLD_MAX_NUM_LINKS) {
bss_conf = mt792x_vif_to_bss_conf(vif, i);
+ if (!bss_conf)
+ continue;
mt7925_mcu_update_arp_filter(&dev->mt76, bss_conf);
}
}
@@ -1876,6 +1882,8 @@ static void mt7925_vif_cfg_changed(struct ieee80211_hw *hw,
} else if (mvif->mlo_pm_state == MT792x_MLO_CHANGED_PS) {
for_each_set_bit(i, &valid, IEEE80211_MLD_MAX_NUM_LINKS) {
bss_conf = mt792x_vif_to_bss_conf(vif, i);
+ if (!bss_conf)
+ continue;
mt7925_mcu_uni_bss_ps(dev, bss_conf);
}
}
--
2.52.0
^ permalink raw reply related
* [PATCH v4 00/21] wifi: mt76: mt7925/mt7921: stability and MLO fixes
From: Zac @ 2026-01-16 1:04 UTC (permalink / raw)
To: sean.wang
Cc: deren.wu, kvalo, linux-kernel, linux-mediatek, linux-wireless,
lorenzo, nbd, linux, ryder.lee, sean.wang, Zac
In-Reply-To: <CAGp9LzpuyXRDa=TxqY+Xd5ZhDVvNayWbpMGDD1T0g7apkn7P0A@mail.gmail.com>
This series addresses stability issues in the mt7925 (WiFi 7) and mt7921
drivers, focusing on NULL pointer dereferences, mutex protection, and
MLO (Multi-Link Operation) handling.
Changes since v3:
- Added mt7921 driver fixes (patches 18-19) to address mutex handling
issues that also affected the older driver
- Fixed mutex deadlocks in mt7921 suspend paths - the mutex was being
acquired inside functions that were already called with mutex held
- Added mt76 core fix for list corruption in mt76_wcid_cleanup (patch 20)
that caused crashes during suspend/resume cycles
- Added fix for BA session teardown during beacon loss (patch 21) which
was causing mac80211 WARN in __ieee80211_stop_tx_ba_session - reported
by Sean Wang
The mt7921 mutex fixes (patches 18-19) correct improper mutex nesting
where mt7921_roc_abort_sync() and mt7921_set_runtime_pm() were acquiring
the mutex internally, but were called from paths that already held it
(e.g., mt7921_mac_sta_remove via mt76_sta_remove, suspend handlers).
The list corruption fix (patch 20) addresses a bug where mt76_wcid_cleanup()
wasn't removing wcid entries from sta_poll_list before mt76_reset_device()
reinitialized the master list, leaving stale pointers.
The BA session fix (patch 21) makes the ieee80211_stop_tx_ba_cb_irqsafe()
callback unconditional in IEEE80211_AMPDU_TX_STOP_CONT handling - the MCU
command may fail during beacon loss but mac80211 must still be notified
to complete the session teardown.
More notes in https://github.com/zbowling/mt7925
Tested on MT7925 (RZ616) with kernel 6.18.5.
Zac Bowling (21):
wifi: mt76: mt7921: fix missing mutex protection in multiple paths
wifi: mt76: mt7921: fix mutex deadlocks in multiple paths
wifi: mt76: fix list corruption in mt76_wcid_cleanup
wifi: mt76: mt7925: fix BA session teardown during beacon loss
wifi: mt76: mt7925: fix NULL pointer dereference in vif iteration
wifi: mt76: mt7925: fix missing mutex protection in reset and ROC
abort
wifi: mt76: mt7925: fix missing mutex protection in runtime PM and MLO
PM
wifi: mt76: mt7925: add NULL checks in MCU STA TLV functions
wifi: mt76: mt7925: add NULL checks for link_conf and mlink in main.c
wifi: mt76: mt7925: add error handling for AMPDU MCU commands
wifi: mt76: mt7925: add error handling for BSS info MCU command in
sta_add
wifi: mt76: mt7925: add error handling for BSS info in key setup
wifi: mt76: mt7925: add NULL checks in MLO link and chanctx functions
wifi: mt76: mt792x: fix NULL pointer dereference in TX path
wifi: mt76: mt7925: add lockdep assertions for mutex verification
wifi: mt76: mt7925: fix key removal failure during MLO roaming
wifi: mt76: mt7925: fix kernel warning in MLO ROC setup
wifi: mt76: mt7925: add NULL checks for MLO link pointers in MCU
functions
wifi: mt76: mt792x: fix firmware reload failure after previous load
crash
wifi: mt76: mt7925: add mutex protection in resume path
wifi: mt76: mt7925: add NULL checks in link station and TX queue setup
drivers/net/wireless/mediatek/mt76/mac80211.c | 10 ++
.../net/wireless/mediatek/mt76/mt7921/mac.c | 2 +
.../net/wireless/mediatek/mt76/mt7921/main.c | 8 ++
.../net/wireless/mediatek/mt76/mt7921/pci.c | 2 +
.../net/wireless/mediatek/mt76/mt7921/sdio.c | 2 +
.../net/wireless/mediatek/mt76/mt7925/mac.c | 8 ++
.../net/wireless/mediatek/mt76/mt7925/main.c | 125 ++++++++++++++----
.../net/wireless/mediatek/mt76/mt7925/mcu.c | 48 +++++--
.../net/wireless/mediatek/mt76/mt7925/pci.c | 4 +
.../net/wireless/mediatek/mt76/mt792x_core.c | 27 +++-
10 files changed, 203 insertions(+), 33 deletions(-)
--
2.52.0
^ permalink raw reply
* Re: [PATCH v3 00/17] wifi: mt76: mt7925/mt792x: comprehensive stability fixes
From: Zac Bowling @ 2026-01-16 0:43 UTC (permalink / raw)
To: Sean Wang
Cc: deren.wu, kvalo, linux-kernel, linux-mediatek, linux-wireless,
lorenzo, nbd, ryder.lee, sean.wang
In-Reply-To: <CAGp9LzpuyXRDa=TxqY+Xd5ZhDVvNayWbpMGDD1T0g7apkn7P0A@mail.gmail.com>
Hi Sean,
Thanks for testing this and catching that WARN. Good catch. Yeah, that
was my bug. One of my attempts to handle all error returns that my
static analyzer said was unhandled meant I didn't actually hit a
required callback because I early returned too soon. Patched it
locally already and it's my repo. Will send in just a sec after my
poor-mans stress finishes running tests. I found another bug this
morning too, I need to send with device resets coming out of suspend
and corrupted list from the past initialization.
Zac Bowling
On Thu, Jan 15, 2026 at 4:15 PM Sean Wang <sean.wang@kernel.org> wrote:
>
> Hi Zac,
>
> Thanks for sharing this series. Overall the patches look good to me,
> and I’m continuing more testing to ensure there are no regressions on
> mt7925 and mt7921 further
> But today I do hit a kernel WARN in the disconnect path (mac80211 BA
> session teardown) while testing v3 of the series
>
> [ 3373.120224] Hardware name: HP HP EliteBook 830 G6/854A, BIOS R70
> Ver. 01.22.00 10/14/2022
> [ 3373.120228] Workqueue: events_unbound cfg80211_wiphy_work [cfg80211]
> [ 3373.120367] RIP: 0010:__ieee80211_stop_tx_ba_session+0x295/0x350 [mac80211]
> [ 3373.120570] Code: 11 0f 83 a3 00 00 00 48 c7 80 90 03 00 00 00 00
> 00 00 48 8b 7d 98 e8 4a 26 f3 fa 4c 89 ee 4c 89 ef e8 6f 16 0b fa 31
> c0 eb 93 <0f> 0b 31 c0 eb 8d b8 8e ff ff ff eb 86 48 8b 7d 98 e8 25 26
> f3 fa
> [ 3373.120576] RSP: 0018:ffffd00902ed7ba0 EFLAGS: 00010206
> [ 3373.120583] RAX: 0000000000010003 RBX: 0000000000000003 RCX: 0000000000000000
> [ 3373.120587] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> [ 3373.120591] RBP: ffffd00902ed7c10 R08: 0000000000000000 R09: 0000000000000000
> [ 3373.120596] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> [ 3373.120599] R13: ffff8a8433717540 R14: ffff8a83e0b20960 R15: ffff8a834d42c000
> [ 3373.120604] FS: 0000000000000000(0000) GS:ffff8a8477b03000(0000)
> knlGS:0000000000000000
> [ 3373.120608] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 3373.120626] CR2: 00007b9e0a8ba0d0 CR3: 000000009a440005 CR4: 00000000003726f0
> [ 3373.120631] Call Trace:
> [ 3373.120656] <TASK>
> [ 3373.120664] ieee80211_sta_tear_down_BA_sessions+0x53/0xe0 [mac80211]
> [ 3373.120836] __sta_info_destroy_part1+0x48/0x550 [mac80211]
> [ 3373.120994] __sta_info_flush+0x10e/0x230 [mac80211]
> [ 3373.121150] ieee80211_set_disassoc+0x6b3/0x900 [mac80211]
> [ 3373.121293] ? _printk+0x5f/0x90
> [ 3373.121330] __ieee80211_disconnect+0xd6/0x1a0 [mac80211]
> [ 3373.121446] ieee80211_beacon_connection_loss_work+0x6d/0xc0 [mac80211]
> [ 3373.121573] cfg80211_wiphy_work+0xb4/0x190 [cfg80211]
> [ 3373.121779] process_one_work+0x191/0x3e0
> [ 3373.121789] worker_thread+0x2e3/0x420
> [ 3373.121796] ? __pfx_worker_thread+0x10/0x10
> [ 3373.121802] kthread+0x10d/0x230
> [ 3373.121810] ? __pfx_kthread+0x10/0x10
> [ 3373.121818] ret_from_fork+0x205/0x230
> [ 3373.121826] ? __pfx_kthread+0x10/0x10
> [ 3373.121832] ret_from_fork_asm+0x1a/0x30
> [ 3373.121842] </TASK>
> [ 3373.121844] ---[ end trace 0000000000000000 ]---
> [ 3373.128750] ------------[ cut here ]------------
> [ 3373.128757] WARNING: CPU: 1 PID: 14854 at net/mac80211/agg-tx.c:398
> __ieee80211_stop_tx_ba_session+0x295/0x350 [mac80211]
>
> I’m currently bisecting the series to identify which patch triggers it
> and will follow up once I have clearer results.
> Thanks again for the work and the DKMS setup.
>
> Sean
>
> On Sun, Jan 4, 2026 at 6:27 PM Zac Bowling <zbowling@gmail.com> wrote:
> >
> > From: Zac Bowling <zac@zacbowling.com>
> >
> > This patch series addresses kernel panics, system deadlocks, and various
> > stability issues in the MT7925 WiFi driver. The issues were discovered on
> > kernel 6.17 (Ubuntu 25.10) and fixes were developed and tested on 6.18.2.
> >
> > These patches are based on the wireless tree (nbd168/wireless.git) as
> > requested by Sean Wang.
> >
> > == Problem Description ==
> >
> > The MT7925 driver has several bugs that cause:
> > - Kernel NULL pointer dereferences during BSSID roaming
> > - System-wide deadlocks requiring hard reboot
> > - Firmware reload failures after suspend/resume
> > - Key removal errors during MLO roaming
> >
> > These issues manifest approximately every 5 minutes when the adapter
> > tries to switch to a better BSSID, particularly in enterprise environments
> > with multiple access points.
> >
> > == Root Causes ==
> >
> > 1. Missing mutex protection around ieee80211_iterate_active_interfaces()
> > when the callback invokes MCU functions (patches 2, 3, 16)
> >
> > 2. NULL pointer dereferences where mt792x_vif_to_bss_conf(),
> > mt792x_sta_to_link(), and similar functions return NULL during
> > MLO state transitions but results are not checked (patches 1, 4, 5,
> > 9, 10, 14, 17)
> >
> > 3. Ignored MCU return values hiding firmware errors (patches 6, 7, 8)
> >
> > 4. WARN_ON_ONCE used where NULL is expected during normal MLO AP
> > setup (patch 13)
> >
> > 5. Firmware semaphore not released after failed load attempts (patch 15)
> >
> > 6. Key removal returning error when link is already torn down (patch 12)
> >
> > == Testing ==
> >
> > Stress tested by hammering the driver with custom test script.
> >
> > Tested on:
> > - Framework Desktop (AMD Ryzen AI Max 300 Series) with MT7925 (RZ717)
> > - This whole patch series was tested on Kernel 6.18.2 and 6.17.12 (Ubuntu 25.10)
> > - Enterprise WiFi environment with multiple WIFI 7 APs with MLO enabled
> >
> > Before patches: System hangs/panics every 5-15 minutes during BSSID roaming
> > After patches: Stable for 24+ hours under continuous stress testing
> >
> > == Crash Traces Fixed ==
> >
> > Primary NULL pointer dereference:
> > BUG: kernel NULL pointer dereference, address: 0000000000000010
> > Workqueue: mt76 mt7925_mac_reset_work [mt7925_common]
> > RIP: 0010:mt76_connac_mcu_uni_add_dev+0x9c/0x780 [mt76_connac_lib]
> > Call Trace:
> > mt7925_vif_connect_iter+0xcb/0x240 [mt7925_common]
> > __iterate_interfaces+0x92/0x130 [mac80211]
> > ieee80211_iterate_interfaces+0x3d/0x60 [mac80211]
> > mt7925_mac_reset_work+0x105/0x190 [mt7925_common]
> >
> > Deadlock trace:
> > INFO: task kworker/u128:0:48737 blocked for more than 122 seconds.
> > Workqueue: mt76 mt7925_mac_reset_work [mt7925_common]
> > Call Trace:
> > __mutex_lock.constprop.0+0x3d0/0x6d0
> > mt7925_mac_reset_work+0x85/0x170 [mt7925_common]
> >
> > == Related Links ==
> >
> > Framework Community discussion:
> > https://community.frame.work/t/kernel-panic-from-wifi-mediatek-mt7925-nullptr-dereference/79301
> >
> > OpenWrt GitHub issues:
> > https://github.com/openwrt/mt76/issues/1014
> > https://github.com/openwrt/mt76/issues/1036
> >
> > GitHub repository with additional analysis:
> > https://github.com/zbowling/mt7925
> >
> > Zac Bowling (17):
> > wifi: mt76: mt7925: fix NULL pointer dereference in vif iteration
> > wifi: mt76: mt7925: fix missing mutex protection in reset and ROC abort
> > wifi: mt76: mt7925: fix missing mutex protection in runtime PM and MLO PM
> > wifi: mt76: mt7925: add NULL checks in MCU STA TLV functions
> > wifi: mt76: mt7925: add NULL checks for link_conf and mlink in main.c
> > wifi: mt76: mt7925: add error handling for AMPDU MCU commands
> > wifi: mt76: mt7925: add error handling for BSS info MCU command in sta_add
> > wifi: mt76: mt7925: add error handling for BSS info in key setup
> > wifi: mt76: mt7925: add NULL checks in MLO link and chanctx functions
> > wifi: mt76: mt792x: fix NULL pointer dereference in TX path
> > wifi: mt76: mt7925: add lockdep assertions for mutex verification
> > wifi: mt76: mt7925: fix key removal failure during MLO roaming
> > wifi: mt76: mt7925: fix kernel warning in MLO ROC setup
> > wifi: mt76: mt7925: add NULL checks for MLO link pointers in MCU functions
> > wifi: mt76: mt792x: fix firmware reload failure after previous load crash
> > wifi: mt76: mt7925: add mutex protection in resume path
> > wifi: mt76: mt7925: add NULL checks in link station and TX queue setup
> >
> > drivers/net/wireless/mediatek/mt76/mt792x_core.c | 27 +++++++++++++++-
> > drivers/net/wireless/mediatek/mt76/mt7925/mac.c | 8 +++++
> > drivers/net/wireless/mediatek/mt76/mt7925/main.c | 95 +++++++++++++++++++++---
> > drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 52 ++++++++++++++---
> > drivers/net/wireless/mediatek/mt76/mt7925/pci.c | 6 +++
> > 5 files changed, 170 insertions(+), 18 deletions(-)
> >
> > --
> > 2.51.0
> >
^ permalink raw reply
* Re: [PATCH][next] ath6kl: wmi: Avoid -Wflex-array-member-not-at-end warning
From: Kees Cook @ 2026-01-16 0:27 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Jeff Johnson, Kalle Valo, linux-wireless, linux-kernel,
linux-hardening
In-Reply-To: <aR153k4ExCD-QTMq@kspp>
On Wed, Nov 19, 2025 at 05:03:42PM +0900, Gustavo A. R. Silva wrote:
> -Wflex-array-member-not-at-end was introduced in GCC-14, and we are
> getting ready to enable it, globally.
>
> Move the conflicting declaration (which happens to be in a union, so
> we're moving the entire union) to the end of the corresponding
> structure. Notice that `struct bss_bias_info` is a flexible structure,
> this is a structure that contains a flexible-array member.
>
> With these changes fix the following warning:
>
> drivers/net/wireless/ath/ath6kl/wmi.h:1658:20: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
>
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
> drivers/net/wireless/ath/ath6kl/wmi.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath6kl/wmi.h b/drivers/net/wireless/ath/ath6kl/wmi.h
> index 3080d82e25cc..0e7810b9372f 100644
> --- a/drivers/net/wireless/ath/ath6kl/wmi.h
> +++ b/drivers/net/wireless/ath/ath6kl/wmi.h
> @@ -1649,6 +1649,9 @@ struct low_rssi_scan_params {
> } __packed;
>
> struct roam_ctrl_cmd {
> + u8 roam_ctrl;
> +
> + /* Must be last as it ends in a flexible-array member. */
> union {
> u8 bssid[ETH_ALEN]; /* WMI_FORCE_ROAM */
> u8 roam_mode; /* WMI_SET_ROAM_MODE */
> @@ -1656,7 +1659,6 @@ struct roam_ctrl_cmd {
> struct low_rssi_scan_params params; /* WMI_SET_LRSSI_SCAN_PARAMS
> */
> } __packed info;
> - u8 roam_ctrl;
> } __packed;
It looks like this is a hardware interface, so I don't think roam_ctrl
can be moved like that. See ath6kl_wmi_set_roam_lrssi_cmd().
-Kees
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v3 00/17] wifi: mt76: mt7925/mt792x: comprehensive stability fixes
From: Sean Wang @ 2026-01-16 0:15 UTC (permalink / raw)
To: Zac Bowling
Cc: deren.wu, kvalo, linux-kernel, linux-mediatek, linux-wireless,
lorenzo, nbd, ryder.lee, sean.wang
In-Reply-To: <20260105002638.668723-1-zbowling@gmail.com>
Hi Zac,
Thanks for sharing this series. Overall the patches look good to me,
and I’m continuing more testing to ensure there are no regressions on
mt7925 and mt7921 further
But today I do hit a kernel WARN in the disconnect path (mac80211 BA
session teardown) while testing v3 of the series
[ 3373.120224] Hardware name: HP HP EliteBook 830 G6/854A, BIOS R70
Ver. 01.22.00 10/14/2022
[ 3373.120228] Workqueue: events_unbound cfg80211_wiphy_work [cfg80211]
[ 3373.120367] RIP: 0010:__ieee80211_stop_tx_ba_session+0x295/0x350 [mac80211]
[ 3373.120570] Code: 11 0f 83 a3 00 00 00 48 c7 80 90 03 00 00 00 00
00 00 48 8b 7d 98 e8 4a 26 f3 fa 4c 89 ee 4c 89 ef e8 6f 16 0b fa 31
c0 eb 93 <0f> 0b 31 c0 eb 8d b8 8e ff ff ff eb 86 48 8b 7d 98 e8 25 26
f3 fa
[ 3373.120576] RSP: 0018:ffffd00902ed7ba0 EFLAGS: 00010206
[ 3373.120583] RAX: 0000000000010003 RBX: 0000000000000003 RCX: 0000000000000000
[ 3373.120587] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 3373.120591] RBP: ffffd00902ed7c10 R08: 0000000000000000 R09: 0000000000000000
[ 3373.120596] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
[ 3373.120599] R13: ffff8a8433717540 R14: ffff8a83e0b20960 R15: ffff8a834d42c000
[ 3373.120604] FS: 0000000000000000(0000) GS:ffff8a8477b03000(0000)
knlGS:0000000000000000
[ 3373.120608] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3373.120626] CR2: 00007b9e0a8ba0d0 CR3: 000000009a440005 CR4: 00000000003726f0
[ 3373.120631] Call Trace:
[ 3373.120656] <TASK>
[ 3373.120664] ieee80211_sta_tear_down_BA_sessions+0x53/0xe0 [mac80211]
[ 3373.120836] __sta_info_destroy_part1+0x48/0x550 [mac80211]
[ 3373.120994] __sta_info_flush+0x10e/0x230 [mac80211]
[ 3373.121150] ieee80211_set_disassoc+0x6b3/0x900 [mac80211]
[ 3373.121293] ? _printk+0x5f/0x90
[ 3373.121330] __ieee80211_disconnect+0xd6/0x1a0 [mac80211]
[ 3373.121446] ieee80211_beacon_connection_loss_work+0x6d/0xc0 [mac80211]
[ 3373.121573] cfg80211_wiphy_work+0xb4/0x190 [cfg80211]
[ 3373.121779] process_one_work+0x191/0x3e0
[ 3373.121789] worker_thread+0x2e3/0x420
[ 3373.121796] ? __pfx_worker_thread+0x10/0x10
[ 3373.121802] kthread+0x10d/0x230
[ 3373.121810] ? __pfx_kthread+0x10/0x10
[ 3373.121818] ret_from_fork+0x205/0x230
[ 3373.121826] ? __pfx_kthread+0x10/0x10
[ 3373.121832] ret_from_fork_asm+0x1a/0x30
[ 3373.121842] </TASK>
[ 3373.121844] ---[ end trace 0000000000000000 ]---
[ 3373.128750] ------------[ cut here ]------------
[ 3373.128757] WARNING: CPU: 1 PID: 14854 at net/mac80211/agg-tx.c:398
__ieee80211_stop_tx_ba_session+0x295/0x350 [mac80211]
I’m currently bisecting the series to identify which patch triggers it
and will follow up once I have clearer results.
Thanks again for the work and the DKMS setup.
Sean
On Sun, Jan 4, 2026 at 6:27 PM Zac Bowling <zbowling@gmail.com> wrote:
>
> From: Zac Bowling <zac@zacbowling.com>
>
> This patch series addresses kernel panics, system deadlocks, and various
> stability issues in the MT7925 WiFi driver. The issues were discovered on
> kernel 6.17 (Ubuntu 25.10) and fixes were developed and tested on 6.18.2.
>
> These patches are based on the wireless tree (nbd168/wireless.git) as
> requested by Sean Wang.
>
> == Problem Description ==
>
> The MT7925 driver has several bugs that cause:
> - Kernel NULL pointer dereferences during BSSID roaming
> - System-wide deadlocks requiring hard reboot
> - Firmware reload failures after suspend/resume
> - Key removal errors during MLO roaming
>
> These issues manifest approximately every 5 minutes when the adapter
> tries to switch to a better BSSID, particularly in enterprise environments
> with multiple access points.
>
> == Root Causes ==
>
> 1. Missing mutex protection around ieee80211_iterate_active_interfaces()
> when the callback invokes MCU functions (patches 2, 3, 16)
>
> 2. NULL pointer dereferences where mt792x_vif_to_bss_conf(),
> mt792x_sta_to_link(), and similar functions return NULL during
> MLO state transitions but results are not checked (patches 1, 4, 5,
> 9, 10, 14, 17)
>
> 3. Ignored MCU return values hiding firmware errors (patches 6, 7, 8)
>
> 4. WARN_ON_ONCE used where NULL is expected during normal MLO AP
> setup (patch 13)
>
> 5. Firmware semaphore not released after failed load attempts (patch 15)
>
> 6. Key removal returning error when link is already torn down (patch 12)
>
> == Testing ==
>
> Stress tested by hammering the driver with custom test script.
>
> Tested on:
> - Framework Desktop (AMD Ryzen AI Max 300 Series) with MT7925 (RZ717)
> - This whole patch series was tested on Kernel 6.18.2 and 6.17.12 (Ubuntu 25.10)
> - Enterprise WiFi environment with multiple WIFI 7 APs with MLO enabled
>
> Before patches: System hangs/panics every 5-15 minutes during BSSID roaming
> After patches: Stable for 24+ hours under continuous stress testing
>
> == Crash Traces Fixed ==
>
> Primary NULL pointer dereference:
> BUG: kernel NULL pointer dereference, address: 0000000000000010
> Workqueue: mt76 mt7925_mac_reset_work [mt7925_common]
> RIP: 0010:mt76_connac_mcu_uni_add_dev+0x9c/0x780 [mt76_connac_lib]
> Call Trace:
> mt7925_vif_connect_iter+0xcb/0x240 [mt7925_common]
> __iterate_interfaces+0x92/0x130 [mac80211]
> ieee80211_iterate_interfaces+0x3d/0x60 [mac80211]
> mt7925_mac_reset_work+0x105/0x190 [mt7925_common]
>
> Deadlock trace:
> INFO: task kworker/u128:0:48737 blocked for more than 122 seconds.
> Workqueue: mt76 mt7925_mac_reset_work [mt7925_common]
> Call Trace:
> __mutex_lock.constprop.0+0x3d0/0x6d0
> mt7925_mac_reset_work+0x85/0x170 [mt7925_common]
>
> == Related Links ==
>
> Framework Community discussion:
> https://community.frame.work/t/kernel-panic-from-wifi-mediatek-mt7925-nullptr-dereference/79301
>
> OpenWrt GitHub issues:
> https://github.com/openwrt/mt76/issues/1014
> https://github.com/openwrt/mt76/issues/1036
>
> GitHub repository with additional analysis:
> https://github.com/zbowling/mt7925
>
> Zac Bowling (17):
> wifi: mt76: mt7925: fix NULL pointer dereference in vif iteration
> wifi: mt76: mt7925: fix missing mutex protection in reset and ROC abort
> wifi: mt76: mt7925: fix missing mutex protection in runtime PM and MLO PM
> wifi: mt76: mt7925: add NULL checks in MCU STA TLV functions
> wifi: mt76: mt7925: add NULL checks for link_conf and mlink in main.c
> wifi: mt76: mt7925: add error handling for AMPDU MCU commands
> wifi: mt76: mt7925: add error handling for BSS info MCU command in sta_add
> wifi: mt76: mt7925: add error handling for BSS info in key setup
> wifi: mt76: mt7925: add NULL checks in MLO link and chanctx functions
> wifi: mt76: mt792x: fix NULL pointer dereference in TX path
> wifi: mt76: mt7925: add lockdep assertions for mutex verification
> wifi: mt76: mt7925: fix key removal failure during MLO roaming
> wifi: mt76: mt7925: fix kernel warning in MLO ROC setup
> wifi: mt76: mt7925: add NULL checks for MLO link pointers in MCU functions
> wifi: mt76: mt792x: fix firmware reload failure after previous load crash
> wifi: mt76: mt7925: add mutex protection in resume path
> wifi: mt76: mt7925: add NULL checks in link station and TX queue setup
>
> drivers/net/wireless/mediatek/mt76/mt792x_core.c | 27 +++++++++++++++-
> drivers/net/wireless/mediatek/mt76/mt7925/mac.c | 8 +++++
> drivers/net/wireless/mediatek/mt76/mt7925/main.c | 95 +++++++++++++++++++++---
> drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 52 ++++++++++++++---
> drivers/net/wireless/mediatek/mt76/mt7925/pci.c | 6 +++
> 5 files changed, 170 insertions(+), 18 deletions(-)
>
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH ath-next v5 0/6] wifi: ath11k: Add single shot/periodic CFR capture support
From: Qian Zhang @ 2026-01-15 23:47 UTC (permalink / raw)
To: Jeff Johnson, Baochen Qiang, ath11k; +Cc: linux-wireless, Yu Zhang
In-Reply-To: <f0e98751-8fed-4cb8-9cc6-59a691f172b5@oss.qualcomm.com>
On 1/15/2026 12:55 AM, Jeff Johnson wrote:
> On 1/5/2026 3:51 AM, Qian Zhang wrote:
>> On 1/5/2026 10:22 AM, Baochen Qiang wrote:
>>> On 12/30/2025 4:25 PM, Qian Zhang wrote:
>>> what are these dependencies? They are not present in old revisions.
>>>
>>> BTW, if you indeed has dependencies, in addition to these prerequisite-patch-id's, please
>>> also list them explicitly in the cover letter above.
>>>
>>
>> These dependency details were added by mistake, and I will remove them.
>
> Was that the only known problem with the v5 series?
>
> My automation flagged a checkpatch issue in the 6/6 patch:
> WARNING:LINE_SPACING: Missing a blank line after declarations
>
> If there are no other issues with v5 then I can fix this in my pending branch.
> Or you can submit a v6. Just let me know.
>
> /jeff
This feature is under LX test now.
Patchset V6 will be submitted when testing is finished.
Fixes for new issues (if any new issue are found) as well
as all previous reviewer comments will be included in
the v6 patchset.
Qian
^ permalink raw reply
* Re: [PATCH v2 04/14] wifi: ath10k: snoc: support powering on the device via pwrseq
From: Jeff Johnson @ 2026-01-15 23:12 UTC (permalink / raw)
To: Dmitry Baryshkov, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Jeff Johnson,
Bjorn Andersson, Konrad Dybcio, Manivannan Sadhasivam, Vinod Koul,
Balakrishna Godavarthi, Matthias Kaehlcke
Cc: linux-arm-msm, linux-kernel, devicetree, linux-bluetooth,
linux-wireless, ath10k, linux-pm, Krzysztof Kozlowski,
Bartosz Golaszewski
In-Reply-To: <20260106-wcn3990-pwrctl-v2-4-0386204328be@oss.qualcomm.com>
On 1/5/2026 5:01 PM, Dmitry Baryshkov wrote:
> @@ -1023,9 +1024,15 @@ static int ath10k_hw_power_on(struct ath10k *ar)
>
> ath10k_dbg(ar, ATH10K_DBG_SNOC, "soc power on\n");
>
> + if (ar_snoc->pwrseq) {
> + ret = pwrseq_power_on(ar_snoc->pwrseq);
> + if (ret)
> + return ret;
> + }
> +
> ret = regulator_bulk_enable(ar_snoc->num_vregs, ar_snoc->vregs);
> if (ret)
> - return ret;
> + goto pwrseq_off;
>
> ret = clk_bulk_prepare_enable(ar_snoc->num_clks, ar_snoc->clks);
> if (ret)
> @@ -1035,18 +1042,28 @@ static int ath10k_hw_power_on(struct ath10k *ar)
>
> vreg_off:
> regulator_bulk_disable(ar_snoc->num_vregs, ar_snoc->vregs);
> +pwrseq_off:
> + pwrseq_power_off(ar_snoc->pwrseq);
in this function you conditionally call pwrseq_power_on()
but on error you unconditionally call pwrseq_power_off()
in the below function you conditionally call pwrseq_power_off()
so there is inconsistency.
note that both pwrseq_power_on() and pwrseq_power_off() handle a NULL
pwrseq_desc so is there any reason to not just call both both functions
unconditionally everywhere?
> +
> return ret;
> }
>
> static int ath10k_hw_power_off(struct ath10k *ar)
> {
> struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
> + int ret_seq = 0;
> + int ret_vreg;
>
> ath10k_dbg(ar, ATH10K_DBG_SNOC, "soc power off\n");
>
> clk_bulk_disable_unprepare(ar_snoc->num_clks, ar_snoc->clks);
>
> - return regulator_bulk_disable(ar_snoc->num_vregs, ar_snoc->vregs);
> + ret_vreg = regulator_bulk_disable(ar_snoc->num_vregs, ar_snoc->vregs);
> +
> + if (ar_snoc->pwrseq)
> + ret_seq = pwrseq_power_off(ar_snoc->pwrseq);
> +
> + return ret_vreg ? : ret_seq;
> }
>
> static void ath10k_snoc_wlan_disable(struct ath10k *ar)
^ permalink raw reply
* [PATCH 1/3] wifi: mt76: update timer APIs for kernel 6.18
From: Lucid Duck @ 2026-01-15 23:02 UTC (permalink / raw)
To: nbd, lorenzo.bianconi83; +Cc: linux-wireless, lucid_duck
In-Reply-To: <20260115230252.43391-1-lucid_duck@justthetip.ca>
Kernel 6.18 introduced several timer API changes:
- hrtimer_init() replaced with hrtimer_setup()
- del_timer_sync() renamed to timer_delete_sync()
- from_timer() macro removed, use container_of() directly
- asm/unaligned.h moved to linux/unaligned.h
Update all mt76 timer usage to the new APIs for kernel 6.18+
compatibility.
Signed-off-by: Lucid Duck <lucid_duck@justthetip.ca>
---
mt76.h | 1 +
mt7615/main.c | 6 +++---
mt7615/pci_mac.c | 4 ++--
mt7615/usb.c | 2 +-
mt76x0/eeprom.c | 2 +-
mt76x02_eeprom.c | 2 +-
mt76x02_usb_core.c | 4 ++--
mt76x2/eeprom.c | 2 +-
mt7925/main.c | 4 ++--
mt792x_core.c | 6 +++---
10 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/mt76.h b/mt76.h
index 646cc8e..4f48167 100644
--- a/mt76.h
+++ b/mt76.h
@@ -19,6 +19,7 @@
#include "airoha_offload.h"
#endif
#include <linux/soc/mediatek/mtk_wed.h>
+#include <linux/version.h>
#include <net/netlink.h>
#include <net/mac80211.h>
#if LINUX_VERSION_CODE < KERNEL_VERSION(6,6,0)
diff --git a/mt7615/main.c b/mt7615/main.c
index a18aa0d..2ac2ba8 100644
--- a/mt7615/main.c
+++ b/mt7615/main.c
@@ -97,7 +97,7 @@ static void mt7615_stop(struct ieee80211_hw *hw, bool suspend)
struct mt7615_phy *phy = mt7615_hw_phy(hw);
cancel_delayed_work_sync(&phy->mt76->mac_work);
- del_timer_sync(&phy->roc_timer);
+ timer_delete_sync(&phy->roc_timer);
cancel_work_sync(&phy->roc_work);
cancel_delayed_work_sync(&dev->pm.ps_work);
@@ -1046,7 +1046,7 @@ void mt7615_roc_work(struct work_struct *work)
void mt7615_roc_timer(struct timer_list *timer)
{
- struct mt7615_phy *phy = from_timer(phy, timer, roc_timer);
+ struct mt7615_phy *phy = container_of(timer, struct mt7615_phy, roc_timer);
ieee80211_queue_work(phy->mt76->hw, &phy->roc_work);
}
@@ -1197,7 +1197,7 @@ static int mt7615_cancel_remain_on_channel(struct ieee80211_hw *hw,
if (!test_and_clear_bit(MT76_STATE_ROC, &phy->mt76->state))
return 0;
- del_timer_sync(&phy->roc_timer);
+ timer_delete_sync(&phy->roc_timer);
cancel_work_sync(&phy->roc_work);
mt7615_mutex_acquire(phy->dev);
diff --git a/mt7615/pci_mac.c b/mt7615/pci_mac.c
index d83d8ec..53cb1ee 100644
--- a/mt7615/pci_mac.c
+++ b/mt7615/pci_mac.c
@@ -220,12 +220,12 @@ void mt7615_mac_reset_work(struct work_struct *work)
set_bit(MT76_MCU_RESET, &dev->mphy.state);
wake_up(&dev->mt76.mcu.wait);
cancel_delayed_work_sync(&dev->mphy.mac_work);
- del_timer_sync(&dev->phy.roc_timer);
+ timer_delete_sync(&dev->phy.roc_timer);
cancel_work_sync(&dev->phy.roc_work);
if (phy2) {
set_bit(MT76_RESET, &phy2->mt76->state);
cancel_delayed_work_sync(&phy2->mt76->mac_work);
- del_timer_sync(&phy2->roc_timer);
+ timer_delete_sync(&phy2->roc_timer);
cancel_work_sync(&phy2->roc_work);
}
diff --git a/mt7615/usb.c b/mt7615/usb.c
index 7736ae3..d91feff 100644
--- a/mt7615/usb.c
+++ b/mt7615/usb.c
@@ -85,7 +85,7 @@ static void mt7663u_stop(struct ieee80211_hw *hw, bool suspend)
struct mt7615_dev *dev = hw->priv;
clear_bit(MT76_STATE_RUNNING, &dev->mphy.state);
- del_timer_sync(&phy->roc_timer);
+ timer_delete_sync(&phy->roc_timer);
cancel_work_sync(&phy->roc_work);
cancel_delayed_work_sync(&phy->scan_work);
cancel_delayed_work_sync(&phy->mt76->mac_work);
diff --git a/mt76x0/eeprom.c b/mt76x0/eeprom.c
index f6720a4..d4506b8 100644
--- a/mt76x0/eeprom.c
+++ b/mt76x0/eeprom.c
@@ -10,7 +10,7 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
#include <linux/etherdevice.h>
-#include <asm/unaligned.h>
+#include <linux/unaligned.h>
#include "mt76x0.h"
#include "eeprom.h"
#include "../mt76x02_phy.h"
diff --git a/mt76x02_eeprom.c b/mt76x02_eeprom.c
index 2a15bd2..d16be0c 100644
--- a/mt76x02_eeprom.c
+++ b/mt76x02_eeprom.c
@@ -4,7 +4,7 @@
* Copyright (C) 2018 Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
*/
-#include <asm/unaligned.h>
+#include <linux/unaligned.h>
#include "mt76x02_eeprom.h"
diff --git a/mt76x02_usb_core.c b/mt76x02_usb_core.c
index c94c2f6..4ca311d 100644
--- a/mt76x02_usb_core.c
+++ b/mt76x02_usb_core.c
@@ -264,8 +264,8 @@ void mt76x02u_init_beacon_config(struct mt76x02_dev *dev)
};
dev->beacon_ops = &beacon_ops;
- hrtimer_init(&dev->pre_tbtt_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
- dev->pre_tbtt_timer.function = mt76x02u_pre_tbtt_interrupt;
+ hrtimer_setup(&dev->pre_tbtt_timer, mt76x02u_pre_tbtt_interrupt,
+ CLOCK_MONOTONIC, HRTIMER_MODE_REL);
INIT_WORK(&dev->pre_tbtt_work, mt76x02u_pre_tbtt_work);
mt76x02_init_beacon_config(dev);
diff --git a/mt76x2/eeprom.c b/mt76x2/eeprom.c
index e1e317a..782813a 100644
--- a/mt76x2/eeprom.c
+++ b/mt76x2/eeprom.c
@@ -5,7 +5,7 @@
#include <linux/module.h>
#include <linux/of.h>
-#include <asm/unaligned.h>
+#include <linux/unaligned.h>
#include "mt76x2.h"
#include "eeprom.h"
diff --git a/mt7925/main.c b/mt7925/main.c
index 307850a..2d358a9 100644
--- a/mt7925/main.c
+++ b/mt7925/main.c
@@ -457,7 +457,7 @@ void mt7925_roc_abort_sync(struct mt792x_dev *dev)
{
struct mt792x_phy *phy = &dev->phy;
- del_timer_sync(&phy->roc_timer);
+ timer_delete_sync(&phy->roc_timer);
cancel_work_sync(&phy->roc_work);
if (test_and_clear_bit(MT76_STATE_ROC, &phy->mt76->state))
ieee80211_iterate_interfaces(mt76_hw(dev),
@@ -489,7 +489,7 @@ static int mt7925_abort_roc(struct mt792x_phy *phy,
{
int err = 0;
- del_timer_sync(&phy->roc_timer);
+ timer_delete_sync(&phy->roc_timer);
cancel_work_sync(&phy->roc_work);
mt792x_mutex_acquire(phy->dev);
diff --git a/mt792x_core.c b/mt792x_core.c
index cc488ee..530e489 100644
--- a/mt792x_core.c
+++ b/mt792x_core.c
@@ -305,7 +305,7 @@ EXPORT_SYMBOL_GPL(mt792x_tx_worker);
void mt792x_roc_timer(struct timer_list *timer)
{
- struct mt792x_phy *phy = from_timer(phy, timer, roc_timer);
+ struct mt792x_phy *phy = container_of(timer, struct mt792x_phy, roc_timer);
ieee80211_queue_work(phy->mt76->hw, &phy->roc_work);
}
@@ -313,7 +313,7 @@ EXPORT_SYMBOL_GPL(mt792x_roc_timer);
void mt792x_csa_timer(struct timer_list *timer)
{
- struct mt792x_vif *mvif = from_timer(mvif, timer, csa_timer);
+ struct mt792x_vif *mvif = container_of(timer, struct mt792x_vif, csa_timer);
ieee80211_queue_work(mvif->phy->mt76->hw, &mvif->csa_work);
}
@@ -362,7 +362,7 @@ void mt792x_unassign_vif_chanctx(struct ieee80211_hw *hw,
mutex_unlock(&dev->mt76.mutex);
if (vif->bss_conf.csa_active) {
- del_timer_sync(&mvif->csa_timer);
+ timer_delete_sync(&mvif->csa_timer);
cancel_work_sync(&mvif->csa_work);
}
}
--
2.52.0
^ permalink raw reply related
* [PATCH 2/3] wifi: mt76: mt7921: convert to MLO callbacks and fix txpower reporting
From: Lucid Duck @ 2026-01-15 23:02 UTC (permalink / raw)
To: nbd, lorenzo.bianconi83; +Cc: linux-wireless, lucid_duck
In-Reply-To: <20260115230252.43391-1-lucid_duck@justthetip.ca>
Kernel 6.18's mac80211 MLO support requires splitting bss_info_changed
into vif_cfg_changed (VIF-wide) and link_info_changed (per-link).
Additionally, handle the case where bss_conf.txpower is not populated
(INT_MIN) when the interface is unassociated. This is intentional
mac80211 behavior - __ieee80211_recalc_txpower() returns early when
chanctx_conf is NULL.
When bss_conf.txpower is unset, fall back to the channel's regulatory
maximum for REPORTING purposes. This does NOT change actual RF power
(controlled by firmware) - only nl80211 reporting accuracy.
Changes:
- Split bss_info_changed into vif_cfg_changed + link_info_changed
- Route VIF-wide changes (ASSOC, PS, ARP_FILTER) to vif_cfg_changed
- Route per-link changes (ERP_SLOT, BEACON, TXPOWER) to link_info_changed
- Handle unset txpower gracefully for unassociated interfaces
Tested on Alfa AWUS036AXML (MT7921AU):
- Kernel 6.18.3 (Kali): Associated and unassociated tests pass
- Kernel 6.18.4 (Fedora): Associated and unassociated tests pass
Signed-off-by: Lucid Duck <lucid_duck@justthetip.ca>
---
mt7921/main.c | 84 +++++++++++++++++++++++++++++++++++++++------------
1 file changed, 64 insertions(+), 20 deletions(-)
diff --git a/mt7921/main.c b/mt7921/main.c
index 66051b0..391fafe 100644
--- a/mt7921/main.c
+++ b/mt7921/main.c
@@ -371,7 +371,7 @@ void mt7921_roc_abort_sync(struct mt792x_dev *dev)
{
struct mt792x_phy *phy = &dev->phy;
- del_timer_sync(&phy->roc_timer);
+ timer_delete_sync(&phy->roc_timer);
cancel_work_sync(&phy->roc_work);
if (test_and_clear_bit(MT76_STATE_ROC, &phy->mt76->state))
ieee80211_iterate_interfaces(mt76_hw(dev),
@@ -402,7 +402,7 @@ static int mt7921_abort_roc(struct mt792x_phy *phy, struct mt792x_vif *vif)
{
int err = 0;
- del_timer_sync(&phy->roc_timer);
+ timer_delete_sync(&phy->roc_timer);
cancel_work_sync(&phy->roc_work);
mt792x_mutex_acquire(phy->dev);
@@ -687,10 +687,49 @@ static void mt7921_configure_filter(struct ieee80211_hw *hw,
*total_flags &= (FIF_OTHER_BSS | FIF_FCSFAIL | FIF_CONTROL);
}
-static void mt7921_bss_info_changed(struct ieee80211_hw *hw,
- struct ieee80211_vif *vif,
- struct ieee80211_bss_conf *info,
- u64 changed)
+/*
+ * mt7921_vif_cfg_changed - handle VIF-wide configuration changes
+ *
+ * In kernel 6.18+, mac80211 splits bss_info_changed into vif_cfg_changed
+ * (VIF-wide) and link_info_changed (per-link). This handles VIF-wide changes.
+ */
+static void mt7921_vif_cfg_changed(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ u64 changed)
+{
+ struct mt792x_dev *dev = mt792x_hw_dev(hw);
+
+ mt792x_mutex_acquire(dev);
+
+ if (changed & BSS_CHANGED_PS)
+ mt7921_mcu_uni_bss_ps(dev, vif);
+
+ if (changed & BSS_CHANGED_ASSOC) {
+ mt7921_mcu_sta_update(dev, NULL, vif, true,
+ MT76_STA_INFO_STATE_ASSOC);
+ mt7921_mcu_set_beacon_filter(dev, vif, vif->cfg.assoc);
+ }
+
+ if (changed & BSS_CHANGED_ARP_FILTER) {
+ struct mt792x_vif *mvif = (struct mt792x_vif *)vif->drv_priv;
+
+ mt76_connac_mcu_update_arp_filter(&dev->mt76, &mvif->bss_conf.mt76,
+ &vif->bss_conf);
+ }
+
+ mt792x_mutex_release(dev);
+}
+
+/*
+ * mt7921_link_info_changed - handle per-link BSS information changes
+ *
+ * In kernel 6.18+, mac80211 uses link_info_changed callback for per-link
+ * BSS changes including TX power, ERP slot, beacon, QOS, etc.
+ */
+static void mt7921_link_info_changed(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ieee80211_bss_conf *info,
+ u64 changed)
{
struct mt792x_phy *phy = mt792x_hw_phy(hw);
struct mt792x_dev *dev = mt792x_hw_dev(hw);
@@ -715,23 +754,27 @@ static void mt7921_bss_info_changed(struct ieee80211_hw *hw,
if (changed & (BSS_CHANGED_QOS | BSS_CHANGED_BEACON_ENABLED))
mt7921_mcu_set_tx(dev, vif);
- if (changed & BSS_CHANGED_PS)
- mt7921_mcu_uni_bss_ps(dev, vif);
-
if (changed & BSS_CHANGED_CQM)
mt7921_mcu_set_rssimonitor(dev, vif);
- if (changed & BSS_CHANGED_ASSOC) {
- mt7921_mcu_sta_update(dev, NULL, vif, true,
- MT76_STA_INFO_STATE_ASSOC);
- mt7921_mcu_set_beacon_filter(dev, vif, vif->cfg.assoc);
- }
+ if (changed & BSS_CHANGED_TXPOWER) {
+ int tx_power = info->txpower;
- if (changed & BSS_CHANGED_ARP_FILTER) {
- struct mt792x_vif *mvif = (struct mt792x_vif *)vif->drv_priv;
+ /*
+ * Workaround for kernel 6.18+: bss_conf.txpower may not be
+ * populated (INT_MIN) even when BSS_CHANGED_TXPOWER is set.
+ * In this case, use the channel's max regulatory power.
+ */
+ if (tx_power == INT_MIN || tx_power <= 0) {
+ struct ieee80211_channel *chan = phy->mt76->chandef.chan;
- mt76_connac_mcu_update_arp_filter(&dev->mt76, &mvif->bss_conf.mt76,
- info);
+ if (chan)
+ tx_power = chan->max_reg_power;
+ }
+
+ /* txpower is in dBm, txpower_cur is in 0.5dBm units */
+ if (tx_power > 0 && tx_power < 127)
+ phy->mt76->txpower_cur = tx_power * 2;
}
mt792x_mutex_release(dev);
@@ -1494,7 +1537,7 @@ static void mt7921_abort_channel_switch(struct ieee80211_hw *hw,
{
struct mt792x_vif *mvif = (struct mt792x_vif *)vif->drv_priv;
- del_timer_sync(&mvif->csa_timer);
+ timer_delete_sync(&mvif->csa_timer);
cancel_work_sync(&mvif->csa_work);
}
@@ -1535,7 +1578,8 @@ const struct ieee80211_ops mt7921_ops = {
.config = mt7921_config,
.conf_tx = mt792x_conf_tx,
.configure_filter = mt7921_configure_filter,
- .bss_info_changed = mt7921_bss_info_changed,
+ .vif_cfg_changed = mt7921_vif_cfg_changed,
+ .link_info_changed = mt7921_link_info_changed,
.start_ap = mt7921_start_ap,
.stop_ap = mt7921_stop_ap,
.sta_state = mt7921_sta_state,
--
2.52.0
^ permalink raw reply related
* [PATCH 0/3] wifi: mt76: kernel 6.18 compatibility and txpower reporting fix
From: Lucid Duck @ 2026-01-15 23:02 UTC (permalink / raw)
To: nbd, lorenzo.bianconi83; +Cc: linux-wireless, lucid_duck
This series addresses kernel 6.18 API changes and fixes TX power
REPORTING accuracy for mt7921 (and related connac devices) when
the interface is unassociated.
IMPORTANT: These patches do NOT change actual RF transmit power.
The firmware power tables and regulatory limits remain unchanged.
This only fixes how the driver REPORTS txpower to userspace via
nl80211 (e.g., `iw dev wlan0 info`).
Background
----------
In kernel 6.18, mac80211's __ieee80211_recalc_txpower() returns early
when chanctx_conf is NULL (unassociated interface), leaving
bss_conf.txpower at INT_MIN. This is intentional mac80211 behavior.
However, BSS_CHANGED_TXPOWER is still fired with txpower_type set
correctly but txpower=INT_MIN. Without driver-side handling, this
results in misleading txpower values (3 dBm) reported to userspace.
Testing
-------
Tested on Alfa AWUS036AXML (MT7921AU):
Kernel 6.18.3 (Kali Linux):
- Unassociated: Uses regulatory max for reporting
- Associated: Exact user-requested values work
- Firmware txpower_sku debugfs unchanged
Kernel 6.18.4 (Fedora 43):
- Unassociated: Uses regulatory max for reporting
- Associated (5GHz 80MHz): User values honored correctly
- Firmware txpower_sku debugfs unchanged
Lucid Duck (3):
wifi: mt76: update timer APIs for kernel 6.18
wifi: mt76: mt7921: convert to MLO callbacks and fix txpower reporting
wifi: mt76: connac: preserve txpower_cur in set_rate_txpower
mt76.h | 1 +
mt7615/main.c | 6 ++--
mt7615/pci_mac.c | 4 +--
mt7615/usb.c | 2 +-
mt76_connac_mcu.c | 13 ++++++-
mt76x0/eeprom.c | 2 +-
mt76x02_eeprom.c | 2 +-
mt76x02_usb_core.c | 4 +--
mt76x2/eeprom.c | 2 +-
mt7921/main.c | 84 +++++++++++++++++++++++++++++++++++-----------
mt7925/main.c | 4 +--
mt792x_core.c | 6 ++--
12 files changed, 93 insertions(+), 37 deletions(-)
--
2.52.0
^ permalink raw reply
* Re: [PATCH v2 04/14] wifi: ath10k: snoc: support powering on the device via pwrseq
From: Jeff Johnson @ 2026-01-15 22:30 UTC (permalink / raw)
To: Dmitry Baryshkov, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Jeff Johnson,
Bjorn Andersson, Konrad Dybcio, Manivannan Sadhasivam, Vinod Koul,
Balakrishna Godavarthi, Matthias Kaehlcke
Cc: linux-arm-msm, linux-kernel, devicetree, linux-bluetooth,
linux-wireless, ath10k, linux-pm, Krzysztof Kozlowski,
Bartosz Golaszewski
In-Reply-To: <20260106-wcn3990-pwrctl-v2-4-0386204328be@oss.qualcomm.com>
On 1/5/2026 5:01 PM, Dmitry Baryshkov wrote:
> The WCN39xx family of WiFi/BT chips incorporates a simple PMU, spreading
> voltages over internal rails. Implement support for using powersequencer
> for this family of ATH10k devices in addition to using regulators.
>
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath10k/snoc.c | 54 ++++++++++++++++++++++++++++++++--
> drivers/net/wireless/ath/ath10k/snoc.h | 2 ++
My automation flagged:
* drivers/net/wireless/ath/ath10k/snoc.c has no QTI copyright
* drivers/net/wireless/ath/ath10k/snoc.h has no QTI copyright
* 2 copyright issues
I'll add these manually in my 'pending' branch
/jeff
^ permalink raw reply
* Re: (subset) [PATCH v2 00/14] power: sequencing: extend WCN driver to support WCN399x device
From: Bjorn Andersson @ 2026-01-15 21:03 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Jeff Johnson, Konrad Dybcio,
Manivannan Sadhasivam, Vinod Koul, Balakrishna Godavarthi,
Matthias Kaehlcke, Dmitry Baryshkov
Cc: linux-arm-msm, linux-kernel, devicetree, linux-bluetooth,
linux-wireless, ath10k, linux-pm, Krzysztof Kozlowski,
Bartosz Golaszewski, Konrad Dybcio
In-Reply-To: <20260106-wcn3990-pwrctl-v2-0-0386204328be@oss.qualcomm.com>
On Tue, 06 Jan 2026 03:01:10 +0200, Dmitry Baryshkov wrote:
> Qualcomm WCN3950, WCN3988 and WCN399x families of WiFi/BT chips preceed
> the later WCN / QCA devices, but they still incorporate a very simple
> PMU on die. It controls internal on-chip power networks, but, most
> importantly, it also requires a certain start-up procedure (first bring
> up VDD_IO, then bring up other voltages). In order to further unify code
> supporting different families of QCA / WCN chips and in order to
> maintain the required power up sequence, properly represent these chips
> in DTs and modify drivers to use power sequencing for these chips.
>
> [...]
Applied, thanks!
[06/14] arm64: dts: qcom: qrb4210-rb2: Fix UART3 wakeup IRQ storm
commit: c5dc4812f6bf397b82290c540085e9ec98b47b30
[07/14] arm64: dts: qcom: sdm845-db845c: drop CS from SPIO0
commit: 8bfb696ccdc5bcfad7a45b84c2c8a36757070e19
[08/14] arm64: dts: qcom: sdm845-db845c: specify power for WiFi CH1
commit: c303e89f7f17c29981d09f8beaaf60937ae8b1f2
[09/14] arm64: dts: qcom: sm8150: add uart13
commit: 0404b98c6bbca7a3b1e59a20d173fa149ac20194
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH wireless-next v2 00/34] wifi: inffmac: introducing a driver for Infineon's new generation chipsets
From: Marek Vasut @ 2026-01-15 17:27 UTC (permalink / raw)
To: Gokul Sivakumar
Cc: linux-wireless, Johannes Berg, Arend van Spriel,
wlan-kernel-dev-list
In-Reply-To: <aWdP6chPOS0PV-Nc@ISCN5CG14747PP.infineon.com>
On 1/14/26 9:12 AM, Gokul Sivakumar wrote:
> On 01/14, Marek Vasut wrote:
>> On 1/13/26 9:33 PM, Gokul Sivakumar wrote:
>>> Infineon(Cypress) is introducing a new INFFMAC (WLAN FULLMAC) Linux driver
>>> specifically for its new-generation AIROC family of Wi-Fi Connectivity
>>> Processor (CP) chipsets (CYW5591x), Wi-Fi + Bluetooth combo chipsets
>>> (CYW5557x, CYW5551x, CYW5591x, CYW43022), and also for all future chipsets.
>> Support for the CYW55572 can be easily added into the existing brcmfmac
>> driver, I already posted a patch over a year ago [1], but it was blocked
>> by an off-list email.
>
>> Frankly, I do not see any good reason why the brcmfmac driver shouldn't
>> be extended when it is clearly easily doable. Adding new fork of the
>> brcmfmac would only increase maintenance burden and prevent bugfixes
>> from reaching the brcmfmac.
>>
>> [1] https://lore.kernel.org/all/20240909203133.74777-2-marex@denx.de/
>
> There are multiple reasons behind Infineon's proposal for this new INFFMAC
> driver for its new-generation chips. Sharing a few here, and more info
> is available in the v1 cover-letter [1]. For Example, the CYW5591x family
> chipsets that is currently supported in this INFFMAC driver has a unique
> Connected-MCU / Connectivtiy Processor (CP) Architecture [2], primarly
> intended for IoT applications and it is completely different from any of
> the legacy Broadcom architecture chipsets of Infineon supported currently
> in upstream BRCMFMAC.
This does not prevent them from being integrated in brcmfmac like many
of the other already supported chips, there seems to be no technical
reason here.
> The CYW5591x family chipsets has dedicated MCU Core
> in addition to the WLAN core and an onboard FLASH memory for the Firmware.
It seems all brcmfmac devices have a cortex-M core in them since a long
time.
> And with respect to the support for the new-generation CYW5557x family of
> Secure chipsets, that requires a Secure boot handshake with the Bootloader.
It seems like the TRX firmware loading is trivial to add, and parts of
it are already in the Linux kernel for other brcm components. It seems
this TRX was used since old broadcom MIPS SoCs.
> Even if the enumeration and firmware download support for the CYW55572 is
> somehow retro-fitted into the existing upstream BRCMFMAC driver, there are
> multiple other features and aspects of the Driver-Device communication that
> are unique to each WLAN vendor, which are not always practically feasible
> to support in the same upstream driver.
Why ?
> Because currently BRCMFMAC driver
> has a shared ownership with more than 3 WLAN vendor organizations and this
> approach has its limitations.
Yes, this means it is necessary to cooperate and coordinate with other
people, on the mailing list.
> For Example, the version of the PCIe and SDIO
> BUS specific shared info in Device Memory is expected same from chipsets
> from all vendors. There would be a complex need to maintain vendor specifc
> as well as BUS specific Shared info version, vendor specific BUS Protocol
> layers, vendor specific firmware event header OUIs (currently always expects
> BRCM OUI even from other vendor chips) and even more.
This sounds like code refactoring is necessary.
> Confining different architecture chips from different WLAN vendors into the
> same legacy BRCMFMAC driver codebase, may not be sustainable and could
> potentially increase the maintainence effort and codebase complexity.
> And not practically feasible to continue splitting this driver with more
> vendor specific checks in the longer run. Since being different vendors,
> each will only naturally diverge even more in the future with their chipset
> Architecture, Driver-Device communication flow, etc. Infineon will continue
> to support its legacy chipsets, already supported in the upstream BRCMFMAC.
Maybe all the extra functionality can be added later, and the driver can
be forked later, when it becomes clear that refactoring is not an option
and it is becoming too difficult to maintain ?
So far, it seems the current generation chips can be easily added to
brcmfmac, even if the feature set would be limited. Adding them would
allow the maintainers to review such a smaller patchset and get at least
some hardware support in, step by step, instead of this mega-patchset.
^ permalink raw reply
* [PATCH] wifi: iwlwifi: ptp: Fix potential race condition in PTP removal
From: Junjie Cao @ 2026-01-15 16:15 UTC (permalink / raw)
To: Miri Korenblit, Johannes Berg, linux-wireless, Richard Cochran
Cc: Simon Horman, netdev, linux-kernel, Yedidya Benshimol,
Avraham Stern, Daniel Gabay, Krishnanand Prabhu, Luca Coelho,
Gregory Greenman, stable
iwl_mvm_ptp_remove() and iwl_mld_ptp_remove() call
cancel_delayed_work_sync() only after ptp_clock_unregister() and after
partially clearing ptp_data state.
This creates a race where the delayed work (iwl_mvm_ptp_work /
iwl_mld_ptp_work) can run while teardown is in progress and observe a
partially modified PTP state. In addition, the work may re-arm itself,
extending the teardown window and risking execution after driver
resources have been released.
Move cancel_delayed_work_sync() before ptp_clock_unregister() to ensure
the delayed work is fully stopped before any PTP cleanup begins. This
follows the standard pattern used by other Intel PTP drivers such as
e1000e, igb, ixgbe, and ice.
Fixes: d1e879ec600f ("wifi: iwlwifi: add iwlmld sub-driver")
Fixes: 1595ecce1cf3 ("wifi: iwlwifi: mvm: add support for PTP HW clock (PHC)")
Cc: stable@vger.kernel.org
Signed-off-by: Junjie Cao <junjie.cao@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mld/ptp.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/ptp.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/ptp.c b/drivers/net/wireless/intel/iwlwifi/mld/ptp.c
index 231920425c06..b40182320801 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/ptp.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/ptp.c
@@ -319,10 +319,10 @@ void iwl_mld_ptp_remove(struct iwl_mld *mld)
mld->ptp_data.ptp_clock_info.name,
ptp_clock_index(mld->ptp_data.ptp_clock));
+ cancel_delayed_work_sync(&mld->ptp_data.dwork);
ptp_clock_unregister(mld->ptp_data.ptp_clock);
mld->ptp_data.ptp_clock = NULL;
mld->ptp_data.last_gp2 = 0;
mld->ptp_data.wrap_counter = 0;
- cancel_delayed_work_sync(&mld->ptp_data.dwork);
}
}
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/ptp.c b/drivers/net/wireless/intel/iwlwifi/mvm/ptp.c
index 1da6260e238c..2b01ca36a1b5 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/ptp.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/ptp.c
@@ -325,11 +325,11 @@ void iwl_mvm_ptp_remove(struct iwl_mvm *mvm)
mvm->ptp_data.ptp_clock_info.name,
ptp_clock_index(mvm->ptp_data.ptp_clock));
+ cancel_delayed_work_sync(&mvm->ptp_data.dwork);
ptp_clock_unregister(mvm->ptp_data.ptp_clock);
mvm->ptp_data.ptp_clock = NULL;
memset(&mvm->ptp_data.ptp_clock_info, 0,
sizeof(mvm->ptp_data.ptp_clock_info));
mvm->ptp_data.last_gp2 = 0;
- cancel_delayed_work_sync(&mvm->ptp_data.dwork);
}
}
--
2.43.0
^ permalink raw reply related
* pull request: iwlwifi firmware update 2026-01-15
From: Korenblit, Miriam Rachel @ 2026-01-15 14:59 UTC (permalink / raw)
To: linux-firmware@kernel.org
Cc: linux-firmware@kernel.org, kyle@infradead.org, Hutchings, Ben,
Dreyfuss, Haim, Yang, You-Sheng, Linux Wireless
Hi,
This contains the firmware of core102 for all our supported devices
Please pull or let me know if there are any issues.
Thanks,
Miri
---
The following changes since commit e477bd5942f436029cee23a9c4cfec2ea36e38c0:
Merge branch 'intel/ptl_gsc_105.0.2.1301' into 'main' (2026-01-14 12:11:48 +0000)
are available in the Git repository at:
http://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git tags/iwlwifi-fw-2026-01-15
for you to fetch changes up to 9a9285ce9b440c4d0d6d9aeff181615d8052dfe7:
iwlwifi: add Bz/Sc FW for core102-56 release (2026-01-15 16:51:42 +0200)
----------------------------------------------------------------
Relase core 102-56
----------------------------------------------------------------
Miri Korenblit (3):
iwlwifi: update ty/So/Ma firmwares for core102-56 release
iwlwifi: Add Hr/Gf firmware for core102-56 release
iwlwifi: add Bz/Sc FW for core102-56 release
WHENCE | 36 +++++++++++++++++++--------
intel/iwlwifi/iwlwifi-bz-b0-fm-c0-c102.ucode | Bin 0 -> 2244684 bytes
intel/iwlwifi/iwlwifi-bz-b0-gf-a0-100.ucode | Bin 1836712 -> 1837172 bytes
intel/iwlwifi/iwlwifi-bz-b0-hr-b0-100.ucode | Bin 1584620 -> 1584684 bytes
intel/iwlwifi/iwlwifi-gl-c0-fm-c0-c102.ucode | Bin 0 -> 2223328 bytes
intel/iwlwifi/iwlwifi-ma-b0-gf-a0-89.ucode | Bin 1752580 -> 1752652 bytes
intel/iwlwifi/iwlwifi-ma-b0-gf-a0.pnvm | Bin 55096 -> 55096 bytes
intel/iwlwifi/iwlwifi-ma-b0-gf4-a0-89.ucode | Bin 1604620 -> 1604692 bytes
intel/iwlwifi/iwlwifi-ma-b0-gf4-a0.pnvm | Bin 27820 -> 27820 bytes
intel/iwlwifi/iwlwifi-ma-b0-hr-b0-89.ucode | Bin 1539788 -> 1539788 bytes
intel/iwlwifi/iwlwifi-sc-a0-fm-c0-c102.ucode | Bin 0 -> 2311660 bytes
intel/iwlwifi/iwlwifi-sc-a0-gf-a0-100.ucode | Bin 1810548 -> 1810848 bytes
intel/iwlwifi/iwlwifi-sc-a0-wh-b0-c102.ucode | Bin 0 -> 2214468 bytes
intel/iwlwifi/iwlwifi-so-a0-gf-a0-89.ucode | Bin 1736616 -> 1736688 bytes
intel/iwlwifi/iwlwifi-so-a0-gf-a0.pnvm | Bin 55176 -> 55176 bytes
intel/iwlwifi/iwlwifi-so-a0-gf4-a0-89.ucode | Bin 1591588 -> 1591660 bytes
intel/iwlwifi/iwlwifi-so-a0-gf4-a0.pnvm | Bin 27860 -> 27860 bytes
intel/iwlwifi/iwlwifi-so-a0-hr-b0-89.ucode | Bin 1526956 -> 1526956 bytes
intel/iwlwifi/iwlwifi-ty-a0-gf-a0-89.ucode | Bin 1678684 -> 1678756 bytes
intel/iwlwifi/iwlwifi-ty-a0-gf-a0.pnvm | Bin 55020 -> 55020 bytes
20 files changed, 26 insertions(+), 10 deletions(-)
create mode 100644 intel/iwlwifi/iwlwifi-bz-b0-fm-c0-c102.ucode
create mode 100644 intel/iwlwifi/iwlwifi-gl-c0-fm-c0-c102.ucode
create mode 100644 intel/iwlwifi/iwlwifi-sc-a0-fm-c0-c102.ucode
create mode 100644 intel/iwlwifi/iwlwifi-sc-a0-wh-b0-c102.ucode
^ permalink raw reply
* Re: [DESIGN RFC v3] AP Architecture for Wi-Fi-8 Multi-AP Coordination (MAPC)
From: Johannes Berg @ 2026-01-15 14:17 UTC (permalink / raw)
To: Jeff Johnson, Abhishek Rajkapur Suryawanshi, ath12k, hostap
Cc: linux-wireless
In-Reply-To: <63ff0362-4ee4-4f13-a212-dc1351eefe08@oss.qualcomm.com>
On Wed, 2026-01-14 at 11:15 -0800, Jeff Johnson wrote:
> On 1/12/2026 11:18 AM, Johannes Berg wrote:
> > On Mon, 2026-01-12 at 20:12 +0100, Johannes Berg wrote:
> > >
> > > Why do you always want to let firmware be in control of everything?
> > > Seems at least for some of this you'd really want the upper layers to
> > > control it for purposes of coordination? How does the FW even know which
> > > other AP it can coordinate with, isn't that something a network
> > > controller would determine?
> >
> > A less generous reading of this could be: you guys want everything to be
> > controlled by FW, so you don't have to open-source it in hostapd. Now
> > you realize oops, don't really want to do all the security handshake in
> > FW, so we need to ask hostapd and then we need keys and stations and all
> > this stuff. So let's build something nobody else can use, upstream it
> > and we get the best of both worlds - others will maintain the mac80211
> > code for us anyway.
> >
> > Am I wrong? Is there a technical reason for not simply doing MAPC
> > discovery/agreement negotiation etc. in hostapd as well, based on
> > driver/hw/fw capabilities, and then you don't need all these strange
> > "triggered by firmware" flows?
>
> My perception is that Qualcomm would love for all the Wi-Fi 8 functionality to
> be in userspace and nl/cfg/mac80211 since then there would be no code
> maintenance overhead on our part -- just you and the userspace maintainers.
:)
> But there are concerns about latency, and internal consensus is that some
> aspects of this functionality has to be handled in firmware (or even hardware)
> in order to meet customer KPIs. This comes from our history of supporting
> large-scale deployments of APs, and the expectations of how Wi-Fi 8 will make
> things better. That is why we are posting design RFCs, so that you, as well as
> engineers from other vendors, can review our proposals and give your feedback
> and counter-proposals. We want to avoid developing what might be an
> architecturally pure design that doesn't actually meet customer needs.
Sure, that's fair.
Maybe I can just ask folks to spell out the constraints and reasoning
behind the design?
Taking this specific example, it basically says "FW sends a request to
hostapd, hostapd does the handshake and installs the MAPC station. This
is how we think we should handle the MAPC stations."
It never says _why_ and how any of this happens. What's the magic thing
only the firmware can do to figure out it should start coordinating a
given AP? (Clearly that operation can't be concerned much about latency
if it asks hostapd.)
In fact I'd have expected that in certain cases some controller
infrastructure sitting *on top of hostapd* would decide which APs
coordinate with each other, rather than the firmware. Although I guess
if you hear the beacon on the same channel with a good enough RSSI then
you can coordinate.
I could keep guessing - maybe there's a limited space to do this in FW?
But there's not even anything built into the design where the firmware
can ask to _remove_ it again, as far as I can tell, unless there was an
(unstated) assumption that it can just delete the MAPC station and send
a DEL_STATION notification about it.
The document even says that phase 1 is discovery, and then goes to
completely ignore phase 1 (it's hidden in FW), and describes basically
only phase 2.
> And apologies for the "firehose" of both design and code, but we have a desire
> to ship Wi-Fi 8 products using upstream code. I've passed along information
> that you want our engineering team to focus on the base NPCA patches so that
> there is the appropriate foundation. But in parallel we do also hope there is
> engagement from other vendors on the Design RFCs we are posting. Our goal is
> to upstream as much AP functionality as you can absorb.
Sure, and I appreciate that this is coming. I'm a little overwhelmed by
having so many parallel things going on right now, and all the parallel
design documents don't help.
Maybe this is the point where we consider inviting everyone who wants to
a room for a few days? Even a video room might be better ;-) List some
topics first, present the design briefly, etc.? But I don't know if it's
just the medium.
johannes
^ permalink raw reply
* Re: [PATCH v2 1/3] sdio: Provide a bustype shutdown function
From: Uwe Kleine-König @ 2026-01-15 8:23 UTC (permalink / raw)
To: Shawn Lin, Ulf Hansson, Johannes Berg
Cc: linux-wireless, linux-mmc, Ping-Ke Shih
In-Reply-To: <ee62632a-34cb-494a-ad87-bd18a58d6a7c@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]
On Thu, Jan 15, 2026 at 09:26:21AM +0800, Shawn Lin wrote:
> 在 2026/01/12 星期一 23:46, Uwe Kleine-König 写道:
> > To prepare sdio drivers to migrate away from struct device_driver::shutdown
> > (and then eventually remove that callback) create a serdev driver shutdown
>
> /s/serdev driver/sdio driver ?
Oh, indeed. Thanks for catching that.
> > callback and migration code to keep the existing behaviour. Note this
> > introduces a warning for each driver that isn't converted yet to that
> > callback at register time.
> >
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> > ---
> > drivers/mmc/core/sdio_bus.c | 25 +++++++++++++++++++++++++
> > include/linux/mmc/sdio_func.h | 1 +
> > 2 files changed, 26 insertions(+)
> >
> > diff --git a/drivers/mmc/core/sdio_bus.c b/drivers/mmc/core/sdio_bus.c
> > index 10799772494a..6e5bdc2f0cc8 100644
> > --- a/drivers/mmc/core/sdio_bus.c
> > +++ b/drivers/mmc/core/sdio_bus.c
> > @@ -232,6 +232,15 @@ static void sdio_bus_remove(struct device *dev)
> > pm_runtime_put_sync(dev);
> > }
> > +static void sdio_bus_shutdown(struct device *dev)
> > +{
> > + struct sdio_driver *drv = to_sdio_driver(dev->driver);
> > + struct sdio_func *func = dev_to_sdio_func(dev);
> > +
> > + if (dev->driver && drv->shutdown)
> > + drv->shutdown(func);
> > +}
>
> Seem bogus check as a few line ahead, you used dev->driver to get
> sdio_driver already. Otherwise the reset looks good.
to_sdio_driver(dev->driver) however is only pointer arithmetic and
doesn't dereference the pointer. So this is not a bug in the class
check-for-NULL-after-dereference. TTBOMY the code if fine as is.
Should I resend for the typo, or can this be fixed up while applying?
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] wifi: ath: fix comment typo in monitor mode handling
From: Chien Wong @ 2026-01-15 8:20 UTC (permalink / raw)
To: Jeff Johnson, Chien Wong, 'ath11k@lists.infradead.org'
Cc: linux-wireless
In-Reply-To: <a47cfe9f-01eb-4cdd-ac97-421f3c8a3451@oss.qualcomm.com>
On Thu Jan 15, 2026 at 12:34 AM CST, Jeff Johnson wrote:
> On 10/30/2025 7:30 AM, Chien Wong wrote:
>
> Subject should have use "ath11k:"
> I'll fix this in my pending branch
>
> And I've removed the ath12k list and added the ath11k list
>
>> Correct a typo in the monitor mode comment where "it make" was mistakenly
>> used instead of "it doesn't make". The comment explains that the brief
>> period where monitor mode appears enabled before being removed is harmless
>> in practice.
>> Also, use more common phrase "in practice" instead of "in practise".
>>
>> Fixes: 3f6e6c3291ed ("ath11k: disable monitor mode on QCA6390")
>> Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
>
> And I'll drop the Fixes tags since there is no code change and hence no need
> to backport this change to stable kernels.
>
As a newbie in kernel development, I now understand the use of Fixes tag.
Thank you.
Regards,
Chien Wong
^ permalink raw reply
* Re: [PATCH] wifi: mt76: mt792x: fix firmware reload failure after previous load crash
From: Zac Bowling @ 2026-01-15 7:19 UTC (permalink / raw)
To: Sean Wang, linux
Cc: deren.wu, kvalo, linux-kernel, linux-mediatek, linux-wireless,
lorenzo, nbd, ryder.lee, sean.wang
In-Reply-To: <CAOFcj8Qy=6gpKpkph_rj8Nyc82t_q87XM8B3hhmX0Rijv-FxeQ@mail.gmail.com>
While I'm still waiting for feedback from folks on these patches, I've
set up a public repository with all the fixes for others experiencing
these issues and created a DKMS package for folks so they can easily
load these patches as an alternative driver since so many folks are
running into these same problems on several popular commercial laptops
and desktops:
https://github.com/zbowling/mt7925
The repository has:
- All 18 patches from this series I've sent here (different versions
of these patches that apply cleanly to different kernel versions)
- Pre-patched kernel branches (6.17.x, 6.18.x, 6.19-rc5) in another
repo linked in the README
- A new DKMS package for out-of-tree builds (requires kernel 6.17+)
with various hacks with #ifdef kernel versions so that the single
package works for all recent kernels.
The DKMS package builds mt76, mt76-connac-lib, mt792x-lib,
mt7925-common, and mt7925e modules with all fixes applied.
Testing in the community with everyone experiencing these same panics
in the current upstream version, I've heard feedback from many folks
that this patch series (either just apply the patches or using the
DKMS build) that this fixes most of their issues.
There still seems to be ongoing issues inside the firmware related to
MLO and deauths with certain APs (especially with my Unifi U7 Pros)
but at least this keeps machines from crashing while it the chip
resets so you only suffer momentary losses in connectivity instead of
straight-up kernel panic or a deadlock.
For anyone still hitting the NULL pointer dereferences, mutex
deadlocks with NetworkManager and friends during MLO and deauth
situations, or suspend/resume hangs with mt7925 - this DMKS package or
these patches should greatly help.
Happy to address any review feedback whenever you finally have a
chance to look at these.
Zac Bowling
On Sat, Jan 3, 2026 at 10:42 AM Zac Bowling <zbowling@gmail.com> wrote:
>
> Hi Sean,
>
> Thanks! I don't have a MT7921, only a MT7925, so no unfortunately. I
> ordered off Amazon and should be here in a week or two.
>
> Zac Bowling
>
> Zac Bowling
>
>
> On Fri, Jan 2, 2026 at 10:46 PM Sean Wang <sean.wang@kernel.org> wrote:
> >
> > On Fri, Jan 2, 2026 at 2:03 PM Zac Bowling <zbowling@gmail.com> wrote:
> > >
> > > If the firmware loading process crashes or is interrupted after
> > > acquiring the patch semaphore but before releasing it, subsequent
> > > firmware load attempts will fail with 'Failed to get patch semaphore'
> > > because the semaphore is still held.
> > >
> > > This issue manifests as devices becoming unusable after suspend/resume
> > > failures or firmware crashes, requiring a full hardware reboot to
> > > recover. This has been widely reported on MT7921 and MT7925 devices.
> > >
> > > Apply the same fix that was applied to MT7915 in commit 79dd14f:
> > > 1. Release the patch semaphore before starting firmware load (in case
> > > it was held by a previous failed attempt)
> > > 2. Restart MCU firmware to ensure clean state
> > > 3. Wait briefly for MCU to be ready
> > >
> > > This fix applies to both MT7921 and MT7925 drivers which share the
> > > mt792x_load_firmware() function.
> > >
> > > Fixes: 'Failed to get patch semaphore' errors after firmware crash
> > > Signed-off-by: Zac Bowling <zac@zacbowling.com>
> > > ---
> > > mt792x_core.c | 14 ++++++++++++++
> > > 1 file changed, 14 insertions(+)
> > >
> > > diff --git a/mt792x_core.c b/mt792x_core.c
> > > index cc488ee9..b82e4470 100644
> > > --- a/mt792x_core.c
> > > +++ b/mt792x_core.c
> > > @@ -927,6 +927,20 @@ int mt792x_load_firmware(struct mt792x_dev *dev)
> > > {
> > > int ret;
> > >
> > > + /* Release semaphore if taken by previous failed load attempt.
> > > + * This prevents "Failed to get patch semaphore" errors when
> > > + * recovering from firmware crashes or suspend/resume failures.
> > > + */
> > > + ret = mt76_connac_mcu_patch_sem_ctrl(&dev->mt76, false);
> > > + if (ret < 0)
> > > + dev_dbg(dev->mt76.dev, "Semaphore release returned %d (may be expected)\n", ret);
> > > +
> > > + /* Always restart MCU to ensure clean state before loading firmware */
> > > + mt76_connac_mcu_restart(&dev->mt76);
> > > +
> > > + /* Wait for MCU to be ready after restart */
> > > + msleep(100);
> > > +
> >
> > Hi Zac,
> >
> > This is a good finding. Since this is a common mt792x code path, have you
> > also had a chance to test it on MT7921?
> >
> > One small nit: the Fixes tag should reference the actual commit being
> > fixed, e.g.
> >
> > Fixes: <commit-sha> ("mt76: mt792x: ...")
> >
> > instead of the error string.
> >
> > Sean
> >
> > > ret = mt76_connac2_load_patch(&dev->mt76, mt792x_patch_name(dev));
> > > if (ret)
> > > return ret;
> > > --
> > > 2.51.0
> > >
> > >
> > >
^ permalink raw reply
* Re: [PATCH v3] wifi: ath11k: move .max_tx_ring to struct ath11k_hw_hal_params
From: Alex G. @ 2026-01-15 4:43 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan, jjohnson, ath11k, Jeff Johnson
Cc: baochen.qiang, linux-wireless, linux-kernel
In-Reply-To: <89a61ef1-3e83-4303-ba04-cf5c5a4aae56@oss.qualcomm.com>
On Wednesday, January 14, 2026 3:59:09 PM CST Jeff Johnson wrote:
> On 1/14/2026 1:29 PM, Alex G. wrote:
> > On Wednesday, January 14, 2026 11:24:19 AM CST Jeff Johnson wrote:
> >> On 1/12/2026 11:00 PM, Vasanthakumar Thiagarajan wrote:
> >>> On 12/28/2025 8:44 PM, Alexandru Gagniuc wrote:
> >>>> ".max_tx_ring" is an upper bounds to indexing ".tcl2wbm_rbm_map". It
> >>>> is initialized in, core.c, a different file than the array. This
> >>>> spaghetti-like relation is fragile and not obvious. Accidentally
> >>>> setting ".max_tx_ring" too high leads to a hard to track out-of-
> >>>> bounds access and memory corruption.
> >>>>
> >>>> There is a small ambiguity on the meaning of "max_tx_ring":
> >>>> - The highest ring, max=3 implies there are 4 rings (0, 1, 2, 3)
> >>>> - The highest number to use for array indexing (there are 3 rings)
> >>>>
> >>>> Clarify this dependency by moving ".max_tx_ring" adjacent to the array
> >>>> ".tcl2wbm_rbm_map", and name it "num_tx_rings". Use ARRAY_SIZE()
> >>>> instead of #defines to initialize the length field.
> >>>>
> >>>> The ath11k_hw_hal_params_qca6390 uses fewer num_tx_rings than its map,
> >>>> so use a constant to express the correct value. Add a static_assert()
> >>>> to fail compilation if the constant is accidentally set too high.
> >>>
> >>> Text related to static_assert to be removed accordingly.
> >
> > Hi Jeff,
> >
> >> I removed the last sentence in 'pending', please check:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/commit/?h=pen
> >> din g&id=26bb149b5e011b0f73f7b74421589cbd38e3304b
> >
> > Re-reading the commit message, I think it makes sense to also remove the
> > sentence "The ath11k_hw_hal_params_qca6390 uses fewer num_tx_rings than
> > its
> > map, so use a constant to express the correct value.". Do you think it's
> > worth submitting a v4 with this minor change?
> >
> > Alex
>
> No need to submit a v4. I can make that change in 'pending'
Thank you!
> /jeff
^ 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