* [PATCH v5 0/1] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers
From: Devin Wittmayer @ 2026-06-03 19:28 UTC (permalink / raw)
To: linux-wireless
Cc: Johannes Berg, Felix Fietkau, Lorenzo Bianconi, linux-kernel,
Oscar Alfonso Diaz, fjhhz1997, Brite
In-Reply-To: <20260519235713.49109-1-lucid_duck@justthetip.ca>
v4 [1] used list_first_or_null_rcu() plus an rcu_access_pointer() check
on the sole entry's list.next to confirm it was the only chanctx. As
Johannes pointed out [2], list.next is not an __rcu pointer, so that
check trips a sparse warning, and his original loop is cleaner. v5 walks
chanctx_list with list_for_each_entry_rcu() and takes the sole entry
instead, which builds clean.
v5 also switches the stable tag to the noautosel opt-out, since the fix
can crash older drivers and should not be auto-backported.
No functional change from v4, so the v3 Tested-by carries. I rebuilt v5
and reran the monitor injection test on mt7921e here, no crash.
[1] https://lore.kernel.org/linux-wireless/20260519235713.49109-1-lucid_duck@justthetip.ca/
[2] https://lore.kernel.org/linux-wireless/978c9a11cf836680b1fd9365f3b90f028ddf5372.camel@sipsolutions.net/
傅继晗 (1):
wifi: mac80211: fix monitor mode frame capture for real chanctx
drivers
net/mac80211/tx.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH v5 1/1] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers
From: Devin Wittmayer @ 2026-06-03 19:28 UTC (permalink / raw)
To: linux-wireless
Cc: 傅继晗, Johannes Berg, Felix Fietkau,
Lorenzo Bianconi, linux-kernel, Oscar Alfonso Diaz, Brite,
stable+noautosel
In-Reply-To: <cover.1780513445.git.lucid_duck@justthetip.ca>
From: 傅继晗 <fjhhz1997@gmail.com>
Commit d594cc6f2c58 ("wifi: mac80211: restore non-chanctx injection
behaviour") restored the monitor injection fallback for drivers using
chanctx emulation but explicitly deferred drivers that transitioned
to real chanctx ops. mt76 falls in that category and still drops
every injected frame when monitor coexists with another interface.
When the monitor has no chanctx of its own, fall back to the only
chanctx in flight if there is exactly one. Refuse if multiple are
present: picking arbitrarily would inject on an unrelated channel.
Emulated and real chanctx drivers both flow through this fallback,
since emulation always presents zero or one chanctx in
local->chanctx_list.
Reran the airgeddon evil-twin flow (hostapd AP + coexisting monitor
VIF on the same phy + aireplay-ng deauth from the monitor) on
mt7921e PCIe and mt7921u USB across 2.4 GHz and 5 GHz, and on a
Kali VM with MT7921U passthrough as the closest match to the
original reporter's setup. None reproduced the hang seen against
the earlier attempt at this fix
(<20251216111909.25076-2-johannes@sipsolutions.net>) or against v1
on lore in March.
Cc: <stable+noautosel@kernel.org> # causes some older drivers to crash
Reported-by: Oscar Alfonso Diaz <oscar.alfonso.diaz@gmail.com>
Closes: https://github.com/morrownr/USB-WiFi/issues/682
Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers")
Signed-off-by: 傅继晗 <fjhhz1997@gmail.com>
Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
---
v5:
- Use list_for_each_entry_rcu() to find the single chanctx instead
of list_first_or_null_rcu() plus an rcu_access_pointer() check on
ctx->list.next. That field is not an __rcu pointer, so the check
tripped a sparse warning. No functional change.
- Opt out of stable autoselect (the fix reintroduces the crash on
older drivers) instead of Cc: stable # 6.9+.
v4:
- Drop the dedicated local->emulate_chanctx branch. Emulation always
presents zero or one chanctx in local->chanctx_list, so the
single-chanctx walk handles that path too.
- Real-chanctx TX path is unchanged, so v3 Tested-by carries.
v3:
- Replace list_is_singular() + list_first_entry() with an RCU walk.
The v2 pair re-read ->next without RCU between the singularity check
and the entry fetch, racing list_del_rcu() of the sole entry
(rculist.h).
v2:
- First respin under my submitter signoff; preserves fjh1997
authorship.
- Verification matrix; airgeddon evil-twin flow on mt7921e/mt7921u/
Kali-VM does not reproduce the hang reported against the v1 attempt
at this fix.
net/mac80211/tx.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 933c86ca21c3..cf336e92c072 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2407,10 +2407,20 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
rcu_dereference(tmp_sdata->vif.bss_conf.chanctx_conf);
}
+ if (!chanctx_conf) {
+ struct ieee80211_chanctx *ctx;
+ bool first = true;
+
+ list_for_each_entry_rcu(ctx, &local->chanctx_list, list) {
+ if (!first)
+ goto fail_rcu;
+ chanctx_conf = &ctx->conf;
+ first = false;
+ }
+ }
+
if (chanctx_conf)
chandef = &chanctx_conf->def;
- else if (local->emulate_chanctx)
- chandef = &local->hw.conf.chandef;
else
goto fail_rcu;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] wifi: mt76: mt7925: add regulatory wiphy self manager support
From: kernel test robot @ 2026-06-03 20:27 UTC (permalink / raw)
To: JB Tsai, nbd, lorenzo
Cc: llvm, oe-kbuild-all, linux-wireless, linux-mediatek, Deren.Wu,
Sean.Wang, Quan.Zhou, Ryder.Lee, Leon.Yen, litien.chang,
Charlie-cy.Wu, jb.tsai
In-Reply-To: <20260603075331.1234691-1-jb.tsai@mediatek.com>
Hi JB,
kernel test robot noticed the following build errors:
[auto build test ERROR on wireless-next/main]
[also build test ERROR on wireless/main linus/master v7.1-rc6 next-20260602]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/JB-Tsai/wifi-mt76-mt7925-add-regulatory-wiphy-self-manager-support/20260603-155908
base: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git main
patch link: https://lore.kernel.org/r/20260603075331.1234691-1-jb.tsai%40mediatek.com
patch subject: [PATCH] wifi: mt76: mt7925: add regulatory wiphy self manager support
config: x86_64-rhel-9.4-rust (https://download.01.org/0day-ci/archive/20260603/202606032205.iaSDVq2Z-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project f43d6834093b19baf79beda8c0337ab020ac5f17)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260603/202606032205.iaSDVq2Z-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606032205.iaSDVq2Z-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/net/wireless/mediatek/mt76/mt7925/regd.c:361:43: error: passing 'const struct ieee80211_regdomain *' to parameter of type 'struct ieee80211_regdomain *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
361 | return regulatory_set_wiphy_regd(wiphy, &mt7925_regd_ww);
| ^~~~~~~~~~~~~~~
include/net/cfg80211.h:8082:38: note: passing argument to parameter 'rd' here
8082 | struct ieee80211_regdomain *rd);
| ^
1 error generated.
vim +361 drivers/net/wireless/mediatek/mt76/mt7925/regd.c
286
287 int mt7925_regd_update(struct mt792x_phy *phy, char *alpha2)
288 {
289 struct wiphy *wiphy = phy->mt76->hw->wiphy;
290 struct ieee80211_hw *hw = wiphy_to_ieee80211_hw(wiphy);
291 struct mt792x_dev *dev = mt792x_hw_dev(hw);
292 struct mt7925_regd_rule *mt7925_rule;
293 struct mt76_dev *mdev = &dev->mt76;
294 struct ieee80211_regdomain *regd;
295 struct ieee80211_reg_rule *rule;
296 struct mt7925_regd_rule_ev *ev;
297 int i, num_of_rules = 0;
298 struct sk_buff *skb;
299 int ret = 0;
300
301 if (dev->hw_full_reset)
302 return 0;
303
304 if (!MT7925_REGD_SUPPORTED(phy))
305 return -EOPNOTSUPP;
306
307 mt792x_mutex_acquire(dev);
308 skb = mt7925_regd_query_regdb(phy, alpha2);
309 mt792x_mutex_release(dev);
310
311 if (!skb)
312 return -EINVAL;
313
314 ev = (struct mt7925_regd_rule_ev *)(skb->data + 4);
315 num_of_rules = le32_to_cpu(ev->n_reg_rules);
316
317 if (!num_of_rules ||
318 WARN_ON_ONCE(num_of_rules > NL80211_MAX_SUPP_REG_RULES)) {
319 ret = -EINVAL;
320 goto err;
321 }
322
323 regd = kzalloc(struct_size(regd, reg_rules, num_of_rules), GFP_KERNEL);
324 if (!regd) {
325 ret = -ENOMEM;
326 goto err;
327 }
328
329 for (i = 0; i < num_of_rules; i++) {
330 mt7925_rule = &ev->reg_rule[i];
331 rule = ®d->reg_rules[i];
332
333 rule->freq_range.start_freq_khz =
334 MHZ_TO_KHZ(mt7925_rule->start_freq);
335 rule->freq_range.end_freq_khz =
336 MHZ_TO_KHZ(mt7925_rule->end_freq);
337 rule->freq_range.max_bandwidth_khz =
338 MHZ_TO_KHZ(mt7925_rule->max_bw);
339 /* not used by fw */
340 rule->power_rule.max_antenna_gain = DBI_TO_MBI(6);
341 rule->power_rule.max_eirp = DBM_TO_MBM(22);
342 rule->flags = mt7925_rule->flags;
343 }
344
345 regd->n_reg_rules = num_of_rules;
346 regd->dfs_region = ev->dfs_region;
347
348 memcpy(regd->alpha2, alpha2, 2);
349 memcpy(mdev->alpha2, alpha2, 2);
350
351 dev->regd_change = true;
352 mt7925_mcu_regd_update(dev, alpha2, ENVIRON_ANY);
353
354 ret = regulatory_set_wiphy_regd(wiphy, regd);
355
356 kfree(regd);
357 err:
358 dev_kfree_skb(skb);
359
360 if (ret < 0)
> 361 return regulatory_set_wiphy_regd(wiphy, &mt7925_regd_ww);
362
363 return ret;
364 }
365 EXPORT_SYMBOL_GPL(mt7925_regd_update);
366
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [bug report] wifi: mt76: mt7921: mt7925monitor-mode per-channel retune emits narrowband RF burst
From: Bradley Pizzimenti @ 2026-06-03 23:46 UTC (permalink / raw)
To: Sean Wang
Cc: John Henry, Javier Tia, linux-wireless, linux-kernel, nbd,
lorenzo, ryder.lee, shayne.chen, sean.wang,
moderated list:ARM/Mediatek SoC support, Deren Wu, Nick Morrow
In-Reply-To: <CAGp9LzrmUGQLK5giHVgOjJ5pzGNnfLaV02iWdodT7aDNBbNUqg@mail.gmail.com>
Hi there,
Are all of these fixes going into kernel 7.1+ or introduced earlier?
On Wed, May 27, 2026 at 4:08 PM Sean Wang <sean.wang@kernel.org> wrote:
>
> Hi John,
>
> On Wed, May 27, 2026 at 7:24 AM John Henry <jshenry1963@gmail.com> wrote:
> >
> > Just a kind reminder of this issue.
> >
> > Please advise if this is already taken up in a separate issue I am
> > unaware of, but it is not directly related to the "iw set txpower
> > fixed accepted but ignored" issue.
> >
> > On products available in the market, e.g. the Alfa AWUS036AXML
> > consumer product and the Netgear Nighthawk A9000, in Monitor Mode
> > there is RF generated when scanning through channels and we get to 5
> > or more channels in succession.
> > This does not seem to occur at all in managed mode.
> >
> > This means if we scan the 2.4GHz channel list, an RF Spectrum analyzer
> > will show a narrow pulse generated on each channel as we progress
> > through the channels.
> > This can 100% be reproduced using standard iw set channel commands as
> > shown below:
> > FACE=$(iw dev | awk '/Interface wl/ {print $2; exit}')
> > iw reg set US ; sleep 1
> > ip link set "$IFACE" down
> > iw dev "$IFACE" set type monitor
> > ip link set "$IFACE" up
> >
> > # This triggers narrowband bursts at channel center on each retune:
> > while true; do
> > for f in 2412 2417 2422 2427 2432; do
> > iw dev "$IFACE" set freq "$f" HT20
> > done
> > done
> >
>
> I have thought about this issue for a while. A possible workaround
> would be to reset WFSYS / firmware after five consecutive `set
> channel` operations in monitor mode, then restore the current monitor
> channel context. The WFSYS reset may take hundreds of milliseconds to
> complete, which is the cost we would need to pay.
>
> > No special software required to reproduce.
> > I have shown that this occurs on all MT7921 based products, along with
> > MT7925 based products.
> > It does not occur if the channel list is set to the same 4 over and
> > over, no RF generated.
> >
> > There are no calibration channel commands going from the driver to the
> > firmware, so I believe this is a firmware bug.
> >
> > Best Regards,
> > John Henry
> >
> > On Sun, May 17, 2026 at 9:01 AM John Henry <jshenry1963@gmail.com> wrote:
> > >
> > > Just a kind reminder of this issue, has anyone been able to reproduce
> > > this monitor mode issue?
> > > When scanning through channels, and the list of channels is > 4, there
> > > is a large transmit tick/burst coming from the MT7921u and the MT7925.
> > > This can easily be seen on an RF Spectrum Analyzer.
> > > Confirmed on an Alfa AWUS036AXML consumer product and the Netgear
> > > Nighthawk A9000.
> > > This can be reproduced with simple scripts.
> > >
> > > Reproduction with stock iw commands (no custom code):
> > >
> > > IFACE=$(iw dev | awk '/Interface wl/ {print $2; exit}')
> > > iw reg set US ; sleep 1
> > > ip link set "$IFACE" down
> > > iw dev "$IFACE" set type monitor
> > > ip link set "$IFACE" up
> > >
> > > # This triggers narrowband bursts at channel center on each retune:
> > > while true; do
> > > for f in 2412 2417 2422 2427 2432; do
> > > iw dev "$IFACE" set freq "$f" HT20
> > > done
> > > done
> > >
> > > # This does NOT (only 4 frequencies):
> > > while true; do
> > > for f in 2412 2422 2462 2484; do
> > > iw dev "$IFACE" set freq "$f" HT20
> > > done
> > > done
> > >
> > > Bursts are ~800 kHz wide at the base, -30 to -50 dBm OTA at close
> > > range, brief (estimated few hundred microseconds), at channel
> > > frequency. tx_stats counters remain zero throughout.
> > > On Mon, May 11, 2026 at 1:58 PM John Henry <jshenry1963@gmail.com> wrote:
> > > >
> > > > Bradley/Sean,
> > > >
> > > > Thank you all very much for the information.
> > > > I tested this on mt7921u based Alfa AWUS unit and also an mt7925 based
> > > > Netgear Nighthawk unit.
> > > > I can confirm that the RF tick issue is present on both models when in
> > > > Monitor Mode. I'm assuming it is in the base mt76?
> > > >
> > > > I attempted sudo iw dev wlxxx set txpower fixed nn where nn is the
> > > > minimum value, next few values up, and then a few near the max values,
> > > > and see no change in the signal strength of the RF Ticks when scanning
> > > > through 5 or more channels.
> > > >
> > > > Please keep this in mind when attempting to resolve the known txpower
> > > > 3dBm issue if possible, or please generate a new bug report for that
> > > > specifically so that I can track when it is patched, or in ??? version
> > > > so that I can test here locally.
> > > >
> > > > Incidentally, I'd appreciate it if anyone could please attempt to
> > > > repeat using the scripts I had shown in the previous posts and confirm
> > > > it is indeed seen by others.
> > > >
> > > > Thank you very much for your time and assistance
> > > >
> > > > John Henry
> > > >
> > > >
> > > >
> > > >
> > > > From: Bradley Pizzimenti <brad.pizzimenti@gmail.com>
> > > > To: linux-wireless@vger.kernel.org
> > > > Cc: linux-kernel@vger.kernel.org, nbd@nbd.name, lorenzo@kernel.org,
> > > > ryder.lee@mediatek.com, shayne.chen@mediatek.com,
> > > > sean.wang@mediatek.com
> > > > Subject: [bug report] wifi: mt76: mt7925: iw set txpower fixed
> > > > accepted but ignored
> > > > Date: Mon, 4 May 2026 15:04:35 -0700 [thread overview]
> > > > Message-ID: <CACjnFagN9zeSkwEv3-CSPJDUENPcEcOLjKyQoLQ91Yjn=rq5ww@mail.gmail.com>
> > > > (raw)
> > > >
> > > > Hi there maintainers,
> > > >
> > > > `iw dev <iface> set txpower fixed N` returns success on mt7925 for any
> > > > N tested, but the reported txpower never changes from a stuck value of
> > > > 3.00 dBm. The kernel accepts and ignores the call silently in both
> > > > directions (above and below the displayed value), and well below the
> > > > regulatory ceiling.
> > > >
> > > > I'm aware there's prior art on the cosmetic 3.00 dBm display issue
> > > > (Razvan Grigore's v2 series, Feb 2025; Ming Yen Hsieh's txpower init
> > > > refactor, Sept 2025). What seems potentially distinct here is that the
> > > > user-issued `iw set txpower fixed N` itself is silently no-op'd,
> > > > separate from the reported-value question. Reporting as breadcrumbs
> > > > in case the second observation is a separate bug rather than the same
> > > > one.
> > > >
> > > > Hardware
> > > > --------
> > > > MEDIATEK MT7925 [Filogic 360], 802.11be 2x2, PCI 14c3:7925
> > > > ASIC revision 0x79250000
> > > > Driver in use: mt7925e (in-tree)
> > > >
> > > > Firmware (from dmesg at probe)
> > > > ------------------------------
> > > > mt7925e 0000:01:00.0: HW/SW Version: 0x8a108a10,
> > > > Build Time: 20260106153007a
> > > > mt7925e 0000:01:00.0: WM Firmware Version: ____000000,
> > > > Build Time: 20260106153120
> > > > Files: mediatek/mt7925/WIFI_MT7925_PATCH_MCU_1_1_hdr.bin
> > > > mediatek/mt7925/WIFI_RAM_CODE_MT7925_1_1.bin
> > > >
> > > > Kernel
> > > > ------
> > > > 6.18.18-1-MANJARO (close to vanilla 6.18 stable; not yet tested on
> > > > wireless-next or nbd168/wireless HEAD -- happy to retest if needed,
> > > > but flagging the data point in case it helps as-is).
> > > >
> > > > Tools: iw version 6.17
> > > >
> > > > Regulatory
> > > > ----------
> > > > $ iw reg get
> > > > country US: DFS-FCC
> > > > ...
> > > > (5730 - 5850 @ 80), (N/A, 30), (N/A), AUTO-BW
> > > > ...
> > > >
> > > > Connection context: 5GHz channel 161 (5805 MHz), 80 MHz, VHT-MCS,
> > > > NSS 1. So we are on a band with a 30 dBm regulatory cap.
> > > >
> > > > Observed
> > > > --------
> > > > $ iw dev wlp1s0 info | grep txpower
> > > > txpower 3.00 dBm
> > > >
> > > > $ sudo iw dev wlp1s0 set txpower fixed 100 # 1 dBm
> > > > $ iw dev wlp1s0 info | grep txpower
> > > > txpower 3.00 dBm
> > > >
> > > > $ sudo iw dev wlp1s0 set txpower fixed 1500 # 15 dBm
> > > > $ iw dev wlp1s0 info | grep txpower
> > > > txpower 3.00 dBm
> > > >
> > > > $ sudo iw dev wlp1s0 set txpower auto
> > > > $ iw dev wlp1s0 info | grep txpower
> > > > txpower 3.00 dBm
> > > >
> > > > All four `set` invocations return exit code 0. The reported value
> > > > never moves.
> > > >
> > > > Expected
> > > > --------
> > > > Either:
> > > > - The reported txpower follows the requested value (or, where
> > > > capped, the actual applied value with extack indicating the
> > > > cap reason), or
> > > > - The set call returns an error rather than silently ignoring the
> > > > request.
> > > >
> > > > Caveats
> > > > -------
> > > > - Not yet tested on wireless-next or nbd168/wireless HEAD. If a
> > > > reproduction on a current dev tree would be useful, I can do that.
> > > > - I have not verified whether the actual radiated TX power changes
> > > > in response to `set txpower fixed`; I am reporting only the
> > > > user-visible behavior.
> > > >
> > > > Thanks,
> > > > Bradley
> > > >
> > > > On Wed, May 6, 2026 at 8:12 PM Sean Wang <sean.wang@kernel.org> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > The TX power reporting issue has already been investigated by Lucid
> > > > > from the Linux WiFi USB community, and there is a proposed solution.
> > > > > I think we can continue checking whether there are any remaining
> > > > > issues on top of that work. Please refer to the patches here:
> > > > > https://lists.infradead.org/pipermail/linux-mediatek/2026-April/105726.html
> > > > > Thanks everyone for reporting and raising these concerns.
> > > > >
> > > > > On Wed, May 6, 2026 at 3:09 PM Javier Tia <floss@jetm.me> wrote:
> > > > > >
> > > > > > On Sun May 4 22:04:48 2026 Bradley Pizzimenti wrote:
> > > > > > > `iw dev <iface> set txpower fixed N` returns success on mt7925 for
> > > > > > > any N tested, but the reported txpower never changes from a stuck
> > > > > > > value of 3.00 dBm.
> > > > > >
> > > > > > Hi Bradley,
> > > > > >
> > > > > > The 3 dBm display bug is a known issue we have seen when using mt7927
> > > > > > and a tested fix has been working well so far. The root cause is that
> > > > > > mt7925_mcu_set_rate_txpower() programs the per-band SKU tables into
> > > > > > firmware but never assigns phy->txpower_cur. mt76_get_txpower() then
> > > > > > computes:
> > > > > >
> > > > > > DIV_ROUND_UP(0 + 6, 2) = 3
> > > > > >
> > > > > > regardless of the actual power level. The RF output is unaffected;
> > > > > > it is a display-only bug.
> > > > > >
> > > > > > The fix reads the effective TX power back from the rate power limits
> > > > > > after programming the SKU tables and writes it to phy->txpower_cur,
> > > > > > following the same pattern used by mt7996:
> > > > > >
> > > > > > https://github.com/jetm/mediatek-mt7927-dkms/blob/master/mt7927-wifi-14-fix-reported-txpower-always-showing-3-db.patch
> > > > > >
> > > > > > This is part of a series we are targeting for wireless-next; not
> > > > > > yet upstream.
> > > > > >
> > > > > > > What seems potentially distinct here is that the user-issued
> > > > > > > `iw set txpower fixed N` itself is silently no-op'd, separate
> > > > > > > from the reported-value question.
> > > > > >
> > > > > > Agreed those are two separate issues. Our patch addresses the
> > > > > > display-only side: after applying it, iw will report the value the
> > > > > > firmware is actually using based on the SKU tables, rather than
> > > > > > always 3 dBm. Whether `set txpower fixed N` propagates to firmware
> > > > > > to change actual output power is orthogonal and not addressed here.
> > > > > >
> > > > > > If you can test the patch on your MT7925 and confirm the displayed
> > > > > > value reflects the correct power after association, a Tested-by
> > > > > > would be appreciated.
> > > > > >
> > > > > > Best,
> > > > > > Javier
> > > > > >
> > > > >
^ permalink raw reply
* [PATCH wireless-next] wifi: mac80211: fold tid_ampdu_rx allocations into a flexible array
From: Rosen Penev @ 2026-06-04 0:14 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, open list
Convert the separately-allocated reorder_buf pointer to a C99 flexible
array member at the end of struct tid_ampdu_rx, and place reorder_time
in the same allocation immediately after it. This collapses three
allocations into one and removes the corresponding kfree() pairs from
the error and free paths.
Assisted-by: Claude:Opus-4.7
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
net/mac80211/agg-rx.c | 23 ++++++-----------------
net/mac80211/sta_info.h | 6 +++---
2 files changed, 9 insertions(+), 20 deletions(-)
diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index cecd1c917e45..20669cd8a34f 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -50,8 +50,6 @@ static void ieee80211_free_tid_rx(struct rcu_head *h)
for (i = 0; i < tid_rx->buf_size; i++)
__skb_queue_purge(&tid_rx->reorder_buf[i]);
- kfree(tid_rx->reorder_buf);
- kfree(tid_rx->reorder_time);
kfree(tid_rx);
}
@@ -294,6 +292,7 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta,
};
int i, ret = -EOPNOTSUPP;
u16 status = WLAN_STATUS_REQUEST_DECLINED;
+ size_t alloc_size;
u16 max_buf_size;
lockdep_assert_wiphy(sta->local->hw.wiphy);
@@ -412,10 +411,14 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta,
}
/* prepare A-MPDU MLME for Rx aggregation */
- tid_agg_rx = kzalloc_obj(*tid_agg_rx);
+ alloc_size = struct_size(tid_agg_rx, reorder_buf, buf_size);
+ alloc_size += sizeof(*tid_agg_rx->reorder_time) * buf_size;
+ tid_agg_rx = kzalloc(alloc_size, GFP_KERNEL);
if (!tid_agg_rx)
goto end;
+ tid_agg_rx->reorder_time = (void *)(tid_agg_rx->reorder_buf + buf_size);
+
spin_lock_init(&tid_agg_rx->reorder_lock);
/* rx timer */
@@ -426,18 +429,6 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta,
timer_setup(&tid_agg_rx->reorder_timer,
sta_rx_agg_reorder_timer_expired, 0);
- /* prepare reordering buffer */
- tid_agg_rx->reorder_buf =
- kzalloc_objs(struct sk_buff_head, buf_size);
- tid_agg_rx->reorder_time =
- kcalloc(buf_size, sizeof(unsigned long), GFP_KERNEL);
- if (!tid_agg_rx->reorder_buf || !tid_agg_rx->reorder_time) {
- kfree(tid_agg_rx->reorder_buf);
- kfree(tid_agg_rx->reorder_time);
- kfree(tid_agg_rx);
- goto end;
- }
-
for (i = 0; i < buf_size; i++)
__skb_queue_head_init(&tid_agg_rx->reorder_buf[i]);
@@ -445,8 +436,6 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta,
ht_dbg(sta->sdata, "Rx A-MPDU request on %pM tid %d result %d\n",
sta->sta.addr, tid, ret);
if (ret) {
- kfree(tid_agg_rx->reorder_buf);
- kfree(tid_agg_rx->reorder_time);
kfree(tid_agg_rx);
goto end;
}
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 39608a0abbb5..66adfc5c89b2 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -207,8 +207,6 @@ struct tid_ampdu_tx {
/**
* struct tid_ampdu_rx - TID aggregation information (Rx).
*
- * @reorder_buf: buffer to reorder incoming aggregated MPDUs. An MPDU may be an
- * A-MSDU with individually reported subframes.
* @reorder_buf_filtered: bitmap indicating where there are filtered frames in
* the reorder buffer that should be ignored when releasing frames
* @reorder_time: jiffies when skb was added
@@ -228,6 +226,8 @@ struct tid_ampdu_tx {
* and ssn.
* @removed: this session is removed (but might have been found due to RCU)
* @started: this session has started (head ssn or higher was received)
+ * @reorder_buf: buffer to reorder incoming aggregated MPDUs. An MPDU may be an
+ * A-MSDU with individually reported subframes.
*
* This structure's lifetime is managed by RCU, assignments to
* the array holding it must hold the aggregation mutex.
@@ -241,7 +241,6 @@ struct tid_ampdu_rx {
struct rcu_head rcu_head;
spinlock_t reorder_lock;
u64 reorder_buf_filtered;
- struct sk_buff_head *reorder_buf;
unsigned long *reorder_time;
struct sta_info *sta;
struct timer_list session_timer;
@@ -256,6 +255,7 @@ struct tid_ampdu_rx {
u8 auto_seq:1,
removed:1,
started:1;
+ struct sk_buff_head reorder_buf[];
};
/**
--
2.54.0
^ permalink raw reply related
* Re: [GIT PULL] wireless-2026-06-03
From: patchwork-bot+netdevbpf @ 2026-06-04 2:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-wireless
In-Reply-To: <20260603113208.171874-3-johannes@sipsolutions.net>
Hello:
This pull request was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 3 Jun 2026 13:31:24 +0200 you wrote:
> Hi,
>
> And yet more things ... I'm going to defer a number of driver
> things to wireless-next though, e.g. a PCIe device IRQ race.
>
> Please pull and let us know if there's any problem.
>
> [...]
Here is the summary with links:
- [GIT,PULL] wireless-2026-06-03
https://git.kernel.org/netdev/net/c/ac056099822e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH ath-next] wifi: ath12k: expand UserPD ID mask to support up to 8 PDs
From: Aaradhana Sahu @ 2026-06-04 3:15 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless, Aaradhana Sahu
Currently ATH12K_USERPD_ID_MASK uses GENMASK(9, 8), which defines a
2-bit field and limits supported UserPD IDs to values 0-3.
Future IPQ5332 multi-PD platform variants support more than three
UserPDs. Expand ATH12K_USERPD_ID_MASK to GENMASK(10, 8), increasing
the field width to 3 bits and allowing UserPD IDs from 0-7.
ATH12K_USERPD_ID_MASK is currently used only while constructing the
ath12k AHB PAS ID, so this change does not affect existing platforms.
Also remove the unused ATH12K_MAX_UPDS definition.
Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/ahb.c | 1 -
drivers/net/wireless/ath/ath12k/ahb.h | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/ahb.c b/drivers/net/wireless/ath/ath12k/ahb.c
index 30733a244454..4912172e106e 100644
--- a/drivers/net/wireless/ath/ath12k/ahb.c
+++ b/drivers/net/wireless/ath/ath12k/ahb.c
@@ -17,7 +17,6 @@
#include "hif.h"
#define ATH12K_IRQ_CE0_OFFSET 4
-#define ATH12K_MAX_UPDS 1
#define ATH12K_UPD_IRQ_WRD_LEN 18
static struct ath12k_ahb_driver *ath12k_ahb_family_drivers[ATH12K_DEVICE_FAMILY_MAX];
diff --git a/drivers/net/wireless/ath/ath12k/ahb.h b/drivers/net/wireless/ath/ath12k/ahb.h
index 0fa15daaa3e6..a153db6cf1d3 100644
--- a/drivers/net/wireless/ath/ath12k/ahb.h
+++ b/drivers/net/wireless/ath/ath12k/ahb.h
@@ -27,7 +27,7 @@
#define ATH12K_USERPD_SPAWN_TIMEOUT (5 * HZ)
#define ATH12K_USERPD_READY_TIMEOUT (10 * HZ)
#define ATH12K_USERPD_STOP_TIMEOUT (5 * HZ)
-#define ATH12K_USERPD_ID_MASK GENMASK(9, 8)
+#define ATH12K_USERPD_ID_MASK GENMASK(10, 8)
#define ATH12K_USERPD_FW_NAME_LEN 35
enum ath12k_ahb_smp2p_msg_id {
base-commit: e1c8fcfd37f76b46a581b794e27765258c9a537d
--
2.34.1
^ permalink raw reply related
* [PATCH v2] wifi: brcmfmac: add DPP support and fix fw-supplicant/P2P interop
From: Jason Huang @ 2026-06-04 3:42 UTC (permalink / raw)
To: linux-wireless
Cc: brcm80211, brcm80211-dev-list.pdl, linux-kernel, Kurt Lee,
Jason Huang
In-Reply-To: <20260603035722.145894-1-Jason.Huang2@infineon.com>
From: Kurt Lee <kurt.lee@cypress.com>
Add DPP support in brcmfmac and include follow-up fixes needed for
reliable operation with mixed security setups.
Main changes:
- add DPP AKM handling in key-mgmt and RSN parsing
- map DPP to WFA_AUTH_DPP and allow it in MFP-required checks
- recognize DPP public action frames in the P2P TX path
- pass the transmitting vif explicitly for action frame TX
- track the correct ROC wdev for remain-on-channel expiry
- gate sup_wpa iovar usage by firmware FWSUP capability
- avoid stale fw supplicant state that can break DPP/EAPOL handling
- add missing NULL checks in P2P abort/search-channel paths
Together these changes enable DPP while preventing regressions when
switching between DPP and non-DPP encrypted connections.
Changes in v2:
- Fix the kernel test robot warning by removing the unused
action_frame_len variable.
- Use upstream WLAN_AKM_SUITE_WFA_DPP and WLAN_OUI_* constants instead
of adding local DPP/P2P definitions.
- Use get_unaligned_be24() and get_unaligned_be32() for OUI and AKM
suite parsing.
- Gate sup_wpa handling on BRCMF_FEAT_FWSUP.
- Avoid stale firmware supplicant state when switching between DPP and
non-DPP encrypted connections.
- Preserve SAE password handling while avoiding incorrect PSK offload
selection.
- Track remain-on-channel completion with the correct wireless_dev.
- Add NULL checks in P2P abort/search-channel paths.
Signed-off-by: Kurt Lee <kurt.lee@cypress.com>
Signed-off-by: Jason Huang <jason.huang2@infineon.com>
---
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 157 +++++++++++-------
.../broadcom/brcm80211/brcmfmac/p2p.c | 70 ++++++--
.../broadcom/brcm80211/brcmfmac/p2p.h | 1 +
.../broadcom/brcm80211/include/brcmu_wifi.h | 2 +
4 files changed, 151 insertions(+), 79 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 0b55d445895f..3df7af710a5f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -8,6 +8,7 @@
#include <linux/kernel.h>
#include <linux/etherdevice.h>
#include <linux/module.h>
+#include <linux/unaligned.h>
#include <linux/vmalloc.h>
#include <net/cfg80211.h>
#include <net/netlink.h>
@@ -2174,6 +2175,9 @@ brcmf_set_key_mgmt(struct net_device *ndev, struct cfg80211_connect_params *sme)
val = WPA2_AUTH_PSK | WPA2_AUTH_FT;
profile->is_ft = true;
break;
+ case WLAN_AKM_SUITE_WFA_DPP:
+ val = WFA_AUTH_DPP;
+ break;
default:
bphy_err(drvr, "invalid akm suite (%d)\n",
sme->crypto.akm_suites[0]);
@@ -2483,43 +2487,56 @@ brcmf_cfg80211_connect(struct wiphy *wiphy, struct net_device *ndev,
goto done;
}
- if (sme->crypto.psk &&
- profile->use_fwsup != BRCMF_PROFILE_FWSUP_SAE) {
- if (WARN_ON(profile->use_fwsup != BRCMF_PROFILE_FWSUP_NONE)) {
- err = -EINVAL;
- goto done;
- }
- brcmf_dbg(INFO, "using PSK offload\n");
- profile->use_fwsup = BRCMF_PROFILE_FWSUP_PSK;
- }
-
- if (profile->use_fwsup != BRCMF_PROFILE_FWSUP_NONE) {
- /* enable firmware supplicant for this interface */
- err = brcmf_fil_iovar_int_set(ifp, "sup_wpa", 1);
- if (err < 0) {
- bphy_err(drvr, "failed to enable fw supplicant\n");
- goto done;
+ if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_FWSUP)) {
+ u32 akm = sme->crypto.n_akm_suites ? sme->crypto.akm_suites[0] : 0;
+ bool is_sae_akm = akm == WLAN_AKM_SUITE_SAE ||
+ akm == WLAN_AKM_SUITE_FT_OVER_SAE;
+
+ if (sme->crypto.psk) {
+ if (is_sae_akm &&
+ profile->use_fwsup != BRCMF_PROFILE_FWSUP_SAE) {
+ profile->use_fwsup = BRCMF_PROFILE_FWSUP_NONE;
+ } else if (!is_sae_akm &&
+ profile->use_fwsup != BRCMF_PROFILE_FWSUP_SAE) {
+ if (WARN_ON(profile->use_fwsup !=
+ BRCMF_PROFILE_FWSUP_NONE)) {
+ err = -EINVAL;
+ goto done;
+ }
+ brcmf_dbg(INFO, "using PSK offload\n");
+ profile->use_fwsup = BRCMF_PROFILE_FWSUP_PSK;
+ }
+ } else {
+ profile->use_fwsup = BRCMF_PROFILE_FWSUP_NONE;
}
- }
-
- if (profile->use_fwsup == BRCMF_PROFILE_FWSUP_PSK)
- err = brcmf_set_pmk(ifp, sme->crypto.psk,
- BRCMF_WSEC_MAX_PSK_LEN);
- else if (profile->use_fwsup == BRCMF_PROFILE_FWSUP_SAE) {
- /* clean up user-space RSNE */
- err = brcmf_fil_iovar_data_set(ifp, "wpaie", NULL, 0);
- if (err) {
- bphy_err(drvr, "failed to clean up user-space RSNE\n");
- goto done;
+ if (profile->use_fwsup != BRCMF_PROFILE_FWSUP_NONE) {
+ /* enable firmware supplicant for this interface */
+ err = brcmf_fil_iovar_int_set(ifp, "sup_wpa", 1);
+ if (err < 0) {
+ bphy_err(drvr, "failed to enable fw supplicant\n");
+ goto done;
+ }
+ } else {
+ err = brcmf_fil_iovar_int_set(ifp, "sup_wpa", 0);
}
- err = brcmf_fwvid_set_sae_password(ifp, &sme->crypto);
- if (!err && sme->crypto.psk)
+ if (profile->use_fwsup == BRCMF_PROFILE_FWSUP_PSK)
err = brcmf_set_pmk(ifp, sme->crypto.psk,
BRCMF_WSEC_MAX_PSK_LEN);
+ else if (profile->use_fwsup == BRCMF_PROFILE_FWSUP_SAE &&
+ (sme->crypto.sae_pwd && brcmf_feat_is_enabled(ifp, BRCMF_FEAT_SAE))) {
+ /* clean up user-space RSNE */
+ if (brcmf_fil_iovar_data_set(ifp, "wpaie", NULL, 0)) {
+ bphy_err(drvr, "failed to clean up user-space RSNE\n");
+ goto done;
+ }
+ err = brcmf_fwvid_set_sae_password(ifp, &sme->crypto);
+ if (!err && sme->crypto.psk)
+ err = brcmf_set_pmk(ifp, sme->crypto.psk,
+ BRCMF_WSEC_MAX_PSK_LEN);
+ }
+ if (err)
+ goto done;
}
- if (err)
- goto done;
-
/* Join with specific BSSID and cached SSID
* If SSID is zero join based on BSSID only
*/
@@ -4538,6 +4555,11 @@ static bool brcmf_valid_wpa_oui(u8 *oui, bool is_rsn_ie)
return (memcmp(oui, WPA_OUI, TLV_OUI_LEN) == 0);
}
+static bool brcmf_valid_dpp_suite(u8 *oui)
+{
+ return get_unaligned_be32(oui) == WLAN_AKM_SUITE_WFA_DPP;
+}
+
static s32
brcmf_configure_wpaie(struct brcmf_if *ifp,
const struct brcmf_vs_tlv *wpa_ie,
@@ -4651,42 +4673,47 @@ brcmf_configure_wpaie(struct brcmf_if *ifp,
goto exit;
}
for (i = 0; i < count; i++) {
- if (!brcmf_valid_wpa_oui(&data[offset], is_rsn_ie)) {
+ if (brcmf_valid_dpp_suite(&data[offset])) {
+ wpa_auth |= WFA_AUTH_DPP;
+ offset += TLV_OUI_LEN;
+ } else if (brcmf_valid_wpa_oui(&data[offset], is_rsn_ie)) {
+ offset += TLV_OUI_LEN;
+ switch (data[offset]) {
+ case RSN_AKM_NONE:
+ brcmf_dbg(TRACE, "RSN_AKM_NONE\n");
+ wpa_auth |= WPA_AUTH_NONE;
+ break;
+ case RSN_AKM_UNSPECIFIED:
+ brcmf_dbg(TRACE, "RSN_AKM_UNSPECIFIED\n");
+ is_rsn_ie ?
+ (wpa_auth |= WPA2_AUTH_UNSPECIFIED) :
+ (wpa_auth |= WPA_AUTH_UNSPECIFIED);
+ break;
+ case RSN_AKM_PSK:
+ brcmf_dbg(TRACE, "RSN_AKM_PSK\n");
+ is_rsn_ie ? (wpa_auth |= WPA2_AUTH_PSK) :
+ (wpa_auth |= WPA_AUTH_PSK);
+ break;
+ case RSN_AKM_SHA256_PSK:
+ brcmf_dbg(TRACE, "RSN_AKM_MFP_PSK\n");
+ wpa_auth |= WPA2_AUTH_PSK_SHA256;
+ break;
+ case RSN_AKM_SHA256_1X:
+ brcmf_dbg(TRACE, "RSN_AKM_MFP_1X\n");
+ wpa_auth |= WPA2_AUTH_1X_SHA256;
+ break;
+ case RSN_AKM_SAE:
+ brcmf_dbg(TRACE, "RSN_AKM_SAE\n");
+ wpa_auth |= WPA3_AUTH_SAE_PSK;
+ break;
+ default:
+ bphy_err(drvr, "Invalid key mgmt info\n");
+ }
+ } else {
err = -EINVAL;
bphy_err(drvr, "invalid OUI\n");
goto exit;
}
- offset += TLV_OUI_LEN;
- switch (data[offset]) {
- case RSN_AKM_NONE:
- brcmf_dbg(TRACE, "RSN_AKM_NONE\n");
- wpa_auth |= WPA_AUTH_NONE;
- break;
- case RSN_AKM_UNSPECIFIED:
- brcmf_dbg(TRACE, "RSN_AKM_UNSPECIFIED\n");
- is_rsn_ie ? (wpa_auth |= WPA2_AUTH_UNSPECIFIED) :
- (wpa_auth |= WPA_AUTH_UNSPECIFIED);
- break;
- case RSN_AKM_PSK:
- brcmf_dbg(TRACE, "RSN_AKM_PSK\n");
- is_rsn_ie ? (wpa_auth |= WPA2_AUTH_PSK) :
- (wpa_auth |= WPA_AUTH_PSK);
- break;
- case RSN_AKM_SHA256_PSK:
- brcmf_dbg(TRACE, "RSN_AKM_MFP_PSK\n");
- wpa_auth |= WPA2_AUTH_PSK_SHA256;
- break;
- case RSN_AKM_SHA256_1X:
- brcmf_dbg(TRACE, "RSN_AKM_MFP_1X\n");
- wpa_auth |= WPA2_AUTH_1X_SHA256;
- break;
- case RSN_AKM_SAE:
- brcmf_dbg(TRACE, "RSN_AKM_SAE\n");
- wpa_auth |= WPA3_AUTH_SAE_PSK;
- break;
- default:
- bphy_err(drvr, "Invalid key mgmt info\n");
- }
offset++;
}
@@ -4706,10 +4733,12 @@ brcmf_configure_wpaie(struct brcmf_if *ifp,
*/
if (!(wpa_auth & (WPA2_AUTH_PSK_SHA256 |
WPA2_AUTH_1X_SHA256 |
+ WFA_AUTH_DPP |
WPA3_AUTH_SAE_PSK))) {
err = -EINVAL;
goto exit;
}
+
/* Firmware has requirement that WPA2_AUTH_PSK/
* WPA2_AUTH_UNSPECIFIED be set, if SHA256 OUI
* is to be included in the rsn ie.
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
index 92c16a317328..db942e7eff18 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
@@ -6,6 +6,7 @@
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
#include <linux/rtnetlink.h>
+#include <linux/unaligned.h>
#include <net/cfg80211.h>
#include <brcmu_wifi.h>
@@ -44,9 +45,6 @@
#define BRCMF_SCB_TIMEOUT_VALUE 20
-#define P2P_VER 9 /* P2P version: 9=WiFi P2P v1.0 */
-#define P2P_PUB_AF_CATEGORY 0x04
-#define P2P_PUB_AF_ACTION 0x09
#define P2P_AF_CATEGORY 0x7f
#define P2P_OUI "\x50\x6F\x9A" /* P2P OUI */
#define P2P_OUI_LEN 3 /* P2P OUI length */
@@ -143,10 +141,10 @@ struct brcmf_p2p_scan_le {
/**
* struct brcmf_p2p_pub_act_frame - WiFi P2P Public Action Frame
*
- * @category: P2P_PUB_AF_CATEGORY
- * @action: P2P_PUB_AF_ACTION
+ * @category: WLAN_CATEGORY_PUBLIC
+ * @action: WLAN_PUB_ACTION_VENDOR_SPECIFIC
* @oui: P2P_OUI
- * @oui_type: OUI type - P2P_VER
+ * @oui_type: OUI type - WLAN_OUI_TYPE_WFA_P2P
* @subtype: OUI subtype - P2P_TYPE_*
* @dialog_token: nonzero, identifies req/rsp transaction
* @elts: Variable length information elements.
@@ -166,7 +164,7 @@ struct brcmf_p2p_pub_act_frame {
*
* @category: P2P_AF_CATEGORY
* @oui: OUI - P2P_OUI
- * @type: OUI Type - P2P_VER
+ * @type: OUI Type - WLAN_OUI_TYPE_WFA_P2P
* @subtype: OUI Subtype - P2P_AF_*
* @dialog_token: nonzero, identifies req/resp tranaction
* @elts: Variable length information elements.
@@ -228,10 +226,38 @@ static bool brcmf_p2p_is_pub_action(void *frame, u32 frame_len)
if (frame_len < sizeof(*pact_frm))
return false;
- if (pact_frm->category == P2P_PUB_AF_CATEGORY &&
- pact_frm->action == P2P_PUB_AF_ACTION &&
- pact_frm->oui_type == P2P_VER &&
- memcmp(pact_frm->oui, P2P_OUI, P2P_OUI_LEN) == 0)
+ if (pact_frm->category == WLAN_CATEGORY_PUBLIC &&
+ pact_frm->action == WLAN_PUB_ACTION_VENDOR_SPECIFIC &&
+ pact_frm->oui_type == WLAN_OUI_TYPE_WFA_P2P &&
+ get_unaligned_be24(pact_frm->oui) == WLAN_OUI_WFA)
+ return true;
+
+ return false;
+}
+
+/**
+ * brcmf_p2p_is_dpp_pub_action() - true if dpp public type frame.
+ *
+ * @frame: action frame data.
+ * @frame_len: length of action frame data.
+ *
+ * Determine if action frame is dpp public action type
+ */
+static bool brcmf_p2p_is_dpp_pub_action(void *frame, u32 frame_len)
+{
+ struct brcmf_p2p_pub_act_frame *pact_frm;
+
+ if (!frame)
+ return false;
+
+ pact_frm = (struct brcmf_p2p_pub_act_frame *)frame;
+ if (frame_len < sizeof(struct brcmf_p2p_pub_act_frame) - 1)
+ return false;
+
+ if (pact_frm->category == WLAN_CATEGORY_PUBLIC &&
+ pact_frm->action == WLAN_PUB_ACTION_VENDOR_SPECIFIC &&
+ pact_frm->oui_type == WLAN_OUI_TYPE_WFA_DPP &&
+ get_unaligned_be24(pact_frm->oui) == WLAN_OUI_WFA)
return true;
return false;
@@ -257,7 +283,7 @@ static bool brcmf_p2p_is_p2p_action(void *frame, u32 frame_len)
return false;
if (act_frm->category == P2P_AF_CATEGORY &&
- act_frm->type == P2P_VER &&
+ act_frm->type == WLAN_OUI_TYPE_WFA_P2P &&
memcmp(act_frm->oui, P2P_OUI, P2P_OUI_LEN) == 0)
return true;
@@ -993,6 +1019,8 @@ int brcmf_p2p_remain_on_channel(struct wiphy *wiphy, struct wireless_dev *wdev,
if (err)
goto exit;
+ p2p->remain_on_channel_wdev = wdev;
+
memcpy(&p2p->remain_on_channel, channel, sizeof(*channel));
*cookie = p2p->remain_on_channel_cookie;
cfg80211_ready_on_channel(wdev, *cookie, channel, duration, GFP_KERNEL);
@@ -1016,6 +1044,7 @@ int brcmf_p2p_notify_listen_complete(struct brcmf_if *ifp,
{
struct brcmf_cfg80211_info *cfg = ifp->drvr->config;
struct brcmf_p2p_info *p2p = &cfg->p2p;
+ struct wireless_dev *wdev = p2p->remain_on_channel_wdev;
brcmf_dbg(TRACE, "Enter\n");
if (test_and_clear_bit(BRCMF_P2P_STATUS_DISCOVER_LISTEN,
@@ -1028,10 +1057,16 @@ int brcmf_p2p_notify_listen_complete(struct brcmf_if *ifp,
complete(&p2p->wait_next_af);
}
- cfg80211_remain_on_channel_expired(&ifp->vif->wdev,
+ wdev = p2p->remain_on_channel_wdev ?
+ p2p->remain_on_channel_wdev :
+ &ifp->vif->wdev;
+
+ cfg80211_remain_on_channel_expired(wdev,
p2p->remain_on_channel_cookie,
&p2p->remain_on_channel,
GFP_KERNEL);
+ p2p->remain_on_channel_wdev = NULL;
+
}
return 0;
}
@@ -1283,6 +1318,9 @@ static s32 brcmf_p2p_abort_action_frame(struct brcmf_cfg80211_info *cfg)
brcmf_dbg(TRACE, "Enter\n");
vif = p2p->bss_idx[P2PAPI_BSSCFG_DEVICE].vif;
+ if (!vif)
+ vif = p2p->bss_idx[P2PAPI_BSSCFG_PRIMARY].vif;
+
err = brcmf_fil_bsscfg_data_set(vif->ifp, "actframe_abort", &int_val,
sizeof(s32));
if (err)
@@ -1782,7 +1820,9 @@ bool brcmf_p2p_send_action_frame(struct brcmf_if *ifp,
goto exit;
}
} else if (brcmf_p2p_is_p2p_action(action_frame->data,
- action_frame_len)) {
+ action_frame_len) ||
+ brcmf_p2p_is_dpp_pub_action(action_frame->data,
+ action_frame_len)) {
/* do not configure anything. it will be */
/* sent with a default configuration */
} else {
@@ -1819,6 +1859,7 @@ bool brcmf_p2p_send_action_frame(struct brcmf_if *ifp,
/* validate channel and p2p ies */
if (config_af_params.search_channel &&
IS_P2P_SOCIAL_CHANNEL(le32_to_cpu(af_params->channel)) &&
+ p2p->bss_idx[P2PAPI_BSSCFG_DEVICE].vif &&
p2p->bss_idx[P2PAPI_BSSCFG_DEVICE].vif->saved_ie.probe_req_ie_len) {
afx_hdl = &p2p->afx_hdl;
afx_hdl->peer_listen_chan = le32_to_cpu(af_params->channel);
@@ -2504,7 +2545,6 @@ s32 brcmf_p2p_attach(struct brcmf_cfg80211_info *cfg, bool p2pdev_forced)
pri_ifp = brcmf_get_ifp(cfg->pub, 0);
p2p->bss_idx[P2PAPI_BSSCFG_PRIMARY].vif = pri_ifp->vif;
-
init_completion(&p2p->send_af_done);
if (p2pdev_forced) {
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.h
index 9f3f01ade2b7..ae159b9aef90 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.h
@@ -138,6 +138,7 @@ struct brcmf_p2p_info {
bool block_gon_req_tx;
bool p2pdev_dynamically;
bool wait_for_offchan_complete;
+ struct wireless_dev *remain_on_channel_wdev;
};
s32 brcmf_p2p_attach(struct brcmf_cfg80211_info *cfg, bool p2pdev_forced);
diff --git a/drivers/net/wireless/broadcom/brcm80211/include/brcmu_wifi.h b/drivers/net/wireless/broadcom/brcm80211/include/brcmu_wifi.h
index 7552bdb91991..c465208c4331 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcmu_wifi.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcmu_wifi.h
@@ -233,6 +233,8 @@ static inline bool ac_bitmap_tst(u8 bitmap, int prec)
#define WPA3_AUTH_SAE_PSK 0x40000 /* SAE with 4-way handshake */
+#define WFA_AUTH_DPP 0x200000 /* WFA DPP AUTH */
+
#define DOT11_DEFAULT_RTS_LEN 2347
#define DOT11_DEFAULT_FRAG_LEN 2346
base-commit: 6aded6c10490d5b24325e46f22b327876b669f72
--
2.25.1
^ permalink raw reply related
* [PATCH] ath12k: fix NULL pointer dereference in rhash table destroy
From: Jose Ignacio Tornos Martinez @ 2026-06-04 7:10 UTC (permalink / raw)
To: jjohnson
Cc: linux-wireless, ath12k, linux-kernel,
Jose Ignacio Tornos Martinez, stable
When unbinding the ath12k driver, kernel NULL pointer dereferences
occur in irq_work_sync() called from rhashtable_destroy().
Two hash tables are affected:
1. ath12k_link_sta hash table in ath12k_base
2. ath12k_dp_link_peer hash table in ath12k_dp
The issue happens because the destroy functions are called unconditionally
in cleanup paths, but the hash tables are only initialized late in their
respective init functions. If the device was never fully started or if the
init functions failed before initializing the hash tables, the pointers
will be NULL. The issues are always reproducible from a VM because the MSI
addressing initialization is failing.
Call trace for ath12k_link_sta_rhash_tbl_destroy:
RIP: irq_work_sync+0x1e/0x70
rhashtable_destroy+0x12/0x60
ath12k_link_sta_rhash_tbl_destroy+0x19/0x40 [ath12k]
ath12k_core_stop+0xe/0x80 [ath12k]
ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k]
ath12k_pci_remove+0x60/0x110 [ath12k]
Call trace for ath12k_dp_link_peer_rhash_tbl_destroy:
RIP: irq_work_sync+0x1e/0x70
rhashtable_destroy+0x12/0x60
ath12k_dp_link_peer_rhash_tbl_destroy+0x29/0x50 [ath12k]
ath12k_dp_cmn_device_deinit+0x21/0x140 [ath12k]
ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k]
ath12k_pci_remove+0x60/0x110 [ath12k]
Fix this by adding NULL checks before calling rhashtable_destroy() in
both destroy functions.
Fixes: 57ccca410237 ("wifi: ath12k: Add hash table for ath12k_link_sta in ath12k_base")
Fixes: a88cf5f71adf ("wifi: ath12k: Add hash table for ath12k_dp_link_peer")
Cc: stable@vger.kernel.org
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
drivers/net/wireless/ath/ath12k/dp_peer.c | 5 +++++
drivers/net/wireless/ath/ath12k/peer.c | 3 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/net/wireless/ath/ath12k/dp_peer.c b/drivers/net/wireless/ath/ath12k/dp_peer.c
index a1100782d45e..38045564e223 100644
--- a/drivers/net/wireless/ath/ath12k/dp_peer.c
+++ b/drivers/net/wireless/ath/ath12k/dp_peer.c
@@ -275,9 +275,14 @@ int ath12k_dp_link_peer_rhash_tbl_init(struct ath12k_dp *dp)
void ath12k_dp_link_peer_rhash_tbl_destroy(struct ath12k_dp *dp)
{
mutex_lock(&dp->link_peer_rhash_tbl_lock);
+ if (!dp->rhead_peer_addr)
+ goto unlock;
+
rhashtable_destroy(dp->rhead_peer_addr);
kfree(dp->rhead_peer_addr);
dp->rhead_peer_addr = NULL;
+
+unlock:
mutex_unlock(&dp->link_peer_rhash_tbl_lock);
}
diff --git a/drivers/net/wireless/ath/ath12k/peer.c b/drivers/net/wireless/ath/ath12k/peer.c
index 2e875176baaa..80fee2ce68f1 100644
--- a/drivers/net/wireless/ath/ath12k/peer.c
+++ b/drivers/net/wireless/ath/ath12k/peer.c
@@ -444,6 +444,9 @@ int ath12k_link_sta_rhash_tbl_init(struct ath12k_base *ab)
void ath12k_link_sta_rhash_tbl_destroy(struct ath12k_base *ab)
{
+ if (!ab->rhead_sta_addr)
+ return;
+
rhashtable_destroy(ab->rhead_sta_addr);
kfree(ab->rhead_sta_addr);
ab->rhead_sta_addr = NULL;
--
2.54.0
^ permalink raw reply related
* [PATCH ath-next] wifi: ath12k: enable IEEE80211_VHT_EXT_NSS_BW_CAPABLE when NSS ratio is reported
From: Maharaja Kennadyrajan @ 2026-06-04 9:58 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless, Wen Gong, Maharaja Kennadyrajan
From: Wen Gong <quic_wgong@quicinc.com>
When firmware reports NSS ratio support, SUPPORTS_VHT_EXT_NSS_BW is enabled in
ath12k. However, IEEE80211_VHT_EXT_NSS_BW_CAPABLE must also be set to make the
advertisement valid.
According to IEEE Std 802.11-2024, Subclause 9.4.2.156.3 (Supported VHT-MCS and
NSS Set subfields), the VHT Extended NSS BW Capable bit indicates whether a STA
is capable of interpreting the Extended NSS BW Support subfield of the VHT
capabilities information field. Advertising extended NSS BW support without
setting this capability bit is therefore invalid.
Without this change, mac80211 detects the inconsistency and logs:
ieee80211 phy0: copying sband (band 1) due to VHT EXT NSS BW flag
This indicates that mac80211 implicitly aligns IEEE80211_VHT_EXT_NSS_BW_CAPABLE
during ieee80211_register_hw(). Explicitly setting the bit in ath12k avoids this
fixup and ensures capabilities are advertised correctly by the driver.
This change follows the same approach as the existing ath11k fix.
https://lore.kernel.org/all/20211013073704.15888-1-wgong@codeaurora.org/
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1
Fixes: 18ab9d038fad ("wifi: ath12k: add support for 160 MHz bandwidth")
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/mac.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index a6e4b660da81..af354bef5c0d 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -8489,6 +8489,10 @@ ath12k_create_vht_cap(struct ath12k *ar, u32 rate_cap_tx_chainmask,
vht_cap.vht_supported = 1;
vht_cap.cap = ar->pdev->cap.vht_cap;
+ if (ar->pdev->cap.nss_ratio_enabled)
+ vht_cap.vht_mcs.tx_highest |=
+ cpu_to_le16(IEEE80211_VHT_EXT_NSS_BW_CAPABLE);
+
ath12k_set_vht_txbf_cap(ar, &vht_cap.cap);
/* 80P80 is not supported */
base-commit: 565257a857690244211d85593b2cd490ce86783a
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] wifi: wlcore: Add support for IGTK key
From: Andreas Kemnade @ 2026-06-04 10:08 UTC (permalink / raw)
To: Peter Åstrand; +Cc: linux-wireless
In-Reply-To: <a2040dcc-af47-1de0-b731-defffe3ce4cd@lysator.liu.se>
On Fri, 8 May 2026 15:55:07 +0200 (CEST)
Peter Åstrand <astrand@lysator.liu.se> wrote:
> On Fri, 8 May 2026, Andreas Kemnade wrote:
>
> > Hi,
> >
> > On Fri, 16 Jan 2026 18:58:58 +0100 (CET)
> > Peter Åstrand <astrand@lysator.liu.se> wrote:
> >
> > > This change re-applies commit 2b7aadd3b9e1 ("wlcore: Adding suppoprt for IGTK key in
> > > wlcore driver") (sic), but only enables WLAN_CIPHER_SUITE_AES_CMAC with modern
> > > firmware. This patch is required to support WPA3 connections.
> > >
> >
> > I have seen this after this patch:
> > [ 484.113311] wlcore: WARNING could not set keys
> > [ 484.117828] wlcore: ERROR Could not add or replace key
> > [ 484.123016] wlan0: failed to set key (5, ff:ff:ff:ff:ff:ff) to hardware (-5)
> > [ 484.123046] wlcore: Hardware recovery in progress. FW ver: Rev 7.3.10.0.142
> > [ 484.139923] wlcore: pc: 0x0, hint_sts: 0x00000048 count: 1
> > [ 484.145721] wlcore: down
> > [ 484.148986] ieee80211 phy0: Hardware restart was requested
> > [ 484.610473] wlcore: firmware booted (Rev 7.3.10.0.142)
> > [ 484.633758] wlcore: Association completed.
> > [ 484.690490] wlcore: ERROR command execute failure 14
> > [ 484.690490] ------------[ cut here ]------------
> > [ 484.700195] WARNING: drivers/net/wireless/ti/wlcore/main.c:872 at wl12xx_queue_recovery_work+0x64/0x74 [wlcore], CPU#0: kworker/0:0/892
> >
> > This repeats endlessly.
> > As soon as I set pmf to 1 in wpa_supplciant, once per second. Reverting this patch helps. Seen this
> > on the Epson Moverio BT-200.
>
> Thanks for this feedback. From the firmware version, I assume that this is
> not wl18xx but probably wl12xx? Unfortunately I have no experience with
> that module. So, while my patch is an improvement over the original patch
> because it checks firmware version, it did not consider non-wl18xx
> modules.
>
> I guess we need to throw in something like:
>
> strcmp(pdev_data->family->name, "wl18xx")
>
> ...in the if statement.
>
btw: if the firmware is started for a second time, it will also decrement again.
So after some reboots we end up without any cipher.
And afaik the firmware ups at any ifup.
Regards,
Andreas
^ permalink raw reply
* Re: [PATCH] wifi: wlcore: Add support for IGTK key
From: Johannes Berg @ 2026-06-04 10:23 UTC (permalink / raw)
To: Andreas Kemnade, Peter Åstrand; +Cc: linux-wireless
In-Reply-To: <20260604120834.508f606f@kemnade.info>
> >
> btw: if the firmware is started for a second time, it will also decrement again.
> So after some reboots we end up without any cipher.
> And afaik the firmware ups at any ifup.
Maybe just send a revert for now?
johannes
^ permalink raw reply
* [PATCH] wireless: wlcore: enable the right set of ciphers
From: Andreas Kemnade @ 2026-06-04 10:33 UTC (permalink / raw)
To: johannes.berg, astrand, quic_rdevanat, kees, sakari.ailus,
andreas, linux-wireless, linux-kernel
The firmware version number check for IGTK introduced in
commit c34dbc5900b0 ("wifi: wlcore: Add support for IGTK key")
lets the amount of ciphers decrease on every boot of a too old firmware and
that is practically happening. It also does not take into account other
chips than the wl18xx. On some wl128x, the following can be observed
when connecting via nm to a common ap:
[ 484.113311] wlcore: WARNING could not set keys
[ 484.117828] wlcore: ERROR Could not add or replace key
[ 484.123016] wlan0: failed to set key (5, ff:ff:ff:ff:ff:ff) to hardware (-5)
[ 484.123046] wlcore: Hardware recovery in progress. FW ver: Rev 7.3.10.0.142
[ 484.139923] wlcore: pc: 0x0, hint_sts: 0x00000048 count: 1
[ 484.145721] wlcore: down
[ 484.148986] ieee80211 phy0: Hardware restart was requested
[ 484.610473] wlcore: firmware booted (Rev 7.3.10.0.142)
[ 484.633758] wlcore: Association completed.
[ 484.690490] wlcore: ERROR command execute failure 14
[ 484.690490] ------------[ cut here ]------------
[ 484.700195] WARNING: drivers/net/wireless/ti/wlcore/main.c:872 at wl12xx_queue_recovery_work+0x64/0x74 [wlcore], CPU#0: kworker/0:0/892
This repeats endlessly.
Always disable IGTK on wl12xx and fix the decrementing mess.
Fixes: c34dbc5900b0 ("wifi: wlcore: Add support for IGTK key")
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
drivers/net/wireless/ti/wlcore/main.c | 23 +++++++++++++----------
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 1c340a4a0930..be583ae331c0 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -32,6 +32,15 @@
#define WL1271_BOOT_RETRIES 3
#define WL1271_WAKEUP_TIMEOUT 500
+static const u32 cipher_suites[] = {
+ WLAN_CIPHER_SUITE_WEP40,
+ WLAN_CIPHER_SUITE_WEP104,
+ WLAN_CIPHER_SUITE_TKIP,
+ WLAN_CIPHER_SUITE_CCMP,
+ WL1271_CIPHER_SUITE_GEM,
+ WLAN_CIPHER_SUITE_AES_CMAC,
+};
+
static char *fwlog_param;
static int fwlog_mem_blocks = -1;
static int bug_on_recovery = -1;
@@ -2367,6 +2376,7 @@ static int wl12xx_init_vif_data(struct wl1271 *wl, struct ieee80211_vif *vif)
static int wl12xx_init_fw(struct wl1271 *wl)
{
+ struct wlcore_platdev_data *pdev_data = dev_get_platdata(&wl->pdev->dev);
int retries = WL1271_BOOT_RETRIES;
bool booted = false;
struct wiphy *wiphy = wl->hw->wiphy;
@@ -2421,8 +2431,9 @@ static int wl12xx_init_fw(struct wl1271 *wl)
/* WLAN_CIPHER_SUITE_AES_CMAC must be last in cipher_suites;
support only with firmware 8.9.1 and newer */
- if (wl->chip.fw_ver[FW_VER_MAJOR] < 1)
- wl->hw->wiphy->n_cipher_suites--;
+ if (wl->chip.fw_ver[FW_VER_MAJOR] < 1 ||
+ (!strncmp(pdev_data->family->name, "wl12", 4)))
+ wl->hw->wiphy->n_cipher_suites = ARRAY_SIZE(cipher_suites) - 1;
/*
* Now we know if 11a is supported (info from the NVS), so disable
@@ -6198,14 +6209,6 @@ static void wl1271_unregister_hw(struct wl1271 *wl)
static int wl1271_init_ieee80211(struct wl1271 *wl)
{
int i;
- static const u32 cipher_suites[] = {
- WLAN_CIPHER_SUITE_WEP40,
- WLAN_CIPHER_SUITE_WEP104,
- WLAN_CIPHER_SUITE_TKIP,
- WLAN_CIPHER_SUITE_CCMP,
- WL1271_CIPHER_SUITE_GEM,
- WLAN_CIPHER_SUITE_AES_CMAC,
- };
/* The tx descriptor buffer */
wl->hw->extra_tx_headroom = sizeof(struct wl1271_tx_hw_descr);
--
2.47.3
^ permalink raw reply related
* Re: [PATCH wireless-next v3 2/4] wifi: cfg80211/nl80211: add STA-mode peer probing
From: Johannes Berg @ 2026-06-04 10:40 UTC (permalink / raw)
To: Priyansha Tiwari; +Cc: linux-wireless, quic_drohan
In-Reply-To: <20260507171603.1007812-3-pritiwa@qti.qualcomm.com>
Hi,
I'd already fixed these, but there are other issues in the later
patch(es?), so I'm sending this anyway:
> + * @peer: The peer MAC address (or MLD address for MLO) or %NULL if not
> + * applicable (e.g. for STA/P2P-client)
That should have some indentation.
> @@ -16146,7 +16162,6 @@ static int nl80211_probe_peer(struct sk_buff *skb, struct genl_info *info)
> goto free_msg;
> }
>
> - addr = nla_data(info->attrs[NL80211_ATTR_MAC]);
>
> err = rdev_probe_peer(rdev, dev, addr, &cookie);
that leaves a spurious blank line.
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v3 3/4] wifi: mac80211: implement STA-mode peer probing
From: Johannes Berg @ 2026-06-04 10:47 UTC (permalink / raw)
To: Priyansha Tiwari; +Cc: linux-wireless, quic_drohan
In-Reply-To: <20260507171603.1007812-4-pritiwa@qti.qualcomm.com>
On Thu, 2026-05-07 at 22:46 +0530, Priyansha Tiwari wrote:
> + guard(rcu)();
You're rewriting the whole thing anyway - we have wiphy lock here, so we
don't really need RCU at all. Can just use wiphy_dereference() or
similar below, no?
> + case NL80211_IFTYPE_STATION:
> + case NL80211_IFTYPE_P2P_CLIENT:
> + if (ieee80211_vif_is_mld(&sdata->vif)) {
> + link_id = IEEE80211_LINK_UNSPECIFIED;
> + peer_addr = sdata->vif.cfg.ap_addr;
> + src_addr = sdata->vif.addr;
> + band = 0;
> + sta = sta_info_get(sdata, sdata->vif.cfg.ap_addr);
> + } else {
> + link_id = 0;
> + conf = rcu_dereference(sdata->vif.link_conf[0]);
> + if (!conf)
> + return -ENOLINK;
> + band = conf->chanreq.oper.chan->band;
> + peer_addr = conf->bssid;
> + src_addr = conf->addr;
> + sta = sta_info_get_bss(sdata, peer_addr);
> }
This whole logic seems too much - the non-MLO case really should be a
subset of the MLO case anyway, because e.g. conf->bssid will definitely
be the same as sdata->vif.cfg.ap_addr, so you shouldn't really need
(most of?) this distinction.
Equally I don't think we need link_id=0 in the non-MLO case, fully non-
MLO drivers won't be looking at it anyway, and MLO drivers should be
able to deal with the UNSPECIFIED.
That leaves only really the band to be potentially set differently.
Ideally some unification with the AP side is possible there.
> - band = chanctx_conf->def.chan->band;
> - link_id = 0;
> + qos = sta ? sta->sta.wme : false;
> + fromds = false;
> + break;
I see the check in cfg80211, but it just feels completely wrong to have
to do "sta ? ..." here when it should be connected.
Better to just refuse the operation when there's no 'sta' for the AP
found.
johannes
^ permalink raw reply
* Re: [PATCH wireless-next 3/3] wifi: mac80211: Add 802.3 multicast encapsulation offload support
From: Johannes Berg @ 2026-06-04 10:58 UTC (permalink / raw)
To: Tamizh Chelvam Raja; +Cc: linux-wireless
In-Reply-To: <20260516162900.1981500-4-tamizh.raja@oss.qualcomm.com>
On Sat, 2026-05-16 at 21:59 +0530, Tamizh Chelvam Raja wrote:
> mac80211 currently converts 802.3 multicast packets to 802.11 format before
that line got really long
> @@ -4751,6 +4772,25 @@ static void __ieee80211_subif_start_xmit_8023(struct sk_buff *skb,
> goto out;
> }
>
> + /*
> + * For station mode sta is valid even though dest address
> + * is multicast and that will be sent in eth mode only.
> + * So, add error check for sta pointer before choosing
> + * multicast offload path.
> + */
> + if (IS_ERR_OR_NULL(sta) &&
> + unlikely(ieee80211_check_mcast_offload(sdata, skb))) {
That's not really a good way to write a comment ... it's describing the
_change_, not the _state_. Also the code inside the if:
> + sta = NULL;
> + if (ieee80211_vif_get_num_mcast_if(sdata) <= 0) {
> + /* No associated STAs - no need to send multicast frames. */
> + kfree_skb(skb);
> + goto out;
> + }
> + link = &sdata->deflink;
> + key = rcu_dereference(link->default_multicast_key);
> + goto tx_offload;
> + }
is clearly for AP mode, so I'm not really sure what you intended to say
there.
Also don't really like yet another goto in this function, especially
with the ones that are there now, it's really confusing. There are only
a few lines that can be in an else branch?
johannes
^ permalink raw reply
* Re: [PATCH wireless-next 1/2] wifi: nl80211: Add NL80211_ATTR_MAX_CH_SWITCH_TIME attribute
From: Johannes Berg @ 2026-06-04 11:02 UTC (permalink / raw)
To: Shashikala Prabhu
Cc: linux-wireless, vikram, kiranv, pshashik, cgopi, ybasamma,
vthiagar, sivad, uvignesh, mohathan, abishekg
In-Reply-To: <20260518103106.1462604-2-shashikala.prabhu@oss.qualcomm.com>
On Mon, 2026-05-18 at 16:01 +0530, Shashikala Prabhu wrote:
> From: Chandru Gopi <cgopi@qti.qualcomm.com>
>
> IEEE Std 802.11-2024 subclause 9.4.2.216 (Max Channel Switch Time element)
> defines a Switch Time field in the Channel Switch Announcement (CSA)
> element that indicates the time delta between the time the last beacon
> is transmitted by the AP in the current channel and the expected time
> of the first beacon transmitted by the AP in the new channel.
>
> Add a new u32 nl80211 attribute, NL80211_ATTR_MAX_CH_SWITCH_TIME,
> to carry this value in the NL80211_CMD_CH_SWITCH_STARTED_NOTIFY
> event. Userspace can use this information to decide whether to
> remain connected or disconnect before the AP moves to the new
> channel.
This really confused me a lot because that event is used on both sides
... don't include the new netlink attribute when it's on the AP side.
Also bad split with the patches - make one cfg/nl80211 API patch, and
one mac80211 patch.
> NL80211_ATTR_NPCA_PUNCT_BITMAP,
>
> + NL80211_ATTR_MAX_CH_SWITCH_TIME,
> /* add attributes here, update the policy in nl80211.c */
nit: looks odd without the blank line
> +++ b/net/wireless/nl80211.c
> @@ -1093,6 +1093,7 @@ static const struct nla_policy nl80211_policy[NUM_NL80211_ATTR] = {
> [NL80211_ATTR_NPCA_PRIMARY_FREQ] = { .type = NLA_U32 },
> [NL80211_ATTR_NPCA_PUNCT_BITMAP] =
> NLA_POLICY_FULL_RANGE(NLA_U32, &nl80211_punct_bitmap_range),
> + [NL80211_ATTR_MAX_CH_SWITCH_TIME] = { .type = NLA_U32 },
That seems wrong since it's output only, it shouldn't even be accepted
on input.
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v2 02/31] wifi: mm81x: add command.c
From: Johannes Berg @ 2026-06-04 11:32 UTC (permalink / raw)
To: Lachlan Hodges, Dan Callaghan, Arien Judge
Cc: ayman.grais, linux-wireless, linux-kernel
In-Reply-To: <20260430045615.334669-3-lachlan.hodges@morsemicro.com>
On Thu, 2026-04-30 at 14:55 +1000, Lachlan Hodges wrote:
>
> +#define INIT_CMD_HDR(_req, _cmd, _vif_id) \
> + ((struct host_cmd_header){ \
> + .flags = cpu_to_le16(0), \
nit: you probably don't need the zeroes
nit2: maybe you want to use tabs instead of spaces
> + if (!cmd_q)
> + /* No control pageset, not supported by FW */
> + return -ENODEV;
have to say I'm not a huge fan of this style, it always flares up a
warning in my head at first "are there missing braces?" ;-)
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v2 06/31] wifi: mm81x: add core.h
From: Johannes Berg @ 2026-06-04 11:39 UTC (permalink / raw)
To: Lachlan Hodges, Dan Callaghan, Arien Judge
Cc: ayman.grais, linux-wireless, linux-kernel
In-Reply-To: <20260430045615.334669-7-lachlan.hodges@morsemicro.com>
On Thu, 2026-04-30 at 14:55 +1000, Lachlan Hodges wrote:
>
> +#define KHZ_TO_HZ(x) ((x) * 1000)
> +#define KHZ100_TO_MHZ(x) ((x) / 10)
> +#define KHZ100_TO_KHZ(freq) ((freq) * 100)
> +#define KHZ100_TO_HZ(freq) ((freq) * 100000)
Maybe not right now, but at least the first one seems fairly generic and
could be elsewhere.
> +static inline u32 mm81x_fle32_to_cpu(u32 v)
> +{
> + return le32_to_cpu((__force __le32)v);
> +}
> +
> +static inline u16 mm81x_fle16_to_cpu(u16 v)
> +{
> + return le16_to_cpu((__force __le16)v);
> +}
The whole __force thing here seems odd, why isn't the input 'v' just
__le16?
This goes with all the FW loader thing - but that also has all __force.
I'd argue it'd be better to just have separate FW-endian (little endian)
and host-endian structures, even if that duplicates the structure
definitions, but it'll have sparse actually checking the fields were all
converted correctly rather than
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v2 06/31] wifi: mm81x: add core.h
From: Johannes Berg @ 2026-06-04 11:40 UTC (permalink / raw)
To: Lachlan Hodges, Dan Callaghan, Arien Judge
Cc: ayman.grais, linux-wireless, linux-kernel
In-Reply-To: <20260430045615.334669-7-lachlan.hodges@morsemicro.com>
On Thu, 2026-04-30 at 14:55 +1000, Lachlan Hodges wrote:
>
> +#define KHZ_TO_HZ(x) ((x) * 1000)
> +#define KHZ100_TO_MHZ(x) ((x) / 10)
> +#define KHZ100_TO_KHZ(freq) ((freq) * 100)
> +#define KHZ100_TO_HZ(freq) ((freq) * 100000)
Maybe not right now, but at least the first one seems fairly generic and
could be elsewhere.
> +static inline u32 mm81x_fle32_to_cpu(u32 v)
> +{
> + return le32_to_cpu((__force __le32)v);
> +}
> +
> +static inline u16 mm81x_fle16_to_cpu(u16 v)
> +{
> + return le16_to_cpu((__force __le16)v);
> +}
The whole __force thing here seems odd, why isn't the input 'v' just
__le16?
This goes with all the FW loader thing - but that also has all __force.
I'd argue it'd be better to just have separate FW-endian (little endian)
and host-endian structures, even if that duplicates the structure
definitions, but it'll have sparse actually checking the fields were all
converted correctly rather than casting a little endian structure to
host endian and then doing the conversions:
mm81x_elf_phdr *p = (mm81x_elf_phdr *)(fw->data + ehdr.e_phoff +
i * ehdr.e_phentsize);
phdr.p_type = le32_to_cpu((__force __le32)p->p_type);
(sorry about the partial email I think I sent, that was an accident)
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v2 10/31] wifi: mm81x: add hw.c
From: Johannes Berg @ 2026-06-04 11:42 UTC (permalink / raw)
To: Lachlan Hodges, Dan Callaghan, Arien Judge
Cc: ayman.grais, linux-wireless, linux-kernel
In-Reply-To: <20260430045615.334669-11-lachlan.hodges@morsemicro.com>
On Thu, 2026-04-30 at 14:55 +1000, Lachlan Hodges wrote:
>
> + *((u16 *)&mors->macaddr[0]) = (mac1 & MM81X_OTP_MAC_ADDR_1_MASK) >> 16;
> + *((u32 *)&mors->macaddr[2]) = mac2;
This is an alignment fault waiting to happen, better to build byte-by-
byte perhaps, or at least use put_unaligned_...()
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v2 12/31] wifi: mm81x: add mac.c
From: Johannes Berg @ 2026-06-04 11:46 UTC (permalink / raw)
To: Lachlan Hodges, Dan Callaghan, Arien Judge, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt
Cc: ayman.grais, linux-wireless, linux-kernel, llvm
In-Reply-To: <20260430045615.334669-13-lachlan.hodges@morsemicro.com>
> +static void mm81x_mac_ops_flush(struct ieee80211_hw *hw,
> + struct ieee80211_vif *vif, u32 queues,
> + bool drop)
> +{
> + struct mm81x *mors = hw->priv;
> +
> + /* We don't support IEEE80211_HW_QUEUE_CONTROL so flush all queues */
> + if (drop) {
> + /*
> + * No need to call mm81x_skbq_stop_tx_queues as mac80211
> + * has already cancelled each queue prior to calling .flush()
> + */
> + mm81x_skbq_data_traffic_pause(mors);
> +
> + flush_work(&mors->hif_work);
> + flush_work(&mors->tx_stale_work);
> +
> + mm81x_hif_clear_events(mors);
> + mm81x_hif_flush_tx_data(mors);
> + mm81x_hif_flush_cmds(mors);
> +
> + /* Reenable data, not that there will be any */
> + mm81x_skbq_data_traffic_resume(mors);
> + }
> +}
Doing nothing in the !drop case seems questionable - mac80211 uses this
sometimes to e.g. make sure a deauth frame really went out before
shutting down the hardware.
> +static void mm81x_mac_ops_sta_rc_update(struct ieee80211_hw *hw,
> + struct ieee80211_vif *vif,
> + struct ieee80211_link_sta *link_sta,
> + u32 changed)
> +{
> + struct mm81x *mors = hw->priv;
> + struct ieee80211_sta *sta = link_sta->sta;
> + enum ieee80211_sta_state old_state;
> + enum ieee80211_sta_state new_state;
> +
> + dev_dbg(mors->dev,
> + "Rate control config updated (changed %u, peer address %pM)",
> + changed, sta->addr);
> +
> + if (!(changed & IEEE80211_RC_BW_CHANGED))
> + return;
> +
> + /*
> + * Simulate the disconnection and connection to reinitialize the sta
> + * in mmrc with new BW
> + */
> + old_state = IEEE80211_STA_ASSOC;
> + new_state = IEEE80211_STA_NOTEXIST;
No real objection since it's driver internal, but note that this
transition is normally impossible from mac80211 since it doesn't go
through the intermediate states.
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v2 13/31] wifi: mm81x: add mac.h
From: Johannes Berg @ 2026-06-04 11:48 UTC (permalink / raw)
To: Lachlan Hodges, Dan Callaghan, Arien Judge
Cc: ayman.grais, linux-wireless, linux-kernel
In-Reply-To: <20260430045615.334669-14-lachlan.hodges@morsemicro.com>
On Thu, 2026-04-30 at 14:55 +1000, Lachlan Hodges wrote:
>
> +static inline bool mm81x_mac_is_sta_vif_associated(struct ieee80211_vif *vif)
> +{
> + return vif->cfg.assoc;
> +}
> +static inline u16 mm81x_mac_sta_aid(struct ieee80211_vif *vif)
> +{
> + return vif->cfg.aid;
> +}
Heh. Those function names seem way longer than the implementations, but
YMMV :)
> +
> +static inline __le32 mac2leuint32(const unsigned char *addr)
"le32" rather than "leuint32" might be more understandable, but perhaps
this should also come with a comment about dropping the two octets or
something?
johannes
^ permalink raw reply
* Re: [PATCH wireless-next] wifi: mac80211: fold tid_ampdu_rx allocations into a flexible array
From: Johannes Berg @ 2026-06-04 12:20 UTC (permalink / raw)
To: Rosen Penev, linux-wireless; +Cc: open list
In-Reply-To: <20260604001427.16466-1-rosenp@gmail.com>
On Wed, 2026-06-03 at 17:14 -0700, Rosen Penev wrote:
> Convert the separately-allocated reorder_buf pointer to a C99 flexible
> array member at the end of struct tid_ampdu_rx, and place reorder_time
> in the same allocation immediately after it. This collapses three
> allocations into one and removes the corresponding kfree() pairs from
> the error and free paths.
As I pointed out before, I'm not a huge fan of these "doing a minor
improvement for the sake of it" contributions ...
> @@ -241,7 +241,6 @@ struct tid_ampdu_rx {
> struct rcu_head rcu_head;
> spinlock_t reorder_lock;
> u64 reorder_buf_filtered;
> - struct sk_buff_head *reorder_buf;
> unsigned long *reorder_time;
> struct sta_info *sta;
> struct timer_list session_timer;
> @@ -256,6 +255,7 @@ struct tid_ampdu_rx {
> u8 auto_seq:1,
> removed:1,
> started:1;
> + struct sk_buff_head reorder_buf[];
Given that sizeof(unsigned long) == sizeof(void *), that would probably
be far simpler as
struct {
struct sk_buf_head buf;
unsigned long time;
} reorder[];
or so.
johannes
^ permalink raw reply
* Re: [PATCH] wifi: wlcore: Add support for IGTK key
From: Andreas Kemnade @ 2026-06-04 13:39 UTC (permalink / raw)
To: Johannes Berg; +Cc: Peter Åstrand, linux-wireless
In-Reply-To: <ba6e767a75b02c11d4bec542c971c1affda77df9.camel@sipsolutions.net>
Hi,
On Thu, 04 Jun 2026 12:23:50 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:
> > >
> > btw: if the firmware is started for a second time, it will also decrement again.
> > So after some reboots we end up without any cipher.
> > And afaik the firmware ups at any ifup.
>
> Maybe just send a revert for now?
>
I was preparing something while you wrote this. Do want anything simplier for
now?
Regards,
Andreas
^ 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