* [PATCH 5/5] wifi: mt76: mt7996: fix queue pause after scan due to wrong channel switch reason
From: Shayne Chen @ 2026-02-02 7:53 UTC (permalink / raw)
To: Felix Fietkau
Cc: linux-wireless, Lorenzo Bianconi, Ryder Lee, Evelyn Tsai,
Money Wang, linux-mediatek, StanleyYP Wang, Shayne Chen
In-Reply-To: <20260202075311.365673-1-shayne.chen@mediatek.com>
From: StanleyYP Wang <StanleyYP.Wang@mediatek.com>
Previously, we use the IEEE80211_CONF_IDLE flag to avoid setting the
parking channel with the CH_SWITCH_NORMAL reason, which could trigger TX
emission before bootup CAC.
However, we found that this flag can be set after triggering scanning on a
connected station interface, and the reason CH_SWITCH_SCAN_BYPASS_DPD will
be used when switching back to the operating channel, which makes the
firmware failed to resume paused AC queues.
Seems that we should avoid relying on this flag after switching to single
multi-radio architecture. Instead, replace it with MT76_STATE_RUNNING.
Signed-off-by: StanleyYP Wang <StanleyYP.Wang@mediatek.com>
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
---
drivers/net/wireless/mediatek/mt76/mt7996/mcu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c
index 68d698033e43..1d5ea28e7b9b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c
@@ -3925,7 +3925,7 @@ int mt7996_mcu_set_chan_info(struct mt7996_phy *phy, u16 tag)
if (phy->mt76->hw->conf.flags & IEEE80211_CONF_MONITOR)
req.switch_reason = CH_SWITCH_NORMAL;
else if (phy->mt76->offchannel ||
- phy->mt76->hw->conf.flags & IEEE80211_CONF_IDLE)
+ !test_bit(MT76_STATE_RUNNING, &phy->mt76->state))
req.switch_reason = CH_SWITCH_SCAN_BYPASS_DPD;
else if (!cfg80211_reg_can_beacon(phy->mt76->hw->wiphy, chandef,
NL80211_IFTYPE_AP))
--
2.51.0
^ permalink raw reply related
* [PATCH 2/5] wifi: mt76: mt7996: fix wrong DMAD length when using MAC TXP
From: Shayne Chen @ 2026-02-02 7:53 UTC (permalink / raw)
To: Felix Fietkau
Cc: linux-wireless, Lorenzo Bianconi, Ryder Lee, Evelyn Tsai,
Money Wang, linux-mediatek, Shayne Chen
In-Reply-To: <20260202075311.365673-1-shayne.chen@mediatek.com>
The struct mt76_connac_fw_txp is used for HIF TXP. Change to use the
struct mt76_connac_hw_txp to fix the wrong DMAD length for MAC TXP.
Fixes: cb6ebbdffef2 ("wifi: mt76: mt7996: support writing MAC TXD for AddBA Request")
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
---
drivers/net/wireless/mediatek/mt76/mt7996/mac.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
index 77a036ac043c..3b09eff216c3 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
@@ -1099,10 +1099,10 @@ int mt7996_tx_prepare_skb(struct mt76_dev *mdev, void *txwi_ptr,
* req
*/
if (le32_to_cpu(ptr[7]) & MT_TXD7_MAC_TXD) {
- u32 val;
+ u32 val, mac_txp_size = sizeof(struct mt76_connac_hw_txp);
ptr = (__le32 *)(txwi + MT_TXD_SIZE);
- memset((void *)ptr, 0, sizeof(struct mt76_connac_fw_txp));
+ memset((void *)ptr, 0, mac_txp_size);
val = FIELD_PREP(MT_TXP0_TOKEN_ID0, id) |
MT_TXP0_TOKEN_ID0_VALID_MASK;
@@ -1121,6 +1121,8 @@ int mt7996_tx_prepare_skb(struct mt76_dev *mdev, void *txwi_ptr,
tx_info->buf[1].addr >> 32);
#endif
ptr[3] = cpu_to_le32(val);
+
+ tx_info->buf[0].len = MT_TXD_SIZE + mac_txp_size;
} else {
struct mt76_connac_txp_common *txp;
--
2.51.0
^ permalink raw reply related
* [PATCH 4/5] wifi: mt76: avoid to set ACK for MCU command if wait_resp is not set
From: Shayne Chen @ 2026-02-02 7:53 UTC (permalink / raw)
To: Felix Fietkau
Cc: linux-wireless, Lorenzo Bianconi, Ryder Lee, Evelyn Tsai,
Money Wang, linux-mediatek, StanleyYP Wang, Shayne Chen
In-Reply-To: <20260202075311.365673-1-shayne.chen@mediatek.com>
From: StanleyYP Wang <StanleyYP.Wang@mediatek.com>
When wait_resp is not set but the ACK option is enabled in the MCU TXD,
the ACK event is enqueued to the MCU event queue without being dequeued
by the original MCU command request.
Any orphaned ACK events will only be removed from the queue when another
MCU command requests a response. Due to sequence index mismatches, these
events are discarded one by one until a matching sequence index is found.
However, if several MCU commands that do not require a response continue
to fill up the event queue, there is a risk that when an MCU command with
wait_resp enabled is issued, it may dequeue the wrong event skb,
especially if the queue contains events with all possible sequence
indices.
Signed-off-by: StanleyYP Wang <StanleyYP.Wang@mediatek.com>
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
---
drivers/net/wireless/mediatek/mt76/mcu.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt7996/mcu.c | 11 +++++------
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mcu.c b/drivers/net/wireless/mediatek/mt76/mcu.c
index 535c3d8a9cc0..cbfb3bbec503 100644
--- a/drivers/net/wireless/mediatek/mt76/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mcu.c
@@ -98,7 +98,7 @@ int mt76_mcu_skb_send_and_get_msg(struct mt76_dev *dev, struct sk_buff *skb,
/* orig skb might be needed for retry, mcu_skb_send_msg consumes it */
if (orig_skb)
skb_get(orig_skb);
- ret = dev->mcu_ops->mcu_skb_send_msg(dev, skb, cmd, &seq);
+ ret = dev->mcu_ops->mcu_skb_send_msg(dev, skb, cmd, wait_resp ? &seq : NULL);
if (ret < 0)
goto out;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c
index 285cd83e7117..68d698033e43 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c
@@ -322,13 +322,12 @@ mt7996_mcu_send_message(struct mt76_dev *mdev, struct sk_buff *skb,
uni_txd->pkt_type = MCU_PKT_ID;
uni_txd->seq = seq;
- if (cmd & __MCU_CMD_FIELD_QUERY)
- uni_txd->option = MCU_CMD_UNI_QUERY_ACK;
- else
- uni_txd->option = MCU_CMD_UNI_EXT_ACK;
+ uni_txd->option = MCU_CMD_UNI;
+ if (!(cmd & __MCU_CMD_FIELD_QUERY))
+ uni_txd->option |= MCU_CMD_SET;
- if (mcu_cmd == MCU_UNI_CMD_SDO)
- uni_txd->option &= ~MCU_CMD_ACK;
+ if (wait_seq)
+ uni_txd->option |= MCU_CMD_ACK;
if ((cmd & __MCU_CMD_FIELD_WA) && (cmd & __MCU_CMD_FIELD_WM))
uni_txd->s2d_index = MCU_S2D_H2CN;
--
2.51.0
^ permalink raw reply related
* [PATCH 3/5] wifi: mt76: mt7996: fix struct mt7996_mcu_uni_event
From: Shayne Chen @ 2026-02-02 7:53 UTC (permalink / raw)
To: Felix Fietkau
Cc: linux-wireless, Lorenzo Bianconi, Ryder Lee, Evelyn Tsai,
Money Wang, linux-mediatek, StanleyYP Wang, Shayne Chen
In-Reply-To: <20260202075311.365673-1-shayne.chen@mediatek.com>
From: StanleyYP Wang <StanleyYP.Wang@mediatek.com>
The cid field is defined as a two-byte value in the firmware.
Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
Signed-off-by: StanleyYP Wang <StanleyYP.Wang@mediatek.com>
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
---
drivers/net/wireless/mediatek/mt76/mt7996/mcu.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt7996/mcu.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c
index 8e1c8e1d6a99..285cd83e7117 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c
@@ -242,7 +242,7 @@ mt7996_mcu_parse_response(struct mt76_dev *mdev, int cmd,
event = (struct mt7996_mcu_uni_event *)skb->data;
ret = le32_to_cpu(event->status);
/* skip invalid event */
- if (mcu_cmd != event->cid)
+ if (mcu_cmd != le16_to_cpu(event->cid))
ret = -EAGAIN;
} else {
skb_pull(skb, sizeof(struct mt7996_mcu_rxd));
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.h b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.h
index d9fb49f7b01b..d70540982983 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.h
@@ -25,8 +25,8 @@ struct mt7996_mcu_rxd {
};
struct mt7996_mcu_uni_event {
- u8 cid;
- u8 __rsv[3];
+ __le16 cid;
+ u8 __rsv[2];
__le32 status; /* 0: success, others: fail */
} __packed;
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v2] wifi: mt76: fix backoff fields and max_power calculation
From: Sven Eckelmann @ 2026-02-02 8:14 UTC (permalink / raw)
To: Ryder Lee, Rob Herring
Cc: Felix Fietkau, linux-wireless, linux-mediatek, Allen Ye,
Saravana Kannan
In-Reply-To: <54627282cfb8e5a89fe753da66552c0a084f6387.1769557863.git.ryder.lee@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]
On Wednesday, 28 January 2026 00:55:57 CET Ryder Lee wrote:
> + case MT76_SKU_BACKOFF:
> + backoff_chain_idx += 1;
> + fallthrough;
> + case MT76_SKU_BACKOFF_BF_OFFSET:
> + 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:
Please double check whether the "case"s for MT76_SKU_BACKOFF_BF_OFFSET and
MT76_SKU_BACKOFF should actually be swapped. I think I've originally
introduced this mistake when trying to demonstrate different ways to write the
switch block.
> + /* For connac2 devices,
> + * - paths-ru = RU26, RU52, RU106, BW20, BW40, BW80, BW160
> + * - paths-ru-bf = RU26, RU52, RU106, BW20, BW40, BW80, BW160
> + * Only the first three entries use 1T1ss and do not need index
> + * adjustment; the remaining four require index offset.
> + */
Hm, I doubt that anyone can understand this (same for the commit message).
You basically just showed a list of two equal "array"s.
Actually important here is that, RU26, RU52, RU106, ... stand here for 10
different values:
1T1ss, 2T1ss, 3T1ss, 4T1ss, 2T2ss, 3T2ss, 4T2ss, 3T3ss, 4T3ss, 4T4ss
For paths-ru-bf, also 10 values are stored in the DT for each of these
(RU26, ..., BW160) - but only the non-1T1ss are relevant for this
calculation for BW20, ..., BW160.
These 1T1ss beamforming values for BW20, ..., BW160 were (if I understand it
correctly) removed for connac3.
If you introduce some change in the DT interpretation, then you must also
inform the DT maintainers (Rob Herring <robh@kernel.org>,
Saravana Kannan <saravanak@kernel.org>, devicetree@vger.kernel.org) while
updatingDocumentation/devicetree/bindings/net/wireless/mediatek%2Cmt76.yaml.
The latter is currently still expecting 1 ("rates multiplier") + 10 values
(limits). And DTs with only 1 + 9 values per rate would therefore fail to be
validated.
At the moment, your connac3 code is basically conflicting with the devicetree
documentation. I will leave it to the experts to figure out if the devicetree
should have two different interpretations for the same property or whether
the property should be the same and the code must handle the differences
before sending these values to the HW.
Regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH wireless-next v8 3/3] wifi: mac80211: add initial UHR support
From: Johannes Berg @ 2026-02-02 8:27 UTC (permalink / raw)
To: Pablo MARTIN-GOMEZ, linux-wireless
In-Reply-To: <009232c6-2a67-4df4-9309-71c9d5788c73@freebox.fr>
On Fri, 2026-01-30 at 19:29 +0100, Pablo MARTIN-GOMEZ wrote:
>
> > +void
> > +ieee80211_uhr_cap_ie_to_sta_uhr_cap(struct ieee80211_sub_if_data *sdata,
> > + struct ieee80211_supported_band *sband,
> > + const struct ieee80211_uhr_cap *uhr_cap,
> > + u8 uhr_cap_len,
> > + struct link_sta_info *link_sta)
> > +{
> > + struct ieee80211_sta_uhr_cap *sta_uhr_cap = &link_sta->pub->uhr_cap;
> > + bool from_ap;
> > +
> > + memset(sta_uhr_cap, 0, sizeof(*sta_uhr_cap));
> > +
> > + if (!ieee80211_get_uhr_iftype_cap_vif(sband, &sdata->vif))
> > + return;
> > +
> > + sta_uhr_cap->has_uhr = true;
> > +
> > + sta_uhr_cap->mac = uhr_cap->mac;
> > + from_ap = sdata->vif.type == NL80211_IFTYPE_STATION;
> My knowledge of mac80211 is quite limited so I might be very well wrong
> but it feels that either this is wrong and it should be `sdata->vif.type
> == NL80211_IFTYPE_AP`
If we _are_ the AP then we won't parse data coming _from_ the AP, so
it's correct.
> or this is correct but it won't work with mesh
> point for example and that `sdata->vif.type != NL80211_IFTYPE_AP` would
> be better.
Also no, according to the spec, I even quoted it the other day. But I
guess if someone wants UHR on mesh they have a bunch of work anyway, so
it doesn't even matter.
johannes
>
^ permalink raw reply
* Re: [PATCH 1/5] wifi: mt76: fix potential deadlock caused by rx_lock
From: Felix Fietkau @ 2026-02-02 8:52 UTC (permalink / raw)
To: Shayne Chen
Cc: linux-wireless, Lorenzo Bianconi, Ryder Lee, Evelyn Tsai,
Money Wang, linux-mediatek
In-Reply-To: <20260202075311.365673-1-shayne.chen@mediatek.com>
On 02.02.26 08:53, Shayne Chen wrote:
> A deadlock will occur if both of the following conditions are met,
> because they each attempt to acquire the rx_lock:
> - mac80211 receives an unexpected BAR control frame, which triggers
> a BA deletion
> - A transmission failure happens due to an abnormality in DMA
>
> Since ieee80211_tx_status_ext() is primarily used to address AQL issues,
> avoid potential deadlocks by restricting calls to ieee80211_tx_status_ext
> only for data frames.
First of all, ieee80211_tx_status_ext is not primarily used to address
AQL, ieee80211_free_txskb handles it as well. The reason for it is tx
status handling, e.g. for management frames sent by hostapd that require
an ACK status report, so limiting the status calls for data frames seems
wrong to me.
I don't really understand how the scenario you're describing leads to a
deadlock. From my understanding, if something in the mac80211 rx path
triggers a tx, it should end up calling mt76_tx(), which queues the skb
to wcid->tx_list and triggers the tx worker. So the actual dma tx callls
are expected to come from the worker kthread.
How does this lead to a deadlock on rx_lock?
- Felix
^ permalink raw reply
* Re: [RFC v6 wireless-next 4/4] wifi: mac80211_hwsim: background CAC support
From: Johannes Berg @ 2026-02-02 8:55 UTC (permalink / raw)
To: Janusz Dziedzic, linux-wireless
In-Reply-To: <20260201161836.16506-5-janusz.dziedzic@gmail.com>
On Sun, 2026-02-01 at 17:15 +0100, Janusz Dziedzic wrote:
>
> +static bool background_radar = true;
> +module_param(background_radar, bool, 0444);
> +MODULE_PARM_DESC(background_radar, "Support background radar/CAC");
Do we need this as a module parameter? There's a general pushback
against those and while I guess it's not going to be _impossible_ for a
test tool, we are going to have to justify that...
Either way we should have a netlink parameter for it, which you didn't
add, but I think we can also just not have the module parameter then.
(Also, maybe at this point time to stop sending as RFC?)
johannes
^ permalink raw reply
* Re: [PATCH 5/5] wifi: mt76: mt7996: fix queue pause after scan due to wrong channel switch reason
From: Felix Fietkau @ 2026-02-02 9:01 UTC (permalink / raw)
To: Shayne Chen
Cc: linux-wireless, Lorenzo Bianconi, Ryder Lee, Evelyn Tsai,
Money Wang, linux-mediatek, StanleyYP Wang
In-Reply-To: <20260202075311.365673-5-shayne.chen@mediatek.com>
On 02.02.26 08:53, Shayne Chen wrote:
> From: StanleyYP Wang <StanleyYP.Wang@mediatek.com>
>
> Previously, we use the IEEE80211_CONF_IDLE flag to avoid setting the
> parking channel with the CH_SWITCH_NORMAL reason, which could trigger TX
> emission before bootup CAC.
>
> However, we found that this flag can be set after triggering scanning on a
> connected station interface, and the reason CH_SWITCH_SCAN_BYPASS_DPD will
> be used when switching back to the operating channel, which makes the
> firmware failed to resume paused AC queues.
>
> Seems that we should avoid relying on this flag after switching to single
> multi-radio architecture. Instead, replace it with MT76_STATE_RUNNING.
I don't see how the conditions are comparable at all. I also don't see
how this function can be called with MT76_STATE_RUNNING unset.
Maybe a better replacement would be to check for a chanctx on the phy?
- Felix
^ permalink raw reply
* Re: [PATCH wireless-next v2] wifi: mac80211: use wiphy_hrtimer_work for CAC timeout
From: Johannes Berg @ 2026-02-02 9:07 UTC (permalink / raw)
To: Amith A; +Cc: linux-wireless
In-Reply-To: <20260130035511.2328713-1-amith.a@oss.qualcomm.com>
On Fri, 2026-01-30 at 09:25 +0530, Amith A wrote:
>
> struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
> + ktime_t ktime = ktime_set(0, ms_to_ktime(cac_time_ms));
> struct ieee80211_chan_req chanreq = { .oper = *chandef };
> struct ieee80211_local *local = sdata->local;
> struct ieee80211_link_data *link_data;
> @@ -3874,8 +3875,7 @@ static int ieee80211_start_radar_detection(struct wiphy *wiphy,
> if (err)
> return err;
>
> - wiphy_delayed_work_queue(wiphy, &link_data->dfs_cac_timer_work,
> - msecs_to_jiffies(cac_time_ms));
> + wiphy_hrtimer_work_queue(wiphy, &link_data->dfs_cac_timer_work, ktime);
This is really questionable on multiple counts (at least the variable
name, the ktime_set call arguments), I've fixed it to just do
ms_to_ktime(cac_time_ms) in the argument ...
johannes
^ permalink raw reply
* Re: [PULL linux-firmware] ath10k, ath11k and ath12k firmware ath-20260130
From: Dmitry Baryshkov @ 2026-02-02 9:11 UTC (permalink / raw)
To: Jeff Johnson
Cc: linux-firmware, linux-wireless, ath10k, ath11k, ath12k, jjohnson
In-Reply-To: <34lnv35rbicqk6duyqhhidunulcipttsj6ryvzw6embgablnpl@gh3wtsknmcma>
On Sat, Jan 31, 2026 at 08:39:57AM +0200, Dmitry Baryshkov wrote:
> On Fri, Jan 30, 2026 at 12:29:48PM -0800, Jeff Johnson wrote:
> > Hi,
> > Here's a new pull request for ath10k, ath11k and ath12k.
> >
> > For ath12k:
> >
> > Update firmware for QCN9274/hw2.0.
> >
> > Update board file for WCN7850/hw2.0 to support:
> > bus=pci,vendor=17cb,device=1107,subsystem-vendor=1eac,subsystem-device=8001,qmi-chip-id=2,qmi-board-id=255
> > bus=pci,vendor=17cb,device=1107,subsystem-vendor=1eac,subsystem-device=8004,qmi-chip-id=2,qmi-board-id=255
>
> These two were not a part of the previous upload, but... They again have
> board-id of 255 (unprogrammed). Why is there no calibration variant?
Our engineers clarified that for the PCIe cards with the programmed
subsystem-vendor and device we don't need calibration variant even if
board-id is 255.
Merged and pushed out: https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/899
>
> >
> >
> > Please let me know if there are any problems.
>
> --
> With best wishes
> Dmitry
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH net-next] net: remove unnecessary module_init/exit functions
From: Toke Høiland-Jørgensen @ 2026-02-02 9:17 UTC (permalink / raw)
To: Ethan Nelson-Moore, netdev, linux-can, linux-wireless
Cc: Ethan Nelson-Moore, Michael Grzeschik, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Marc Kleine-Budde, Vincent Mailhol, Ido Schimmel, Petr Machata,
Sridhar Samudrala, Ping-Ke Shih, Thomas Mühlbacher,
Oliver Hartkopp
In-Reply-To: <20260131004327.18112-1-enelsonmoore@gmail.com>
Ethan Nelson-Moore <enelsonmoore@gmail.com> writes:
> Many network drivers have unnecessary empty module_init and module_exit
> functions. Remove them (including some that just print a message). Note
> that if a module_init function exists, a module_exit function must also
> exist; otherwise, the module cannot be unloaded.
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
For ath9k:
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
^ permalink raw reply
* Re: [PATCH wireless-next v8 0/3] wifi: initial UHR support
From: Pablo MARTIN-GOMEZ @ 2026-02-02 10:27 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
In-Reply-To: <20260130154259.265130-5-johannes@sipsolutions.net>
On 30/01/2026 16:21, Johannes Berg wrote:
> Should probably just not be trying to do this while I have a fever...
>
> Maybe this one's going to be the last respin despite that.
>
> FWIW, I'm also working on further NPCA support, both rudimentary AP
> (just configuration of the NPCA chandef) and non-AP side. But I'm
> not going to post _that_ until I get through my fever ;-)
>
> johannes
>
Look good to me, but I don't feel I have the sufficient knowledge to
either the standard or mac80211 to warrant a Reviewed-by or an Ack-by.
Pablo
^ permalink raw reply
* Re: [PATCH wireless-next v8 0/3] wifi: initial UHR support
From: Karthikeyan Kathirvel @ 2026-02-02 10:50 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
In-Reply-To: <20260130154259.265130-5-johannes@sipsolutions.net>
On 1/30/2026 8:51 PM, Johannes Berg wrote:
> Should probably just not be trying to do this while I have a fever...
>
> Maybe this one's going to be the last respin despite that.
>
> FWIW, I'm also working on further NPCA support, both rudimentary AP
> (just configuration of the NPCA chandef) and non-AP side. But I'm
> not going to post _that_ until I get through my fever ;-)
>
> johannes
>
>
Would like to see your approach of NPCA for AP side, since we are
working on Enhanced critical update for all UHR operation features(which
includes NPCA as well).
/KK
^ permalink raw reply
* Re: [PATCH wireless-next v8 0/3] wifi: initial UHR support
From: Johannes Berg @ 2026-02-02 11:12 UTC (permalink / raw)
To: Karthikeyan Kathirvel, linux-wireless
In-Reply-To: <98c47cd2-6e90-4a17-a8a3-ea2d2290a72e@oss.qualcomm.com>
On Mon, 2026-02-02 at 16:20 +0530, Karthikeyan Kathirvel wrote:
>
> Would like to see your approach of NPCA for AP side, since we are
> working on Enhanced critical update for all UHR operation features(which
> includes NPCA as well).
So, FWIW, I went over this a few times in my head ... how do we support
it when one station has NPCA and another doesn't (need a per-STA flag?),
how do we update the NPCA operation when stations with different
parameters join/leave the BSS, etc.
Ultimately I decided that I'm going to leave these problems to you ;-)
For now literally all I've implemented for testing is an ability to
represent NPCA in the chandef (adding npca_chan and npca_punctured
bitmap to it), and two new nl80211 attributes to configure such a
chandef.
That won't even be an upstream hostapd patch, just some hack to set the
NPCA chandef in nl80211 and advertise it in the UHR operation element,
but it's already good enough to test a single client.
(Oh and nl80211 won't accept that unless the driver advertises NPCA
support in UHR for the AP interface, which our driver won't do outside
some testing mode.)
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v8 0/3] wifi: initial UHR support
From: Johannes Berg @ 2026-02-02 11:13 UTC (permalink / raw)
To: Pablo MARTIN-GOMEZ, linux-wireless
In-Reply-To: <87aaabdd-1c21-4b18-9650-a3b4c2618538@freebox.fr>
On Mon, 2026-02-02 at 11:27 +0100, Pablo MARTIN-GOMEZ wrote:
> On 30/01/2026 16:21, Johannes Berg wrote:
> > Should probably just not be trying to do this while I have a fever...
> >
> > Maybe this one's going to be the last respin despite that.
> >
> > FWIW, I'm also working on further NPCA support, both rudimentary AP
> > (just configuration of the NPCA chandef) and non-AP side. But I'm
> > not going to post _that_ until I get through my fever ;-)
> >
> > johannes
> >
> Look good to me, but I don't feel I have the sufficient knowledge to
> either the standard or mac80211 to warrant a Reviewed-by or an Ack-by.
Thanks :)
johannes
^ permalink raw reply
* Re: Problems building rtw89
From: Iohann Tachy @ 2026-02-02 11:31 UTC (permalink / raw)
To: Ping-Ke Shih; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <b7830d69ee2645fb9e4a3c371dcdf6eb@realtek.com>
On Sun, Feb 1, 2026 at 10:52 PM Ping-Ke Shih <pkshih@realtek.com> wrote:
>
> // sort posting as expected (avoid top posting)
>
> Iohann Tachy <iohann.tachy@gmail.com> wrote:
> > > On Thu, Jan 29, 2026 at 9:36 PM Ping-Ke Shih <pkshih@realtek.com> wrote:
> > > >
> > > > Iohann Tachy <iohann.tachy@gmail.com> wrote:
> > > > > Good morning,
> > > > >
> > > > > Currently there's an issue where it's not possible to build the rtw89 driver.
> > > > > The RTL8852BE card has a compatibility problem with Intel X99 chipset
> > > > > and a hacked rtw89 driver is needed to make it work.
> > > > >
> > > > > I kindly request to read the Github issue:
> > > > > https://github.com/lwfinger/rtw89/issues/396
> > > >
> > > > A fix in Github is to disable 36-bit DMA [1]. I'd like to collect platform
> > > > info to add a quirk. Please share outputs of below commands
> > > > - dmidecode
> > > > - lspci -vt
> > > > - lspci -x
> > > >
> > > > [1] https://github.com/a5a5aa555oo/rtw89-1/commit/629756ee0232089d298bb398790d4a745b950058
> > > >
> > > >
> > On Fri, Jan 30, 2026 at 1:58 PM Iohann Tachy <iohann.tachy@gmail.com> wrote:
> > >
> > > Good afternoon!
> > > I'll run the " - dmidecode
> > > - lspci -vt
> > > - lspci -x"
> > > commands today evening.
> > > and I'll let you know what's the output results.
> > >
> > > Regards,
> > > Iohann
> > >
> > Good evening,
> >
> > I attached the results of the commands you requested.
> >
>
> I sent a patch to avoid 36-bit DMA as github did if the driver is running on
> your motherboard X99. Please revert the patch you mentioned from github, and
> apply this one to see if it can work to you.
>
> I decide to not choose PCI bridge as a quirk rule, because the PCI bridge
> "Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port"
> is in common use, and I believe other boards using this bridge can work with
> RTL8852BE.
>
> Another, I assume you installed RTL8852BE on X99 personally, not pre-installed
> on the board when you purchased, right?
>
> [1] https://lore.kernel.org/linux-wireless/20260202014049.11783-1-pkshih@realtek.com/T/#u
>
>
Thank you. Yes I did install the pcie card myself (It's a TP-Link TX20E)
I'll try in the evening to figure out how to apply and test the patch,
as I don't quite yet understand how to do it. thanks.
^ permalink raw reply
* Re: [PATCH 1/5] wifi: mt76: fix potential deadlock caused by rx_lock
From: Shayne Chen @ 2026-02-02 11:46 UTC (permalink / raw)
To: Felix Fietkau
Cc: linux-wireless, Lorenzo Bianconi, Ryder Lee, Evelyn Tsai,
Money Wang, linux-mediatek
In-Reply-To: <e785fe7c-eb3c-4697-9ea6-705c8c9dcfe1@nbd.name>
On Mon, 2026-02-02 at 09:52 +0100, Felix Fietkau wrote:
> On 02.02.26 08:53, Shayne Chen wrote:
> > A deadlock will occur if both of the following conditions are met,
> > because they each attempt to acquire the rx_lock:
> > - mac80211 receives an unexpected BAR control frame, which triggers
> > a BA deletion
> > - A transmission failure happens due to an abnormality in DMA
> >
> > Since ieee80211_tx_status_ext() is primarily used to address AQL
> > issues,
> > avoid potential deadlocks by restricting calls to
> > ieee80211_tx_status_ext
> > only for data frames.
>
> First of all, ieee80211_tx_status_ext is not primarily used to
> address
> AQL, ieee80211_free_txskb handles it as well. The reason for it is tx
> status handling, e.g. for management frames sent by hostapd that
> require
> an ACK status report, so limiting the status calls for data frames
> seems
> wrong to me.
>
> I don't really understand how the scenario you're describing leads to
> a
> deadlock. From my understanding, if something in the mac80211 rx path
> triggers a tx, it should end up calling mt76_tx(), which queues the
> skb
> to wcid->tx_list and triggers the tx worker. So the actual dma tx
> callls
> are expected to come from the worker kthread.
> How does this lead to a deadlock on rx_lock?
Hi Felix,
Thanks for the explanation.
I've re-checked the codebase used by the customer when the issue was
reported, and I found that the wcid->tx_list structure was not present
in that version. So yes, this problem should not occur in the current
codebase.
Will drop this patch in v2.
Thanks,
Shayne
>
> - Felix
^ permalink raw reply
* Re: [PATCH 5/5] wifi: mt76: mt7996: fix queue pause after scan due to wrong channel switch reason
From: Shayne Chen @ 2026-02-02 11:52 UTC (permalink / raw)
To: Felix Fietkau
Cc: linux-wireless, Lorenzo Bianconi, Ryder Lee, Evelyn Tsai,
Money Wang, linux-mediatek, StanleyYP Wang
In-Reply-To: <fe5bb9ed-7dab-4cd5-b2ab-e5252713095c@nbd.name>
On Mon, 2026-02-02 at 10:01 +0100, Felix Fietkau wrote:
> On 02.02.26 08:53, Shayne Chen wrote:
> > From: StanleyYP Wang <StanleyYP.Wang@mediatek.com>
> >
> > Previously, we use the IEEE80211_CONF_IDLE flag to avoid setting
> > the
> > parking channel with the CH_SWITCH_NORMAL reason, which could
> > trigger TX
> > emission before bootup CAC.
> >
> > However, we found that this flag can be set after triggering
> > scanning on a
> > connected station interface, and the reason
> > CH_SWITCH_SCAN_BYPASS_DPD will
> > be used when switching back to the operating channel, which makes
> > the
> > firmware failed to resume paused AC queues.
> >
> > Seems that we should avoid relying on this flag after switching to
> > single
> > multi-radio architecture. Instead, replace it with
> > MT76_STATE_RUNNING.
>
> I don't see how the conditions are comparable at all. I also don't
> see
> how this function can be called with MT76_STATE_RUNNING unset.
>
The condition is used to prevent mt7996_mcu_set_chan_info() (in
mt7996_run()) from triggering TX emission.
> Maybe a better replacement would be to check for a chanctx on the
> phy?
>
Will do some tests on this and send v2.
Thanks,
Shayne
> - Felix
^ permalink raw reply
* Re: [PATCH 5/5] wifi: mt76: mt7996: fix queue pause after scan due to wrong channel switch reason
From: Felix Fietkau @ 2026-02-02 12:22 UTC (permalink / raw)
To: Shayne Chen
Cc: linux-wireless, Lorenzo Bianconi, Ryder Lee, Evelyn Tsai,
Money Wang, linux-mediatek, StanleyYP Wang
In-Reply-To: <41b9111e696c0b0a9a3ad4d8728cf9819aa64708.camel@mediatek.com>
On 02.02.26 12:52, Shayne Chen wrote:
> On Mon, 2026-02-02 at 10:01 +0100, Felix Fietkau wrote:
>> On 02.02.26 08:53, Shayne Chen wrote:
>> > From: StanleyYP Wang <StanleyYP.Wang@mediatek.com>
>> >
>> > Previously, we use the IEEE80211_CONF_IDLE flag to avoid setting
>> > the
>> > parking channel with the CH_SWITCH_NORMAL reason, which could
>> > trigger TX
>> > emission before bootup CAC.
>> >
>> > However, we found that this flag can be set after triggering
>> > scanning on a
>> > connected station interface, and the reason
>> > CH_SWITCH_SCAN_BYPASS_DPD will
>> > be used when switching back to the operating channel, which makes
>> > the
>> > firmware failed to resume paused AC queues.
>> >
>> > Seems that we should avoid relying on this flag after switching to
>> > single
>> > multi-radio architecture. Instead, replace it with
>> > MT76_STATE_RUNNING.
>>
>> I don't see how the conditions are comparable at all. I also don't
>> see
>> how this function can be called with MT76_STATE_RUNNING unset.
>>
> The condition is used to prevent mt7996_mcu_set_chan_info() (in
> mt7996_run()) from triggering TX emission.
Makes sense.
>> Maybe a better replacement would be to check for a chanctx on the
>> phy?
>>
> Will do some tests on this and send v2.
Thanks.
- Felix
^ permalink raw reply
* [PATCH RFC RESEND] wifi: mac80211: Update mesh rate control per beacon to restore correct MCS
From: Simon Schippers @ 2026-02-02 13:35 UTC (permalink / raw)
To: johannes, linux-wireless, linux-kernel; +Cc: Simon Schippers
When operating two TP-Link EAP225 Outdoor v3 devices with OpenWrt [1] in
an 802.11s 5 GHz mesh (ath10k), I observed that the MCS does not recover
correctly after a link temporarily goes out of signal range and then
returns to good signal conditions. Instead, the low MCS selected when the
link goes out of signal range is retained even after signal quality
improves significantly. Only after a long delay (around 5 minutes) does
the rate control recover and select an appropriate higher MCS again.
I was able to reproduce this behavior reliably using a controlled test
setup with two mesh nodes connected through adjustable RF attenuators
(some details in [2]). In my measurements, the link commonly gets stuck
at MCS 2 (45 Mbit/s), resulting in a throughput of roughly 35 Mbit/s
despite great signal conditions.
I experimented with various 802.11s and ath10k configuration parameters,
but none resolved the issue.
To address this, the proposed patch triggers a rate control
initialization/update every time mesh_sta_info_init() is invoked, even if
a beacon has already been processed. With this change, the MCS is updated
correctly when signal conditions improve, and the observed issue is
resolved in my setup (not posted in [2] for now).
As I do not know if this is the right approach to solve this issue, I am
submitting this patch as an RFC.
Thanks :)
Simon
[1] Link: https://openwrt.org/toh/tp-link/eap225
[2] Link: https://forum.openwrt.org/t/802-11s-batman-5ghz-mesh-stuck-at-mcs-2-after-getting-into-range-again/243461
Signed-off-by: Simon Schippers <simon.schippers@tu-dortmund.de>
---
net/mac80211/mesh_plink.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index 04c931cd2063..66d735e18461 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -425,68 +425,69 @@ u64 mesh_plink_deactivate(struct sta_info *sta)
static void mesh_sta_info_init(struct ieee80211_sub_if_data *sdata,
struct sta_info *sta,
struct ieee802_11_elems *elems)
{
struct ieee80211_local *local = sdata->local;
struct ieee80211_supported_band *sband;
u32 rates, changed = 0;
enum ieee80211_sta_rx_bandwidth bw = sta->sta.deflink.bandwidth;
sband = ieee80211_get_sband(sdata);
if (!sband)
return;
rates = ieee80211_sta_get_rates(sdata, elems, sband->band, NULL);
spin_lock_bh(&sta->mesh->plink_lock);
sta->deflink.rx_stats.last_rx = jiffies;
/* rates and capabilities don't change during peering */
if (sta->mesh->plink_state == NL80211_PLINK_ESTAB &&
sta->mesh->processed_beacon)
goto out;
sta->mesh->processed_beacon = true;
if (sta->sta.deflink.supp_rates[sband->band] != rates)
changed |= IEEE80211_RC_SUPP_RATES_CHANGED;
sta->sta.deflink.supp_rates[sband->band] = rates;
if (ieee80211_ht_cap_ie_to_sta_ht_cap(sdata, sband,
elems->ht_cap_elem,
&sta->deflink))
changed |= IEEE80211_RC_BW_CHANGED;
ieee80211_vht_cap_ie_to_sta_vht_cap(sdata, sband,
elems->vht_cap_elem, NULL,
&sta->deflink);
ieee80211_he_cap_ie_to_sta_he_cap(sdata, sband, elems->he_cap,
elems->he_cap_len,
elems->he_6ghz_capa,
&sta->deflink);
ieee80211_eht_cap_ie_to_sta_eht_cap(sdata, sband, elems->he_cap,
elems->he_cap_len,
elems->eht_cap, elems->eht_cap_len,
&sta->deflink);
if (bw != sta->sta.deflink.bandwidth)
changed |= IEEE80211_RC_BW_CHANGED;
/* HT peer is operating 20MHz-only */
if (elems->ht_operation &&
!(elems->ht_operation->ht_param &
IEEE80211_HT_PARAM_CHAN_WIDTH_ANY)) {
if (sta->sta.deflink.bandwidth != IEEE80211_STA_RX_BW_20)
changed |= IEEE80211_RC_BW_CHANGED;
sta->sta.deflink.bandwidth = IEEE80211_STA_RX_BW_20;
}
+out:
/* FIXME: this check is wrong without SW rate control */
if (!test_sta_flag(sta, WLAN_STA_RATE_CONTROL))
rate_control_rate_init(&sta->deflink);
else
rate_control_rate_update(local, sband, &sta->deflink, changed);
-out:
+
spin_unlock_bh(&sta->mesh->plink_lock);
}
--
2.43.0
^ permalink raw reply related
* pull-request: ath-next-20260202
From: Jeff Johnson @ 2026-02-02 14:36 UTC (permalink / raw)
To: linux-wireless, Johannes Berg; +Cc: ath10k, ath11k, ath12k, jjohnson
The following changes since commit c30e188bd2a886258be5facb970a804d8ef549b5:
Merge tag 'iwlwifi-next-2026-01-21' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next (2026-01-27 13:54:12 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git tags/ath-next-20260202
for you to fetch changes up to 2c1ba9c2adf0fda96eaaebd8799268a7506a8fc9:
wifi: ath12k: clear stale link mapping of ahvif->links_map (2026-01-30 07:12:38 -0800)
----------------------------------------------------------------
ath.git patches for v6.20/v7.0 (#3)
A set of small features and cleanups for the next merge window.
----------------------------------------------------------------
Aaradhana Sahu (4):
wifi: ath12k: Fix index decrement when array_len is zero
wifi: ath12k: Add support RX PDEV stats
wifi: ath12k: Add support TX hardware queue stats
wifi: ath12k: clear stale link mapping of ahvif->links_map
Dmitry Baryshkov (1):
wifi: ath10k: snoc: support powering on the device via pwrseq
Miaoqing Pan (2):
wifi: ath11k: add usecase firmware handling based on device compatible
dt-bindings: net: wireless: ath11k-pci: deprecate 'firmware-name' property
Wei Zhang (2):
wifi: ath12k: add WMI support for spatial reuse parameter configuration
wifi: ath12k: support OBSS PD configuration for AP mode
Ziyi Guo (2):
wifi: ath10k: fix lock protection in ath10k_wmi_event_peer_sta_ps_state_chg()
wifi: ath10k: sdio: add missing lock protection in ath10k_sdio_fw_crashed_dump()
.../bindings/net/wireless/qcom,ath11k-pci.yaml | 1 +
drivers/net/wireless/ath/ath10k/sdio.c | 6 +
drivers/net/wireless/ath/ath10k/snoc.c | 53 +++++-
drivers/net/wireless/ath/ath10k/snoc.h | 3 +
drivers/net/wireless/ath/ath10k/wmi.c | 4 +-
drivers/net/wireless/ath/ath11k/core.c | 27 +++
drivers/net/wireless/ath/ath11k/core.h | 4 +
.../net/wireless/ath/ath12k/debugfs_htt_stats.c | 197 ++++++++++++++++++++-
.../net/wireless/ath/ath12k/debugfs_htt_stats.h | 81 +++++++++
drivers/net/wireless/ath/ath12k/mac.c | 174 +++++++++++++++++-
drivers/net/wireless/ath/ath12k/mac.h | 3 +
drivers/net/wireless/ath/ath12k/wmi.c | 142 +++++++++++++++
drivers/net/wireless/ath/ath12k/wmi.h | 47 +++++
13 files changed, 730 insertions(+), 12 deletions(-)
^ permalink raw reply
* Re: [PATCH 01/13] wifi: nl80211/cfg80211: Allow RSTA role to be enabled without LMR request
From: Jeff Johnson @ 2026-02-02 14:46 UTC (permalink / raw)
To: Peddolla Harshavardhan Reddy, johannes; +Cc: linux-wireless
In-Reply-To: <20260130160039.2823409-2-peddolla.reddy@oss.qualcomm.com>
On 1/30/2026 8:00 AM, Peddolla Harshavardhan Reddy wrote:
> The commit 853800c746d3 ("wifi: nl80211/cfg80211: support operating as
> RSTA in PMSR FTM request") adds a check which mandates LMR to be requested
> when the request is to enable RSTA, such check is incorrect in cases
this is a run-on sentence. s/, such/. Such/
> where we want the device to just to act as RSTA and not wakeup the
> host with measurement reports. This commit fixes this issue by removing
use imperative tense: Fix this issue...
> the mentioned check and also updating the corresponding documentation.
>
> Signed-off-by: Peddolla Harshavardhan Reddy <peddolla.reddy@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 07/13] wifi: nl80211/cfg80211: add ingress/egress distance thresholds for FTM
From: Jeff Johnson @ 2026-02-02 14:55 UTC (permalink / raw)
To: Peddolla Harshavardhan Reddy, johannes; +Cc: linux-wireless
In-Reply-To: <20260130160039.2823409-8-peddolla.reddy@oss.qualcomm.com>
On 1/30/2026 8:00 AM, Peddolla Harshavardhan Reddy wrote:
> Add support for configurable distance-based measurement reporting
> thresholds in FTM peer measurement requests. This enables proximity
> detection applications to receive measurement results only when
> devices move into (ingress) or out of (egress) specified distance
> ranges in millimeters.
>
> The implementation adds NL80211_PMSR_FTM_REQ_ATTR_INGRESS and
use imperative tense
> NL80211_PMSR_FTM_REQ_ATTR_EGRESS attributes with corresponding
> u64 fields in cfg80211_pmsr_ftm_request_peer. When configured,
> measurement results are reported on burst index basis only when
> peer crosses these distance boundaries.
>
> Signed-off-by: Peddolla Harshavardhan Reddy <peddolla.reddy@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 08/13] wifi: nl80211/cfg80211: add PD-specific bandwidth capabilities for FTM
From: Jeff Johnson @ 2026-02-02 14:56 UTC (permalink / raw)
To: Peddolla Harshavardhan Reddy, johannes; +Cc: linux-wireless
In-Reply-To: <20260130160039.2823409-9-peddolla.reddy@oss.qualcomm.com>
On 1/30/2026 8:00 AM, Peddolla Harshavardhan Reddy wrote:
> Add separate bandwidth capability reporting for proximity detection
> (PD) requests with EDCA and NTB-based ranging. This allows devices
> to advertise different supported bandwidths for PD operations
> versus regular FTM measurements, enabling more flexible capability
> negotiation for proximity ranging scenarios.
Normally in kernel commit text you describe the problem first, and then
describe how to solve the problem.
^ 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