* Re: [PATCH v3] wifi: ath11k: move .max_tx_ring to struct ath11k_hw_hal_params
From: Alex G. @ 2026-01-15 4:43 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan, jjohnson, ath11k, Jeff Johnson
Cc: baochen.qiang, linux-wireless, linux-kernel
In-Reply-To: <89a61ef1-3e83-4303-ba04-cf5c5a4aae56@oss.qualcomm.com>
On Wednesday, January 14, 2026 3:59:09 PM CST Jeff Johnson wrote:
> On 1/14/2026 1:29 PM, Alex G. wrote:
> > On Wednesday, January 14, 2026 11:24:19 AM CST Jeff Johnson wrote:
> >> On 1/12/2026 11:00 PM, Vasanthakumar Thiagarajan wrote:
> >>> On 12/28/2025 8:44 PM, Alexandru Gagniuc wrote:
> >>>> ".max_tx_ring" is an upper bounds to indexing ".tcl2wbm_rbm_map". It
> >>>> is initialized in, core.c, a different file than the array. This
> >>>> spaghetti-like relation is fragile and not obvious. Accidentally
> >>>> setting ".max_tx_ring" too high leads to a hard to track out-of-
> >>>> bounds access and memory corruption.
> >>>>
> >>>> There is a small ambiguity on the meaning of "max_tx_ring":
> >>>> - The highest ring, max=3 implies there are 4 rings (0, 1, 2, 3)
> >>>> - The highest number to use for array indexing (there are 3 rings)
> >>>>
> >>>> Clarify this dependency by moving ".max_tx_ring" adjacent to the array
> >>>> ".tcl2wbm_rbm_map", and name it "num_tx_rings". Use ARRAY_SIZE()
> >>>> instead of #defines to initialize the length field.
> >>>>
> >>>> The ath11k_hw_hal_params_qca6390 uses fewer num_tx_rings than its map,
> >>>> so use a constant to express the correct value. Add a static_assert()
> >>>> to fail compilation if the constant is accidentally set too high.
> >>>
> >>> Text related to static_assert to be removed accordingly.
> >
> > Hi Jeff,
> >
> >> I removed the last sentence in 'pending', please check:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/commit/?h=pen
> >> din g&id=26bb149b5e011b0f73f7b74421589cbd38e3304b
> >
> > Re-reading the commit message, I think it makes sense to also remove the
> > sentence "The ath11k_hw_hal_params_qca6390 uses fewer num_tx_rings than
> > its
> > map, so use a constant to express the correct value.". Do you think it's
> > worth submitting a v4 with this minor change?
> >
> > Alex
>
> No need to submit a v4. I can make that change in 'pending'
Thank you!
> /jeff
^ permalink raw reply
* pull-request: rtw-next-2026-01-15
From: Ping-Ke Shih @ 2026-01-15 1:56 UTC (permalink / raw)
To: linux-wireless
Hi,
As thread [1], I'd apply WQ_PERCPU patch for rtw88 [2], and I suppose I
have another pull-request before merge windows for -next.
Please pull and let me know if any problems.
[1] https://lore.kernel.org/linux-wireless/CAAofZF4+nDAWQrKEPTwR9vtfECevdjm=nsXR+5wUwGQCzsv=SA@mail.gmail.com/T/#m0c4044a9b6a18337333a2b5a94131c1396bbe5fe
[2] https://patchwork.kernel.org/project/linux-wireless/patch/20251113160605.381777-3-marco.crivellari@suse.com/
Thanks
Ping-Ke
---
The following changes since commit 8f7aa3d3c7323f4ca2768a9e74ebbe359c4f8f88:
Merge tag 'net-next-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next (2025-12-03 17:24:33 -0800)
are available in the Git repository at:
https://github.com/pkshih/rtw.git tags/rtw-next-2026-01-15
for you to fetch changes up to 5e632c7ca9e15a1bc1e114bcfd5210add909e7a4:
wifi: rtw89: pci: consider RTL8922D in PCI common flow (2026-01-15 09:20:28 +0800)
----------------------------------------------------------------
rtw-next patches for -next release.
Main changes are to prepare to support RTL8922DE, including refactor/add
register settings in common flow, and add newly firmware command/event
handlers.
Others are some random fixes and improvements across all drivers.
----------------------------------------------------------------
Ali Tariq (1):
wifi: rtl8xxxu: fix slab-out-of-bounds in rtl8xxxu_sta_add
Bitterblue Smith (4):
wifi: rtw88: 8822b: Avoid WARNING in rtw8822b_config_trx_mode()
wifi: rtw88: Fix alignment fault in rtw_core_enable_beacon()
wifi: rtw88: Use devm_kmemdup() in rtw_set_supported_band()
wifi: rtw88: Fix inadvertent sharing of struct ieee80211_supported_band data
Chia-Yuan Li (1):
wifi: rtw89: coex: update coex software control for RTL8922D
Chih-Kang Chang (7):
wifi: rtw89: refine C2H reg event polling timeout for LPS
wifi: rtw89: setting TBTT AGG number when mac port initialization
wifi: rtw89: mcc: reset probe counter when receiving beacon
wifi: rtw89: refine TX nulldata judgement when scan with 2 OP channels
wifi: rtw89: 8922a: configure FW version for SCAN_OFFLOAD_EXTRA_OP feature
wifi: rtw89: rfk: add rtw89_fw_h2c_rf_pre_ntfy_mcc for new WiFi 7 firmware
wifi: rtw89: rfk: update rtw89_fw_h2c_rf_pre_ntfy_mcc format
Chin-Yen Lee (4):
wifi: rtw89: wow: use struct style to fill WOW CAM H2C command
wifi: rtw89: wow: add WOW_CAM update function for 8922D
wifi: rtw89: wow: abstract DMA check register for RTL8922DE
wifi: rtw89: wow: add reason codes for disassociation in WoWLAN mode
Dian-Syuan Yang (2):
wifi: rtw89: enhance connection stability when triggering beacon loss
wifi: rtw89: 8852b: refine hardware parameters for RFE type 5
Hsiu-Ming Chang (1):
wifi: rtw88: rtw8821cu: Add ID for Mercusys MU6H
Jan Gerber (1):
wifi: rtw89: 8852au: add support for TP TX30U Plus
Jose Ignacio Tornos Martinez (1):
wifi: rtw89: 8922a: set random mac if efuse contains zeroes
Kuan-Chung Chen (6):
wifi: rtw89: 8852b: increase beacon loss to 6 seconds
wifi: rtw89: mlo: fix missing TX null-data 1 during link switch
wifi: rtw89: mlo: fix incorrect link address in management frames
wifi: rtw89: define TX/RX aggregation and MPDU capability per chip
wifi: rtw89: fix potential zero beacon interval in beacon tracking
wifi: rtw89: support EHT GI/LTF setting
Marco Crivellari (1):
wifi: rtw89: add WQ_PERCPU to alloc_workqueue users
Martin Hrůza (1):
wifi: rtw88: Increase the RX gain before scanning
Ping-Ke Shih (36):
wifi: rtw89: correct use sequence of driver_data in skb->info
wifi: rtw89: mac: reset power state before switching to power on
wifi: rtw89: warn unexpected polling value of XTAL SI
wifi: rtw89: wow: change type of WoWLAN pattern mask to __le32
wifi: rtw89: efuse: read hardware version from efuse for WiFi 7 chips
wifi: rtw89: read chip ID for RTL8922D variants
wifi: rtw89: add default quirks as features to chip_info
wifi: rtw89: rfk: update RFK pre info V2 for RTL8922D
wifi: rtw89: update TXWD v3 for RTL8922D
wifi: rtw89: update query RXDESC v3 for RTL8922D
wifi: rtw89: fw: add DMAC v3 H2C command for RTL8922D
wifi: rtw89: fw: add CMAC H2C command to initialize default value for RTL8922D
wifi: rtw89: fw: add CMAC H2C command for association for RTL8922D
wifi: rtw89: fw: add CMAC H2C command for TX AMPDU for RTL8922D
wifi: rtw89: fw: add CMAC H2C command for TX time for RTL8922D
wifi: rtw89: fw: add CMAC H2C command for punctured for RTL8922D
wifi: rtw89: fw: consider hardware AID for firmware elements
wifi: rtw89: fw: set RACK bit every 4 H2C command for WiFi 6 chips only
wifi: rtw89: coex: make coex scoreboard as chip info
wifi: rtw89: coex: update scoreboard value according to power state for two BT
wifi: rtw89: mac: remove unnecessary return from rtw89_fwdl_secure_idmem_share_mode()
wifi: rtw89: mac: add dle_mem and ple_{min,max}_qt quota for RTL8922D
wifi: rtw89: mac: set quota 13 for PLE SNRPT
wifi: rtw89: mac: update MPDU quota according to chip DLE definition
wifi: rtw89: mac: update WP quota for RTL8922D
wifi: rtw89: mac: define preload_init for generations
wifi: rtw89: mac: configure DMA_STOP1 by predefined mask
wifi: rtw89: mac: separate functions of CMAC power and function enable
wifi: rtw89: mac: add an entry to enable MAC function in preinit
wifi: rtw89: mac: set EDCCA configurations for RTL8922D
wifi: rtw89: pci: validate sequence number of TX release report
wifi: rtw89: disable EHT protocol by chip capabilities
wifi: rtw89: align CUSTID defined by firmware
wifi: rtw89: mac: correct page number for CSI response
wifi: rtw89: mac: consider RTL8922D in MAC common flow
wifi: rtw89: pci: consider RTL8922D in PCI common flow
Rohit Chourasia (1):
wifi: rtlwifi: fix typo 'received' in comment
Roman Peshkichev (1):
wifi: rtw88: fix DTIM period handling when conf->dtim_period is zero
Zenm Chen (2):
wifi: rtw89: Add support for MSI AX1800 Nano (GUAX18N)
wifi: rtw89: Add support for D-Link VR Air Bridge (DWA-F18)
Zong-Zhe Yang (11):
wifi: rtw89: ser: enable error IMR after recovering from L1
wifi: rtw89: ser: L1 skip polling status if FW runs event mode
wifi: rtw89: debug: add ser_counters dbgfs
wifi: rtw89: debug: support SER L0/L1 simulation via halt H2C
wifi: rtw89: regd: 6 GHz power type marks default when inactive
wifi: rtw89: pre-handle RF calibration on link when needed
wifi: rtw89: fw: change FW feature map to a BITMAP
wifi: rtw89: fw: introduce helper for disabling FW feature configuration
wifi: rtw89: 8922a: tweak RFK_PRE_NOTIFY FW feature configuration to align handling
wifi: rtw89: refine mis-ordered entries in FW feature table
wifi: rtw89: fw: change WITH_RFK_PRE_NOTIFY to be a FW feature group
drivers/net/wireless/realtek/rtl8xxxu/core.c | 1 +
drivers/net/wireless/realtek/rtlwifi/regd.c | 2 +-
drivers/net/wireless/realtek/rtw88/main.c | 54 +-
drivers/net/wireless/realtek/rtw88/main.h | 2 +-
drivers/net/wireless/realtek/rtw88/phy.c | 20 +
drivers/net/wireless/realtek/rtw88/phy.h | 2 +
drivers/net/wireless/realtek/rtw88/rtw8821cu.c | 2 +
drivers/net/wireless/realtek/rtw88/rtw8822b.c | 3 +-
drivers/net/wireless/realtek/rtw89/cam.c | 134 ++++
drivers/net/wireless/realtek/rtw89/cam.h | 129 +++
drivers/net/wireless/realtek/rtw89/chan.c | 38 +-
drivers/net/wireless/realtek/rtw89/chan.h | 2 +
drivers/net/wireless/realtek/rtw89/core.c | 237 +++++-
drivers/net/wireless/realtek/rtw89/core.h | 158 +++-
drivers/net/wireless/realtek/rtw89/debug.c | 79 ++
drivers/net/wireless/realtek/rtw89/efuse.c | 4 -
drivers/net/wireless/realtek/rtw89/efuse.h | 6 +
drivers/net/wireless/realtek/rtw89/efuse_be.c | 26 +
drivers/net/wireless/realtek/rtw89/fw.c | 866 +++++++++++++++++++--
drivers/net/wireless/realtek/rtw89/fw.h | 333 ++++++--
drivers/net/wireless/realtek/rtw89/mac.c | 176 ++++-
drivers/net/wireless/realtek/rtw89/mac.h | 79 +-
drivers/net/wireless/realtek/rtw89/mac80211.c | 40 +-
drivers/net/wireless/realtek/rtw89/mac_be.c | 675 ++++++++++++++--
drivers/net/wireless/realtek/rtw89/pci.c | 7 +-
drivers/net/wireless/realtek/rtw89/pci.h | 56 +-
drivers/net/wireless/realtek/rtw89/pci_be.c | 136 +++-
drivers/net/wireless/realtek/rtw89/phy.c | 47 +-
drivers/net/wireless/realtek/rtw89/ps.c | 2 +-
drivers/net/wireless/realtek/rtw89/reg.h | 566 +++++++++++++-
drivers/net/wireless/realtek/rtw89/regd.c | 1 +
drivers/net/wireless/realtek/rtw89/rtw8851b.c | 9 +-
drivers/net/wireless/realtek/rtw89/rtw8852a.c | 9 +-
drivers/net/wireless/realtek/rtw89/rtw8852au.c | 4 +
drivers/net/wireless/realtek/rtw89/rtw8852b.c | 31 +-
.../net/wireless/realtek/rtw89/rtw8852b_common.c | 2 -
drivers/net/wireless/realtek/rtw89/rtw8852bt.c | 7 +
drivers/net/wireless/realtek/rtw89/rtw8852bu.c | 2 +
drivers/net/wireless/realtek/rtw89/rtw8852c.c | 9 +-
drivers/net/wireless/realtek/rtw89/rtw8922a.c | 31 +-
drivers/net/wireless/realtek/rtw89/rtw8922a_rfk.c | 48 +-
drivers/net/wireless/realtek/rtw89/ser.c | 10 +
drivers/net/wireless/realtek/rtw89/txrx.h | 22 +
drivers/net/wireless/realtek/rtw89/usb.c | 2 +-
drivers/net/wireless/realtek/rtw89/wow.c | 8 +-
drivers/net/wireless/realtek/rtw89/wow.h | 1 +
46 files changed, 3681 insertions(+), 397 deletions(-)
^ permalink raw reply
* Re: [PATCH rtw-next 1/8] wifi: rtw89: pci: validate sequence number of TX release report
From: Ping-Ke Shih @ 2026-01-15 1:39 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless; +Cc: timlee, damon.chen
In-Reply-To: <20260110022019.2254969-2-pkshih@realtek.com>
Ping-Ke Shih <pkshih@realtek.com> wrote:
> Hardware rarely reports abnormal sequence number in TX release report,
> which will access out-of-bounds of wd_ring->pages array, causing NULL
> pointer dereference.
>
> BUG: kernel NULL pointer dereference, address: 0000000000000000
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x0000) - not-present page
> PGD 0 P4D 0
> Oops: 0000 [#1] PREEMPT SMP NOPTI
> CPU: 1 PID: 1085 Comm: irq/129-rtw89_p Tainted: G S U
> 6.1.145-17510-g2f3369c91536 #1 (HASH:69e8 1)
> Call Trace:
> <IRQ>
> rtw89_pci_release_tx+0x18f/0x300 [rtw89_pci (HASH:4c83 2)]
> rtw89_pci_napi_poll+0xc2/0x190 [rtw89_pci (HASH:4c83 2)]
> net_rx_action+0xfc/0x460 net/core/dev.c:6578 net/core/dev.c:6645 net/core/dev.c:6759
> handle_softirqs+0xbe/0x290 kernel/softirq.c:601
> ? rtw89_pci_interrupt_threadfn+0xc5/0x350 [rtw89_pci (HASH:4c83 2)]
> __local_bh_enable_ip+0xeb/0x120 kernel/softirq.c:499 kernel/softirq.c:423
> </IRQ>
> <TASK>
> rtw89_pci_interrupt_threadfn+0xf8/0x350 [rtw89_pci (HASH:4c83 2)]
> ? irq_thread+0xa7/0x340 kernel/irq/manage.c:0
> irq_thread+0x177/0x340 kernel/irq/manage.c:1205 kernel/irq/manage.c:1314
> ? thaw_kernel_threads+0xb0/0xb0 kernel/irq/manage.c:1202
> ? irq_forced_thread_fn+0x80/0x80 kernel/irq/manage.c:1220
> kthread+0xea/0x110 kernel/kthread.c:376
> ? synchronize_irq+0x1a0/0x1a0 kernel/irq/manage.c:1287
> ? kthread_associate_blkcg+0x80/0x80 kernel/kthread.c:331
> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
> </TASK>
>
> To prevent crash, validate rpp_info.seq before using.
>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
8 patch(es) applied to rtw-next branch of rtw.git, thanks.
957eda596c76 wifi: rtw89: pci: validate sequence number of TX release report
2fd8f953f251 wifi: rtw89: wow: add reason codes for disassociation in WoWLAN mode
432b26382db2 wifi: rtw89: support EHT GI/LTF setting
7fd36ffedeed wifi: rtw89: disable EHT protocol by chip capabilities
91fb4007018f wifi: rtw89: align CUSTID defined by firmware
aa2a44d0d22d wifi: rtw89: mac: correct page number for CSI response
8e47ae078693 wifi: rtw89: mac: consider RTL8922D in MAC common flow
5e632c7ca9e1 wifi: rtw89: pci: consider RTL8922D in PCI common flow
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH v2 1/3] sdio: Provide a bustype shutdown function
From: Shawn Lin @ 2026-01-15 1:26 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: shawn.lin, linux-wireless, linux-mmc, Ulf Hansson, Ping-Ke Shih,
Johannes Berg
In-Reply-To: <397f45c2818f6632151f92b70e547262f373c3b6.1768232321.git.u.kleine-koenig@baylibre.com>
在 2026/01/12 星期一 23:46, Uwe Kleine-König 写道:
> To prepare sdio drivers to migrate away from struct device_driver::shutdown
> (and then eventually remove that callback) create a serdev driver shutdown
/s/serdev driver/sdio driver ?
> callback and migration code to keep the existing behaviour. Note this
> introduces a warning for each driver that isn't converted yet to that
> callback at register time.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> ---
> drivers/mmc/core/sdio_bus.c | 25 +++++++++++++++++++++++++
> include/linux/mmc/sdio_func.h | 1 +
> 2 files changed, 26 insertions(+)
>
> diff --git a/drivers/mmc/core/sdio_bus.c b/drivers/mmc/core/sdio_bus.c
> index 10799772494a..6e5bdc2f0cc8 100644
> --- a/drivers/mmc/core/sdio_bus.c
> +++ b/drivers/mmc/core/sdio_bus.c
> @@ -232,6 +232,15 @@ static void sdio_bus_remove(struct device *dev)
> pm_runtime_put_sync(dev);
> }
>
> +static void sdio_bus_shutdown(struct device *dev)
> +{
> + struct sdio_driver *drv = to_sdio_driver(dev->driver);
> + struct sdio_func *func = dev_to_sdio_func(dev);
> +
> + if (dev->driver && drv->shutdown)
> + drv->shutdown(func);
> +}
Seem bogus check as a few line ahead, you used dev->driver to get
sdio_driver already. Otherwise the reset looks good.
> +
> static const struct dev_pm_ops sdio_bus_pm_ops = {
> SET_SYSTEM_SLEEP_PM_OPS(pm_generic_suspend, pm_generic_resume)
> SET_RUNTIME_PM_OPS(
> @@ -248,6 +257,7 @@ static const struct bus_type sdio_bus_type = {
> .uevent = sdio_bus_uevent,
> .probe = sdio_bus_probe,
> .remove = sdio_bus_remove,
> + .shutdown = sdio_bus_shutdown,
> .pm = &sdio_bus_pm_ops,
> };
>
> @@ -261,6 +271,14 @@ void sdio_unregister_bus(void)
> bus_unregister(&sdio_bus_type);
> }
>
> +static void sdio_legacy_shutdown(struct sdio_func *func)
> +{
> + struct device *dev = &func->dev;
> + struct device_driver *driver = dev->driver;
> +
> + driver->shutdown(dev);
> +}
> +
> /**
> * __sdio_register_driver - register a function driver
> * @drv: SDIO function driver
> @@ -272,6 +290,13 @@ int __sdio_register_driver(struct sdio_driver *drv, struct module *owner)
> drv->drv.bus = &sdio_bus_type;
> drv->drv.owner = owner;
>
> + /*
> + * This driver needs updating. Note that driver_register() warns about
> + * this, so we're not adding another warning here.
> + */
> + if (!drv->shutdown && drv->drv.shutdown)
> + drv->shutdown = sdio_legacy_shutdown;
> +
> return driver_register(&drv->drv);
> }
> EXPORT_SYMBOL_GPL(__sdio_register_driver);
> diff --git a/include/linux/mmc/sdio_func.h b/include/linux/mmc/sdio_func.h
> index fed1f5f4a8d3..4534bf462aac 100644
> --- a/include/linux/mmc/sdio_func.h
> +++ b/include/linux/mmc/sdio_func.h
> @@ -78,6 +78,7 @@ struct sdio_driver {
>
> int (*probe)(struct sdio_func *, const struct sdio_device_id *);
> void (*remove)(struct sdio_func *);
> + void (*shutdown)(struct sdio_func *);
>
> struct device_driver drv;
> };
^ permalink raw reply
* Re: [PATCH] wifi: brcmfmac: Fix potential kernel oops when probe fails
From: Marek Szyprowski @ 2026-01-14 23:16 UTC (permalink / raw)
To: Arend van Spriel, linux-wireless, brcm80211,
brcm80211-dev-list.pdl
In-Reply-To: <74e3bb49-ebbe-4692-b278-c04f2a30bf96@broadcom.com>
On 14.01.2026 14:45, Arend van Spriel wrote:
> On 12/31/2025 3:35 PM, Marek Szyprowski wrote:
>> When probe of the sdio brcmfmac device fails for some reasons (i.e.
>> missing firmware), the sdiodev->bus is set to error instead of NULL,
>> thus
>> the cleanup later in brcmf_sdio_remove() tries to free resources via
>> invalid bus pointer. Fix this.
>
> Hi Marek,
>
> Thanks for the fix. Please consider my suggestion below...
>
>> Fixes: 0ff0843310b7 ("wifi: brcmfmac: Add optional lpo clock enable
>> support")
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> ---
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git
>> a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>> index 6a3f187320fc..6615748fa5bb 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>> @@ -954,6 +954,7 @@ int brcmf_sdiod_probe(struct brcmf_sdio_dev
>> *sdiodev)
>
> Maybe use a local variable bus and assign it only on success:
>
>> bus = brcmf_sdio_probe(sdiodev);
>> if (IS_ERR(bus)) {
>> ret = PTR_ERR(bus);
>> goto out;
>> }
>> + sdiodev->bus = bus;
>> brcmf_sdiod_host_fixup(sdiodev->func2->card->host);
>
Well, that would look much better, but sdiodev->bus is also assigned
inside brcmf_sdio_probe() and I didn't check if this is required by the
functions called there or not. Maybe brcmf_sdio_probe() should simply
return error code to make things easier to track?
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [wireless:for-next] BUILD SUCCESS e7df8567878f9cbb9059287161e80f7c7da9b15c
From: kernel test robot @ 2026-01-14 22:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git for-next
branch HEAD: e7df8567878f9cbb9059287161e80f7c7da9b15c Merge tag 'ath-current-20260113' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath into wireless
elapsed time: 751m
configs tested: 252
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha alldefconfig clang-22
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-22
arc defconfig gcc-15.2.0
arc nsimosci_hs_smp_defconfig gcc-15.2.0
arc randconfig-001-20260114 gcc-10.5.0
arc randconfig-001-20260115 clang-22
arc randconfig-002-20260114 gcc-10.5.0
arc randconfig-002-20260115 clang-22
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm at91_dt_defconfig clang-22
arm defconfig gcc-15.2.0
arm ep93xx_defconfig gcc-15.2.0
arm ixp4xx_defconfig clang-22
arm moxart_defconfig clang-22
arm randconfig-001-20260114 gcc-10.5.0
arm randconfig-001-20260115 clang-22
arm randconfig-002-20260114 gcc-10.5.0
arm randconfig-002-20260115 clang-22
arm randconfig-003-20260114 gcc-10.5.0
arm randconfig-003-20260115 clang-22
arm randconfig-004-20260114 gcc-10.5.0
arm randconfig-004-20260115 clang-22
arm sama7_defconfig clang-22
arm64 allmodconfig clang-22
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260114 clang-22
arm64 randconfig-001-20260115 clang-22
arm64 randconfig-002-20260114 clang-22
arm64 randconfig-002-20260115 clang-22
arm64 randconfig-003-20260114 clang-22
arm64 randconfig-003-20260115 clang-22
arm64 randconfig-004-20260114 clang-22
arm64 randconfig-004-20260115 clang-22
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260114 clang-22
csky randconfig-001-20260115 clang-22
csky randconfig-002-20260114 clang-22
csky randconfig-002-20260115 clang-22
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260114 clang-22
hexagon randconfig-002-20260114 clang-22
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260114 gcc-14
i386 buildonly-randconfig-002-20260114 gcc-14
i386 buildonly-randconfig-003-20260114 gcc-14
i386 buildonly-randconfig-004-20260114 gcc-14
i386 buildonly-randconfig-005-20260114 gcc-14
i386 buildonly-randconfig-006-20260114 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260114 gcc-14
i386 randconfig-001-20260115 clang-20
i386 randconfig-002-20260114 gcc-14
i386 randconfig-002-20260115 clang-20
i386 randconfig-003-20260114 gcc-14
i386 randconfig-003-20260115 clang-20
i386 randconfig-004-20260114 gcc-14
i386 randconfig-004-20260115 clang-20
i386 randconfig-005-20260114 gcc-14
i386 randconfig-005-20260115 clang-20
i386 randconfig-006-20260114 gcc-14
i386 randconfig-006-20260115 clang-20
i386 randconfig-007-20260114 gcc-14
i386 randconfig-007-20260115 clang-20
i386 randconfig-011-20260114 gcc-14
i386 randconfig-011-20260115 gcc-14
i386 randconfig-012-20260114 gcc-14
i386 randconfig-012-20260115 gcc-14
i386 randconfig-013-20260114 gcc-14
i386 randconfig-013-20260115 gcc-14
i386 randconfig-014-20260114 gcc-14
i386 randconfig-014-20260115 gcc-14
i386 randconfig-015-20260114 gcc-14
i386 randconfig-015-20260115 gcc-14
i386 randconfig-016-20260114 gcc-14
i386 randconfig-016-20260115 gcc-14
i386 randconfig-017-20260114 gcc-14
i386 randconfig-017-20260115 gcc-14
loongarch allmodconfig clang-22
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260114 clang-22
loongarch randconfig-002-20260114 clang-22
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips ip28_defconfig gcc-15.2.0
mips mtx1_defconfig gcc-15.2.0
mips pic32mzda_defconfig clang-22
mips rb532_defconfig clang-22
nios2 allmodconfig clang-22
nios2 allnoconfig clang-22
nios2 defconfig clang-19
nios2 randconfig-001-20260114 clang-22
nios2 randconfig-002-20260114 clang-22
openrisc alldefconfig gcc-15.2.0
openrisc allmodconfig clang-22
openrisc allnoconfig clang-22
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-22
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc generic-64bit_defconfig clang-22
parisc randconfig-001-20260114 gcc-14.3.0
parisc randconfig-001-20260115 clang-22
parisc randconfig-002-20260114 gcc-14.3.0
parisc randconfig-002-20260115 clang-22
parisc64 defconfig clang-19
powerpc adder875_defconfig clang-22
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-22
powerpc gamecube_defconfig clang-22
powerpc linkstation_defconfig clang-22
powerpc lite5200b_defconfig gcc-15.2.0
powerpc randconfig-001-20260114 gcc-14.3.0
powerpc randconfig-001-20260115 clang-22
powerpc randconfig-002-20260114 gcc-14.3.0
powerpc randconfig-002-20260115 clang-22
powerpc tqm8555_defconfig gcc-15.2.0
powerpc tqm8xx_defconfig clang-22
powerpc64 randconfig-001-20260114 gcc-14.3.0
powerpc64 randconfig-001-20260115 clang-22
powerpc64 randconfig-002-20260114 gcc-14.3.0
powerpc64 randconfig-002-20260115 clang-22
riscv allmodconfig clang-22
riscv allnoconfig clang-22
riscv allyesconfig clang-16
riscv defconfig clang-22
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260114 gcc-14.3.0
riscv randconfig-001-20260114 gcc-15.2.0
riscv randconfig-001-20260115 gcc-10.5.0
riscv randconfig-002-20260114 gcc-15.2.0
riscv randconfig-002-20260114 gcc-9.5.0
riscv randconfig-002-20260115 gcc-10.5.0
s390 allmodconfig clang-19
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260114 gcc-15.2.0
s390 randconfig-001-20260115 gcc-10.5.0
s390 randconfig-002-20260114 gcc-15.2.0
s390 randconfig-002-20260114 gcc-8.5.0
s390 randconfig-002-20260115 gcc-10.5.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-22
sh allyesconfig clang-19
sh defconfig gcc-14
sh kfr2r09_defconfig gcc-15.2.0
sh r7785rp_defconfig clang-22
sh randconfig-001-20260114 gcc-15.2.0
sh randconfig-001-20260115 gcc-10.5.0
sh randconfig-002-20260114 gcc-12.5.0
sh randconfig-002-20260114 gcc-15.2.0
sh randconfig-002-20260115 gcc-10.5.0
sparc allnoconfig clang-22
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260114 clang-20
sparc randconfig-001-20260115 clang-22
sparc randconfig-002-20260114 clang-20
sparc randconfig-002-20260115 clang-22
sparc64 allmodconfig clang-22
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260114 clang-20
sparc64 randconfig-001-20260115 clang-22
sparc64 randconfig-002-20260114 clang-20
sparc64 randconfig-002-20260115 clang-22
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig clang-22
um i386_defconfig gcc-14
um randconfig-001-20260114 clang-20
um randconfig-001-20260115 clang-22
um randconfig-002-20260114 clang-20
um randconfig-002-20260115 clang-22
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-22
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260114 clang-20
x86_64 buildonly-randconfig-002-20260114 clang-20
x86_64 buildonly-randconfig-003-20260114 clang-20
x86_64 buildonly-randconfig-004-20260114 clang-20
x86_64 buildonly-randconfig-005-20260114 clang-20
x86_64 buildonly-randconfig-006-20260114 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260114 gcc-14
x86_64 randconfig-001-20260115 clang-20
x86_64 randconfig-002-20260114 gcc-14
x86_64 randconfig-002-20260115 clang-20
x86_64 randconfig-003-20260114 gcc-14
x86_64 randconfig-003-20260115 clang-20
x86_64 randconfig-004-20260114 gcc-14
x86_64 randconfig-004-20260115 clang-20
x86_64 randconfig-005-20260114 gcc-14
x86_64 randconfig-005-20260115 clang-20
x86_64 randconfig-006-20260114 gcc-14
x86_64 randconfig-006-20260115 clang-20
x86_64 randconfig-011-20260114 gcc-14
x86_64 randconfig-012-20260114 gcc-14
x86_64 randconfig-013-20260114 gcc-14
x86_64 randconfig-014-20260114 gcc-14
x86_64 randconfig-015-20260114 gcc-14
x86_64 randconfig-016-20260114 gcc-14
x86_64 randconfig-071-20260114 clang-20
x86_64 randconfig-071-20260115 gcc-14
x86_64 randconfig-072-20260114 clang-20
x86_64 randconfig-072-20260115 gcc-14
x86_64 randconfig-073-20260114 clang-20
x86_64 randconfig-073-20260115 gcc-14
x86_64 randconfig-074-20260114 clang-20
x86_64 randconfig-074-20260115 gcc-14
x86_64 randconfig-075-20260114 clang-20
x86_64 randconfig-075-20260115 gcc-14
x86_64 randconfig-076-20260114 clang-20
x86_64 randconfig-076-20260115 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-22
xtensa allyesconfig clang-22
xtensa randconfig-001-20260114 clang-20
xtensa randconfig-001-20260115 clang-22
xtensa randconfig-002-20260114 clang-20
xtensa randconfig-002-20260115 clang-22
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Google Summer of Code 2026 - Project ideas page for the Linux Foundation online
From: Till Kamppeter @ 2026-01-14 22:16 UTC (permalink / raw)
To: linux-wireless; +Cc: Aveek Basu
Hi,
the Linux Foundation will apply again as mentoring organization in this year's
Google Summer of Code.
Perhaps also this year security-related projects and projects about AI/ML are
especially welcomed by the organizers at Google, like in 2025.
Everything is going as last year, especially allowance of open source newcomers
and not only students and flexibility with the end of the coding period and the
3 project sizes, large (350h), medium (175h), and small (90h).
On January 19, 2026 (in 5 days) the application period for mentoring
organizations for the Google Summer of Code 2025 will start and the deadline
will be Feb 3.
To be successful, we need a rich project idea list so that we will get selected
by Google.
I have set up a page for project ideas for the Linux Foundation's participation
in the Google Summer of Code 2026:
https://wiki.linuxfoundation.org/gsoc/google-summer-code-2026
Please add your ideas to the sub-page of your work group. Also remove project
ideas which are already done in one of the previous years or not needed any more
and make sure that all contact info is up-to-date and all links are working.
At each idea please tell for which project size (Large (350h), Medium (175h),
Small (90h)) it is intended, the level of difficulty (Easy, Intermediate, Hard),
and mark clearly your security-related and AI/ML-related project ideas (with
something like "**SECURITY**", "**AI**", "**ML**").
Having security and AI/ML project ideas and also not only large-sized projects
raises our chances to get accepted.
Make sure to not talk about "students", but about "contributors" instead. I
have, at least partially, taken care of this when I have copied your sub-group
pages from last year.
Also make sure to remove the "**TO BE UPDATED**" phrase after having updated
your project ideas.
If you have problems mail me with your project ideas and other editing wishes.
The ideas list is in the Linux Foundation Wiki. If you want to edit and did not
have the edit rights already from previous years, please tell me and I give you
edit rights. I need your name and e-mail address for that. If you have an
account at the Linux Foundation, use preferably that e-mail address, but having
an account at the Linux Foundation is not required.
Please also take into account that the deadline for our application as mentoring
organization is Feb 3 and after that Google will evaluate the applications. So
have your ideas (at least most of them, ideas can be posted at any time up to
the contributor application deadline) in by then to raise our chances to get
accepted.
Please also tell us if you do not want to participate any more with your
workgroup, so that we can remove your sub-page.
Till
^ permalink raw reply
* Re: [PATCH v3] wifi: ath11k: move .max_tx_ring to struct ath11k_hw_hal_params
From: Jeff Johnson @ 2026-01-14 21:59 UTC (permalink / raw)
To: Alex G., Vasanthakumar Thiagarajan, jjohnson, ath11k
Cc: baochen.qiang, linux-wireless, linux-kernel
In-Reply-To: <5896283.e9J7NaK4W3@nukework.gtech>
On 1/14/2026 1:29 PM, Alex G. wrote:
> On Wednesday, January 14, 2026 11:24:19 AM CST Jeff Johnson wrote:
>> On 1/12/2026 11:00 PM, Vasanthakumar Thiagarajan wrote:
>>> On 12/28/2025 8:44 PM, Alexandru Gagniuc wrote:
>>>> ".max_tx_ring" is an upper bounds to indexing ".tcl2wbm_rbm_map". It
>>>> is initialized in, core.c, a different file than the array. This
>>>> spaghetti-like relation is fragile and not obvious. Accidentally
>>>> setting ".max_tx_ring" too high leads to a hard to track out-of-
>>>> bounds access and memory corruption.
>>>>
>>>> There is a small ambiguity on the meaning of "max_tx_ring":
>>>> - The highest ring, max=3 implies there are 4 rings (0, 1, 2, 3)
>>>> - The highest number to use for array indexing (there are 3 rings)
>>>>
>>>> Clarify this dependency by moving ".max_tx_ring" adjacent to the array
>>>> ".tcl2wbm_rbm_map", and name it "num_tx_rings". Use ARRAY_SIZE()
>>>> instead of #defines to initialize the length field.
>>>>
>>>> The ath11k_hw_hal_params_qca6390 uses fewer num_tx_rings than its map,
>>>> so use a constant to express the correct value. Add a static_assert()
>>>> to fail compilation if the constant is accidentally set too high.
>>>
>>> Text related to static_assert to be removed accordingly.
>>
> Hi Jeff,
>
>> I removed the last sentence in 'pending', please check:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/commit/?h=pendin
>> g&id=26bb149b5e011b0f73f7b74421589cbd38e3304b
>
> Re-reading the commit message, I think it makes sense to also remove the
> sentence "The ath11k_hw_hal_params_qca6390 uses fewer num_tx_rings than its
> map, so use a constant to express the correct value.". Do you think it's worth
> submitting a v4 with this minor change?
>
> Alex
No need to submit a v4. I can make that change in 'pending'
/jeff
^ permalink raw reply
* Re: [PATCH v3] wifi: ath11k: move .max_tx_ring to struct ath11k_hw_hal_params
From: Alex G. @ 2026-01-14 21:29 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan, jjohnson, ath11k, Jeff Johnson
Cc: baochen.qiang, linux-wireless, linux-kernel
In-Reply-To: <c8456b52-f14c-4bcf-9385-580e9607219d@oss.qualcomm.com>
On Wednesday, January 14, 2026 11:24:19 AM CST Jeff Johnson wrote:
> On 1/12/2026 11:00 PM, Vasanthakumar Thiagarajan wrote:
> > On 12/28/2025 8:44 PM, Alexandru Gagniuc wrote:
> >> ".max_tx_ring" is an upper bounds to indexing ".tcl2wbm_rbm_map". It
> >> is initialized in, core.c, a different file than the array. This
> >> spaghetti-like relation is fragile and not obvious. Accidentally
> >> setting ".max_tx_ring" too high leads to a hard to track out-of-
> >> bounds access and memory corruption.
> >>
> >> There is a small ambiguity on the meaning of "max_tx_ring":
> >> - The highest ring, max=3 implies there are 4 rings (0, 1, 2, 3)
> >> - The highest number to use for array indexing (there are 3 rings)
> >>
> >> Clarify this dependency by moving ".max_tx_ring" adjacent to the array
> >> ".tcl2wbm_rbm_map", and name it "num_tx_rings". Use ARRAY_SIZE()
> >> instead of #defines to initialize the length field.
> >>
> >> The ath11k_hw_hal_params_qca6390 uses fewer num_tx_rings than its map,
> >> so use a constant to express the correct value. Add a static_assert()
> >> to fail compilation if the constant is accidentally set too high.
> >
> > Text related to static_assert to be removed accordingly.
>
Hi Jeff,
> I removed the last sentence in 'pending', please check:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/commit/?h=pendin
> g&id=26bb149b5e011b0f73f7b74421589cbd38e3304b
Re-reading the commit message, I think it makes sense to also remove the
sentence "The ath11k_hw_hal_params_qca6390 uses fewer num_tx_rings than its
map, so use a constant to express the correct value.". Do you think it's worth
submitting a v4 with this minor change?
Alex
> >> The intent is to make the code easier to understand rather than fix
> >> an existing bug.
> >>
> >> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
> >
> > With the above minor comment addressed.
> >
> > Reviewed-by: Vasanthakumar Thiagarajan
> > <vasanthakumar.thiagarajan@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] ath9k: debug.h: fix kernel-doc bad lines and struct ath_tx_stats
From: Randy Dunlap @ 2026-01-14 19:15 UTC (permalink / raw)
To: Jeff Johnson, netdev
Cc: Toke Høiland-Jørgensen, Johannes Berg, linux-wireless
In-Reply-To: <cf6b81ea-3ab2-420a-ac10-e847be54c9c3@oss.qualcomm.com>
On 1/14/26 7:53 AM, Jeff Johnson wrote:
> On 11/16/2025 6:03 PM, Randy Dunlap wrote:
>> Repair "bad line" warnings by starting each line with " *".
>> Add or correct kernel-doc entries for missing struct members in
>> struct ath_tx_stats.
>>
>> Warning: ../drivers/net/wireless/ath/ath9k/debug.h:144 bad line:
>> may have had errors.
>> Warning: ../drivers/net/wireless/ath/ath9k/debug.h:146 bad line:
>> may have had errors.
>> Warning: ../drivers/net/wireless/ath/ath9k/debug.h:156 bad line:
>> Valid only for:
>> Warning: ../drivers/net/wireless/ath/ath9k/debug.h:157 bad line:
>> - non-aggregate condition.
>> Warning: ../drivers/net/wireless/ath/ath9k/debug.h:158 bad line:
>> - first packet of aggregate.
>> Warning: drivers/net/wireless/ath/ath9k/debug.h:191 struct member
>> 'xretries' not described in 'ath_tx_stats'
>> Warning: drivers/net/wireless/ath/ath9k/debug.h:191 struct member
>> 'data_underrun' not described in 'ath_tx_stats'
>> Warning: drivers/net/wireless/ath/ath9k/debug.h:191 struct member
>> 'delim_underrun' not described in 'ath_tx_stats'
>>
>> Fixes: 99c15bf575b1 ("ath9k: Report total tx/rx bytes and packets in debugfs.")
>> Fixes: fec247c0d5bf ("ath9k: Add debug counters for TX")
>> Fixes: 5a6f78afdabe ("ath9k: show excessive-retry MPDUs in debugfs")
>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>> ---
>> Cc: Toke Høiland-Jørgensen <toke@toke.dk>
>> Cc: Johannes Berg <johannes@sipsolutions.net>
>> Cc: linux-wireless@vger.kernel.org
>
> I'm picking this up, but my automation noticed there are still kdoc issues:
> Warning: drivers/net/wireless/ath/ath9k/debug.h:138 struct member 'txeol' not described in 'ath_interrupt_stats'
> ...
> Warning: drivers/net/wireless/ath/ath9k/debug.h:138 struct member 'mac_sleep_access' not described in 'ath_interrupt_stats'
> 19 warnings as errors
>
> Are these handled elsewhere, or will they need to be handled later?
>
> /jeff
Hi Jeff,
I didn't attempt to address those warnings. They need to be handled
later by someone who knows that they are.
--
~Randy
^ permalink raw reply
* Re: [DESIGN RFC v3] AP Architecture for Wi-Fi-8 Multi-AP Coordination (MAPC)
From: Jeff Johnson @ 2026-01-14 19:15 UTC (permalink / raw)
To: Johannes Berg, Abhishek Rajkapur Suryawanshi, ath12k, hostap
Cc: linux-wireless
In-Reply-To: <59cec65b29ded381c85d1be943d88e956a4b7e74.camel@sipsolutions.net>
On 1/12/2026 11:18 AM, Johannes Berg wrote:
> On Mon, 2026-01-12 at 20:12 +0100, Johannes Berg wrote:
>>
>> Why do you always want to let firmware be in control of everything?
>> Seems at least for some of this you'd really want the upper layers to
>> control it for purposes of coordination? How does the FW even know which
>> other AP it can coordinate with, isn't that something a network
>> controller would determine?
>
> A less generous reading of this could be: you guys want everything to be
> controlled by FW, so you don't have to open-source it in hostapd. Now
> you realize oops, don't really want to do all the security handshake in
> FW, so we need to ask hostapd and then we need keys and stations and all
> this stuff. So let's build something nobody else can use, upstream it
> and we get the best of both worlds - others will maintain the mac80211
> code for us anyway.
>
> Am I wrong? Is there a technical reason for not simply doing MAPC
> discovery/agreement negotiation etc. in hostapd as well, based on
> driver/hw/fw capabilities, and then you don't need all these strange
> "triggered by firmware" flows?
My perception is that Qualcomm would love for all the Wi-Fi 8 functionality to
be in userspace and nl/cfg/mac80211 since then there would be no code
maintenance overhead on our part -- just you and the userspace maintainers.
But there are concerns about latency, and internal consensus is that some
aspects of this functionality has to be handled in firmware (or even hardware)
in order to meet customer KPIs. This comes from our history of supporting
large-scale deployments of APs, and the expectations of how Wi-Fi 8 will make
things better. That is why we are posting design RFCs, so that you, as well as
engineers from other vendors, can review our proposals and give your feedback
and counter-proposals. We want to avoid developing what might be an
architecturally pure design that doesn't actually meet customer needs.
And apologies for the "firehose" of both design and code, but we have a desire
to ship Wi-Fi 8 products using upstream code. I've passed along information
that you want our engineering team to focus on the base NPCA patches so that
there is the appropriate foundation. But in parallel we do also hope there is
engagement from other vendors on the Design RFCs we are posting. Our goal is
to upstream as much AP functionality as you can absorb.
/jeff
^ permalink raw reply
* Re: pull-request: ath-current-20260113
From: Jeff Johnson @ 2026-01-14 17:51 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: ath10k, ath11k, ath12k, jjohnson
In-Reply-To: <22746c254c4c43561e2e3deaf49dadf7c57dae17.camel@sipsolutions.net>
On 1/14/2026 9:08 AM, Johannes Berg wrote:
> Do you just want to redo it? I don't mind backing it out, nobody pulled
> my tree yet I'd think?
My opinion is to leave it as is.
let's not add extra work unless netdev or Linus says otherwise :)
/jeff
^ permalink raw reply
* Re: [PATCH v3] wifi: ath11k: move .max_tx_ring to struct ath11k_hw_hal_params
From: Jeff Johnson @ 2026-01-14 17:24 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan, Alexandru Gagniuc, jjohnson, ath11k
Cc: baochen.qiang, linux-wireless, linux-kernel
In-Reply-To: <56c6471b-c878-4afd-8e8e-d56266ca9c64@oss.qualcomm.com>
On 1/12/2026 11:00 PM, Vasanthakumar Thiagarajan wrote:
>
>
> On 12/28/2025 8:44 PM, Alexandru Gagniuc wrote:
>> ".max_tx_ring" is an upper bounds to indexing ".tcl2wbm_rbm_map". It
>> is initialized in, core.c, a different file than the array. This
>> spaghetti-like relation is fragile and not obvious. Accidentally
>> setting ".max_tx_ring" too high leads to a hard to track out-of-
>> bounds access and memory corruption.
>>
>> There is a small ambiguity on the meaning of "max_tx_ring":
>> - The highest ring, max=3 implies there are 4 rings (0, 1, 2, 3)
>> - The highest number to use for array indexing (there are 3 rings)
>>
>> Clarify this dependency by moving ".max_tx_ring" adjacent to the array
>> ".tcl2wbm_rbm_map", and name it "num_tx_rings". Use ARRAY_SIZE()
>> instead of #defines to initialize the length field.
>>
>> The ath11k_hw_hal_params_qca6390 uses fewer num_tx_rings than its map,
>> so use a constant to express the correct value. Add a static_assert()
>> to fail compilation if the constant is accidentally set too high.
>
> Text related to static_assert to be removed accordingly.
I removed the last sentence in 'pending', please check:
https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/commit/?h=pending&id=26bb149b5e011b0f73f7b74421589cbd38e3304b
>
>>
>> The intent is to make the code easier to understand rather than fix
>> an existing bug.
>>
>> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
>
> With the above minor comment addressed.
>
> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
^ permalink raw reply
* Re: pull-request: ath-current-20260113
From: Johannes Berg @ 2026-01-14 17:08 UTC (permalink / raw)
To: Jeff Johnson, linux-wireless; +Cc: ath10k, ath11k, ath12k, jjohnson
In-Reply-To: <f12c186c-c76a-4d39-8591-4c8d7d04d307@oss.qualcomm.com>
On Wed, 2026-01-14 at 07:13 -0800, Jeff Johnson wrote:
> On 1/14/2026 1:47 AM, Johannes Berg wrote:
> > On Tue, 2026-01-13 at 09:33 -0800, Jeff Johnson wrote:
> > >
> > > Note to maintainers:
> > >
> > > This tag includes:
> > > 31707572108d ("wifi: ath12k: Fix wrong P2P device link id issue")
> > >
> > > That commit contains the following:
> > >
> > > Note to linux-next and netdev maintainers:
> >
> > I'm a bit on the fence about this, I hadn't thought about it on the
> > prior -next PR much, but I feel like this is a process thing that
> > shouldn't get recorded in the tag for posterity?
> >
> > I do appreciate the inclusion of this (*especially* when I won't notice
> > the merge conflict myself), but I tend to think it should be in the
> > email rather than the tag message, since the latter is something I use
> > for the merge commit message and it gets recorded.
> >
> > Either way I have to preserve it manually to the next level, so it
> > doesn't really help all that much, although I guess in the tag there's a
> > chance I could see it again when preparing my PR.
> >
> > I'll just edit it out this time I think since it's so long, but you can
> > complain and convince me otherwise for the next time ;-)
>
> In retrospect I made one bad decision.
FTR, I didn't meant to imply that you made a bad choice here - including
this information was valuable. I just didn't think it needs to be in the
tag message, as outlined.
And I was scratching my head over what you said below when I read your
mail earlier, and again now, until I looked back at git ...
> I modified the commit text of that
> patch in my "pending" branch to add the conflict resolution information.
I hadn't even noticed _that_! I only noticed it in the merge / tag
message, not in the individual commit.
> Instead of that, I should have reposted the "pending" version with that
> conflict resolution embedded in the "basement" of the patch so that then it
> would be part of the email record on lore but not part of the patch record in
> git. And then for the tag I could have referred to that lore link in the PR
> email. So this was a good learning lesson for me.
Makes sense.
Do you just want to redo it? I don't mind backing it out, nobody pulled
my tree yet I'd think?
> Hopefully these merge conflicts will be much fewer once the refactored ath12k
> lands in Linus' tree in the next merge window.
Right.
johannes
^ permalink raw reply
* Re: [PATCH wireless-next] wifi: mac80211: Fix AAD/Nonce computation for management frames with MLO
From: Johannes Berg @ 2026-01-14 17:04 UTC (permalink / raw)
To: Sai Pratyusha Magam; +Cc: linux-wireless, Rohan Dutta
In-Reply-To: <0847363a-055a-4d6f-a9ac-b62f275e02ec@oss.qualcomm.com>
On Fri, 2026-01-09 at 15:33 +0530, Sai Pratyusha Magam wrote:
>
> Hi Johannes, I agree that by maintaining a local storage of the A1/A2/A3
> link addresses before mac80211 translates them to the MLD addresses
> would make things easy, i.e, they can directly be used for the
> computations in the SW crypto. While this works well for the receive
> path, on the Transmit path, mac80211 would still receive management
> frames from hostapd with the MLD addresses, which again cannot be used
> directly for the AAD/Nonce computations.
Fair point.
Thinking out loud: First, I think we can afford to separate TX and RX
discussions.
For RX, I think we agree that it could be done much simpler by
(conditionally, when we do translation in mac80211) keeping the pre-
translation addresses, and passing them into the SW crypto. If not set,
use the frame itself.
Secondly, this all seems only relevant to hwsim. Do you think otherwise?
Few drivers seem to use IEEE80211_KEY_FLAG_SW_MGMT_TX, so I think
especially with MLO we can say that you simply _have_ to support TX
encryption offload for EPPKE [1].
Obviously we still want to have hwsim, but if this really is only for
that then I feel we can still fairly easily implement TX encryption
"offload"? After all, in RX we make decryption optional for every single
frame - so if the device/driver didn't decrypt/validate the frame then
mac80211 will. We also pass the key to the driver for each individual
packet (struct ieee80211_tx_info::control::key). So doing the encryption
in hwsim would be really simple if we export a function akin to
ieee80211_tx_h_encrypt() that works on a single skb (which has the key
pointer), sets up a single-frame struct ieee80211_tx_data and returns
the skb from that [2].
While this may sound like a bit more work overall, I'm not even
convinced that it's _that_ much more, and I it would also align hwsim
more with how modern hardware works today anyway.
Any thoughts?
johannes
[1] and, it seems, correct unicast action frame encryption?
[2] https://p.sipsolutions.net/154c5c86af7765fd.txt
^ permalink raw reply
* Re: [PATCH ath-next v5 0/6] wifi: ath11k: Add single shot/periodic CFR capture support
From: Jeff Johnson @ 2026-01-14 16:55 UTC (permalink / raw)
To: Qian Zhang, Baochen Qiang, ath11k; +Cc: linux-wireless, Yu Zhang
In-Reply-To: <a7a73ad1-0761-4abc-acc9-fc94a4e77348@oss.qualcomm.com>
On 1/5/2026 3:51 AM, Qian Zhang wrote:
> On 1/5/2026 10:22 AM, Baochen Qiang wrote:
>> On 12/30/2025 4:25 PM, Qian Zhang wrote:
>> what are these dependencies? They are not present in old revisions.
>>
>> BTW, if you indeed has dependencies, in addition to these prerequisite-patch-id's, please
>> also list them explicitly in the cover letter above.
>>
>
> These dependency details were added by mistake, and I will remove them.
Was that the only known problem with the v5 series?
My automation flagged a checkpatch issue in the 6/6 patch:
WARNING:LINE_SPACING: Missing a blank line after declarations
If there are no other issues with v5 then I can fix this in my pending branch.
Or you can submit a v6. Just let me know.
/jeff
^ permalink raw reply
* Re: [PATCH] wifi: ath: fix comment typo in monitor mode handling
From: Jeff Johnson @ 2026-01-14 16:34 UTC (permalink / raw)
To: Chien Wong, ath11k@lists.infradead.org; +Cc: linux-wireless
In-Reply-To: <20251030143041.12027-1-m@xv97.com>
On 10/30/2025 7:30 AM, Chien Wong wrote:
Subject should have use "ath11k:"
I'll fix this in my pending branch
And I've removed the ath12k list and added the ath11k list
> Correct a typo in the monitor mode comment where "it make" was mistakenly
> used instead of "it doesn't make". The comment explains that the brief
> period where monitor mode appears enabled before being removed is harmless
> in practice.
> Also, use more common phrase "in practice" instead of "in practise".
>
> Fixes: 3f6e6c3291ed ("ath11k: disable monitor mode on QCA6390")
> Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
And I'll drop the Fixes tags since there is no code change and hence no need
to backport this change to stable kernels.
> Signed-off-by: Chien Wong <m@xv97.com>
^ permalink raw reply
* Re: [PATCH] ath9k: debug.h: fix kernel-doc bad lines and struct ath_tx_stats
From: Jeff Johnson @ 2026-01-14 15:53 UTC (permalink / raw)
To: Randy Dunlap, netdev
Cc: Toke Høiland-Jørgensen, Johannes Berg, linux-wireless
In-Reply-To: <20251117020304.448687-1-rdunlap@infradead.org>
On 11/16/2025 6:03 PM, Randy Dunlap wrote:
> Repair "bad line" warnings by starting each line with " *".
> Add or correct kernel-doc entries for missing struct members in
> struct ath_tx_stats.
>
> Warning: ../drivers/net/wireless/ath/ath9k/debug.h:144 bad line:
> may have had errors.
> Warning: ../drivers/net/wireless/ath/ath9k/debug.h:146 bad line:
> may have had errors.
> Warning: ../drivers/net/wireless/ath/ath9k/debug.h:156 bad line:
> Valid only for:
> Warning: ../drivers/net/wireless/ath/ath9k/debug.h:157 bad line:
> - non-aggregate condition.
> Warning: ../drivers/net/wireless/ath/ath9k/debug.h:158 bad line:
> - first packet of aggregate.
> Warning: drivers/net/wireless/ath/ath9k/debug.h:191 struct member
> 'xretries' not described in 'ath_tx_stats'
> Warning: drivers/net/wireless/ath/ath9k/debug.h:191 struct member
> 'data_underrun' not described in 'ath_tx_stats'
> Warning: drivers/net/wireless/ath/ath9k/debug.h:191 struct member
> 'delim_underrun' not described in 'ath_tx_stats'
>
> Fixes: 99c15bf575b1 ("ath9k: Report total tx/rx bytes and packets in debugfs.")
> Fixes: fec247c0d5bf ("ath9k: Add debug counters for TX")
> Fixes: 5a6f78afdabe ("ath9k: show excessive-retry MPDUs in debugfs")
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> Cc: Toke Høiland-Jørgensen <toke@toke.dk>
> Cc: Johannes Berg <johannes@sipsolutions.net>
> Cc: linux-wireless@vger.kernel.org
I'm picking this up, but my automation noticed there are still kdoc issues:
Warning: drivers/net/wireless/ath/ath9k/debug.h:138 struct member 'txeol' not described in 'ath_interrupt_stats'
...
Warning: drivers/net/wireless/ath/ath9k/debug.h:138 struct member 'mac_sleep_access' not described in 'ath_interrupt_stats'
19 warnings as errors
Are these handled elsewhere, or will they need to be handled later?
/jeff
^ permalink raw reply
* Re: pull-request: ath-current-20260113
From: Jeff Johnson @ 2026-01-14 15:13 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: ath10k, ath11k, ath12k, jjohnson
In-Reply-To: <33d998cc225a7aeef4731ebc53c28a32b241ca7e.camel@sipsolutions.net>
On 1/14/2026 1:47 AM, Johannes Berg wrote:
> On Tue, 2026-01-13 at 09:33 -0800, Jeff Johnson wrote:
>>
>> Note to maintainers:
>>
>> This tag includes:
>> 31707572108d ("wifi: ath12k: Fix wrong P2P device link id issue")
>>
>> That commit contains the following:
>>
>> Note to linux-next and netdev maintainers:
>
> I'm a bit on the fence about this, I hadn't thought about it on the
> prior -next PR much, but I feel like this is a process thing that
> shouldn't get recorded in the tag for posterity?
>
> I do appreciate the inclusion of this (*especially* when I won't notice
> the merge conflict myself), but I tend to think it should be in the
> email rather than the tag message, since the latter is something I use
> for the merge commit message and it gets recorded.
>
> Either way I have to preserve it manually to the next level, so it
> doesn't really help all that much, although I guess in the tag there's a
> chance I could see it again when preparing my PR.
>
> I'll just edit it out this time I think since it's so long, but you can
> complain and convince me otherwise for the next time ;-)
In retrospect I made one bad decision. I modified the commit text of that
patch in my "pending" branch to add the conflict resolution information.
Instead of that, I should have reposted the "pending" version with that
conflict resolution embedded in the "basement" of the patch so that then it
would be part of the email record on lore but not part of the patch record in
git. And then for the tag I could have referred to that lore link in the PR
email. So this was a good learning lesson for me.
Hopefully these merge conflicts will be much fewer once the refactored ath12k
lands in Linus' tree in the next merge window.
/jeff
^ permalink raw reply
* Re: [PATCH] wifi: brcmfmac: Fix potential kernel oops when probe fails
From: Arend van Spriel @ 2026-01-14 13:45 UTC (permalink / raw)
To: Marek Szyprowski, linux-wireless, brcm80211,
brcm80211-dev-list.pdl
In-Reply-To: <20251231143544.4158840-1-m.szyprowski@samsung.com>
On 12/31/2025 3:35 PM, Marek Szyprowski wrote:
> When probe of the sdio brcmfmac device fails for some reasons (i.e.
> missing firmware), the sdiodev->bus is set to error instead of NULL, thus
> the cleanup later in brcmf_sdio_remove() tries to free resources via
> invalid bus pointer. Fix this.
Hi Marek,
Thanks for the fix. Please consider my suggestion below...
> Fixes: 0ff0843310b7 ("wifi: brcmfmac: Add optional lpo clock enable support")
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> index 6a3f187320fc..6615748fa5bb 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> @@ -954,6 +954,7 @@ int brcmf_sdiod_probe(struct brcmf_sdio_dev *sdiodev)
Maybe use a local variable bus and assign it only on success:
> bus = brcmf_sdio_probe(sdiodev);
> if (IS_ERR(bus)) {
> ret = PTR_ERR(bus);
> goto out;
> }
> + sdiodev->bus = bus;
> brcmf_sdiod_host_fixup(sdiodev->func2->card->host);
Regards,
Arend
^ permalink raw reply
* [PATCH wireless-next v4 9/9] wifi: mac80211_hwsim: Declare support for EPPKE authentication protocol
From: Kavita Kavita @ 2026-01-14 11:19 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, kavita.kavita, ainy.kumari, sai.magam,
quic_drohan
In-Reply-To: <20260114111900.2196941-1-kavita.kavita@oss.qualcomm.com>
Advertise support for Enhanced Privacy Protection Key Exchange (EPPKE)
authentication protocol for testing scenarios.
Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com>
---
drivers/net/wireless/virtual/mac80211_hwsim.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/virtual/mac80211_hwsim.c b/drivers/net/wireless/virtual/mac80211_hwsim.c
index 4d9f5f87e814..88b2f74cd45d 100644
--- a/drivers/net/wireless/virtual/mac80211_hwsim.c
+++ b/drivers/net/wireless/virtual/mac80211_hwsim.c
@@ -5640,6 +5640,10 @@ static int mac80211_hwsim_new_radio(struct genl_info *info,
wiphy_ext_feature_set(hw->wiphy,
NL80211_EXT_FEATURE_BSS_COLOR);
+ wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_EPPKE);
+ wiphy_ext_feature_set(hw->wiphy,
+ NL80211_EXT_FEATURE_ASSOC_FRAME_ENCRYPTION);
+
hw->wiphy->interface_modes = param->iftypes;
/* ask mac80211 to reserve space for magic */
--
2.34.1
^ permalink raw reply related
* [PATCH wireless-next v4 8/9] wifi: mac80211: add support for encryption/decryption of (Re)Association frames
From: Kavita Kavita @ 2026-01-14 11:18 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, kavita.kavita, ainy.kumari, sai.magam,
quic_drohan
In-Reply-To: <20260114111900.2196941-1-kavita.kavita@oss.qualcomm.com>
Currently, mac80211 does not encrypt or decrypt (Re)Association frames
(Request and Response) because temporal keys are not yet available at
that stage.
With extensions from IEEE P802.11bi, e.g. EPPKE, temporal keys can be
established before association. This enables the encryption and
decryption of (Re)Association Request/Response frames.
Add support to unset the IEEE80211_TX_INTFL_DONT_ENCRYPT flag when
the peer is marked as an Enhanced Privacy Protection (EPP) peer and
encryption keys are available for the connection in non-AP STA mode,
allowing secure transmission of (Re)Association Request frames.
Drop unprotected (Re)Association Request/Response frames received from
an EPP peer.
Co-developed-by: Sai Pratyusha Magam <quic_smagam@quicinc.com>
Signed-off-by: Sai Pratyusha Magam <quic_smagam@quicinc.com>
Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com>
---
net/mac80211/ieee80211_i.h | 8 ++++++++
net/mac80211/mlme.c | 12 +++++++++++-
net/mac80211/rx.c | 8 ++++++++
net/mac80211/tx.c | 4 +++-
net/mac80211/wpa.c | 6 ++++--
5 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 0a8875e0709b..dc757cb32974 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -2393,6 +2393,14 @@ void __ieee80211_tx_skb_tid_band(struct ieee80211_sub_if_data *sdata,
struct sk_buff *skb, int tid, int link_id,
enum nl80211_band band);
+static inline bool ieee80211_require_encrypted_assoc(__le16 fc,
+ struct sta_info *sta)
+{
+ return (sta && sta->sta.epp_peer &&
+ (ieee80211_is_assoc_req(fc) || ieee80211_is_reassoc_req(fc) ||
+ ieee80211_is_assoc_resp(fc) || ieee80211_is_reassoc_resp(fc)));
+}
+
/* sta_out needs to be checked for ERR_PTR() before using */
int ieee80211_lookup_ra_sta(struct ieee80211_sub_if_data *sdata,
struct sk_buff *skb,
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index f7af6750f8d9..6f2217dc7ec8 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2155,6 +2155,8 @@ static int ieee80211_send_assoc(struct ieee80211_sub_if_data *sdata)
struct ieee80211_prep_tx_info info = {};
unsigned int link_id, n_links = 0;
u16 present_elems[PRESENT_ELEMS_MAX] = {};
+ struct sta_info *sta;
+ bool assoc_encrypt;
void *capab_pos;
size_t size;
int ret;
@@ -2335,7 +2337,15 @@ static int ieee80211_send_assoc(struct ieee80211_sub_if_data *sdata)
info.link_id = assoc_data->assoc_link_id;
drv_mgd_prepare_tx(local, sdata, &info);
- IEEE80211_SKB_CB(skb)->flags |= IEEE80211_TX_INTFL_DONT_ENCRYPT;
+ sta = sta_info_get_bss(sdata, sdata->vif.cfg.ap_addr);
+
+ assoc_encrypt = (sta && sta->sta.epp_peer &&
+ wiphy_dereference(sdata->local->hw.wiphy,
+ sta->ptk[sta->ptk_idx]));
+
+ if (!assoc_encrypt)
+ IEEE80211_SKB_CB(skb)->flags |= IEEE80211_TX_INTFL_DONT_ENCRYPT;
+
if (ieee80211_hw_check(&local->hw, REPORTS_TX_ACK_STATUS))
IEEE80211_SKB_CB(skb)->flags |= IEEE80211_TX_CTL_REQ_TX_STATUS |
IEEE80211_TX_INTFL_MLME_CONN_TX;
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index e0ccd9749853..9a2b0ef2f21a 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2609,6 +2609,14 @@ ieee80211_drop_unencrypted_mgmt(struct ieee80211_rx_data *rx)
(!rx->sta || !test_sta_flag(rx->sta, WLAN_STA_ASSOC)))
return RX_DROP_U_UNPROT_ROBUST_ACTION;
+ /*
+ * Drop unprotected (Re)Association Request/Response frame received from
+ * an EPP Peer.
+ */
+ if (!ieee80211_has_protected(fc) &&
+ ieee80211_require_encrypted_assoc(fc, rx->sta))
+ return RX_DROP_U_UNPROT_UCAST_MGMT;
+
return RX_CONTINUE;
}
EXPORT_SYMBOL_IF_MAC80211_KUNIT(ieee80211_drop_unencrypted_mgmt);
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 1b55e8340413..007f5a368d41 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -640,7 +640,9 @@ ieee80211_tx_h_select_key(struct ieee80211_tx_data *tx)
if (!ieee80211_is_data_present(hdr->frame_control) &&
!ieee80211_use_mfp(hdr->frame_control, tx->sta,
tx->skb) &&
- !ieee80211_is_group_privacy_action(tx->skb))
+ !ieee80211_is_group_privacy_action(tx->skb) &&
+ !ieee80211_require_encrypted_assoc(hdr->frame_control,
+ tx->sta))
tx->key = NULL;
else
skip_hw = (tx->key->conf.flags &
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index 4a858112e4ef..fdf98c21d32c 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -527,7 +527,8 @@ ieee80211_crypto_ccmp_decrypt(struct ieee80211_rx_data *rx,
hdrlen = ieee80211_hdrlen(hdr->frame_control);
if (!ieee80211_is_data(hdr->frame_control) &&
- !ieee80211_is_robust_mgmt_frame(skb))
+ !ieee80211_is_robust_mgmt_frame(skb) &&
+ !ieee80211_require_encrypted_assoc(hdr->frame_control, rx->sta))
return RX_CONTINUE;
if (status->flag & RX_FLAG_DECRYPTED) {
@@ -723,7 +724,8 @@ ieee80211_crypto_gcmp_decrypt(struct ieee80211_rx_data *rx)
hdrlen = ieee80211_hdrlen(hdr->frame_control);
if (!ieee80211_is_data(hdr->frame_control) &&
- !ieee80211_is_robust_mgmt_frame(skb))
+ !ieee80211_is_robust_mgmt_frame(skb) &&
+ !ieee80211_require_encrypted_assoc(hdr->frame_control, rx->sta))
return RX_CONTINUE;
if (status->flag & RX_FLAG_DECRYPTED) {
--
2.34.1
^ permalink raw reply related
* [PATCH wireless-next v4 7/9] wifi: mac80211: add support for EPPKE authentication protocol in non-AP STA mode
From: Kavita Kavita @ 2026-01-14 11:18 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, kavita.kavita, ainy.kumari, sai.magam,
quic_drohan
In-Reply-To: <20260114111900.2196941-1-kavita.kavita@oss.qualcomm.com>
Add support for the Enhanced Privacy Protection Key Exchange (EPPKE)
authentication protocol in non-AP STA mode, as specified in
"IEEE P802.11bi/D3.0, 12.16.9".
EPPKE is an RSNA authentication protocol that operates using
Pre-Association Security Negotiation (PASN) procedures. It consists
of three Authentication frames with transaction sequence numbers 1, 2,
and 3. The first and third from the non-AP STA and the second from the
AP STA.
Extend mac80211 to process EPPKE Authentication frames during the
authentication phase. Currently, mac80211 processes only frames with
the expected transaction number. In the case of EPPKE, process the
Authentication frame from the AP only if the transaction number matches
the expected value, which is 2.
After receiving the final Authentication frame with transaction number 3
from the non-AP STA, it indicates that both the non-AP STA and the AP
confirm there are no issues with authentication. Since this is the final
confirmation frame to send out, mark the state as authenticated in
mac80211.
For EPPKE authentication, the Multi-Link element (MLE) must be included
in the Authentication frame body by userspace in case of MLO connection.
If the MLE is not present, reject the Authentication frame.
Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com>
---
net/mac80211/ieee80211_i.h | 2 +-
net/mac80211/mlme.c | 31 +++++++++++++++++++++++++------
2 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 649ea9d2ae9b..0a8875e0709b 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -430,7 +430,7 @@ struct ieee80211_mgd_auth_data {
u8 ap_addr[ETH_ALEN] __aligned(2);
- u16 sae_trans, sae_status;
+ u16 trans, status;
size_t data_len;
u8 data[];
};
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 977303fdfd9f..f7af6750f8d9 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -4911,6 +4911,7 @@ static void ieee80211_rx_mgmt_auth(struct ieee80211_sub_if_data *sdata,
case WLAN_AUTH_FILS_SK:
case WLAN_AUTH_FILS_SK_PFS:
case WLAN_AUTH_FILS_PK:
+ case WLAN_AUTH_EPPKE:
break;
case WLAN_AUTH_SHARED_KEY:
if (ifmgd->auth_data->expected_transaction != 4) {
@@ -8277,6 +8278,12 @@ static int ieee80211_auth(struct ieee80211_sub_if_data *sdata)
if (WARN_ON_ONCE(!auth_data))
return -EINVAL;
+ if (auth_data->algorithm == WLAN_AUTH_EPPKE &&
+ ieee80211_vif_is_mld(&sdata->vif) &&
+ !cfg80211_find_ext_elem(WLAN_EID_EXT_EHT_MULTI_LINK,
+ auth_data->data, auth_data->data_len))
+ return -EINVAL;
+
auth_data->tries++;
if (auth_data->tries > IEEE80211_AUTH_MAX_TRIES) {
@@ -8305,9 +8312,12 @@ static int ieee80211_auth(struct ieee80211_sub_if_data *sdata)
auth_data->expected_transaction = 2;
if (auth_data->algorithm == WLAN_AUTH_SAE) {
- trans = auth_data->sae_trans;
- status = auth_data->sae_status;
+ trans = auth_data->trans;
+ status = auth_data->status;
auth_data->expected_transaction = trans;
+ } else if (auth_data->algorithm == WLAN_AUTH_EPPKE) {
+ trans = auth_data->trans;
+ status = auth_data->status;
}
if (ieee80211_hw_check(&local->hw, REPORTS_TX_ACK_STATUS))
@@ -9222,6 +9232,9 @@ int ieee80211_mgd_auth(struct ieee80211_sub_if_data *sdata,
case NL80211_AUTHTYPE_FILS_PK:
auth_alg = WLAN_AUTH_FILS_PK;
break;
+ case NL80211_AUTHTYPE_EPPKE:
+ auth_alg = WLAN_AUTH_EPPKE;
+ break;
default:
return -EOPNOTSUPP;
}
@@ -9246,12 +9259,14 @@ int ieee80211_mgd_auth(struct ieee80211_sub_if_data *sdata,
auth_data->link_id = req->link_id;
if (req->auth_data_len >= 4) {
- if (req->auth_type == NL80211_AUTHTYPE_SAE) {
+ if (req->auth_type == NL80211_AUTHTYPE_SAE ||
+ req->auth_type == NL80211_AUTHTYPE_EPPKE) {
__le16 *pos = (__le16 *) req->auth_data;
- auth_data->sae_trans = le16_to_cpu(pos[0]);
- auth_data->sae_status = le16_to_cpu(pos[1]);
+ auth_data->trans = le16_to_cpu(pos[0]);
+ auth_data->status = le16_to_cpu(pos[1]);
}
+
memcpy(auth_data->data, req->auth_data + 4,
req->auth_data_len - 4);
auth_data->data_len += req->auth_data_len - 4;
@@ -9302,7 +9317,11 @@ int ieee80211_mgd_auth(struct ieee80211_sub_if_data *sdata,
* out SAE Confirm.
*/
if (cont_auth && req->auth_type == NL80211_AUTHTYPE_SAE &&
- auth_data->peer_confirmed && auth_data->sae_trans == 2)
+ auth_data->peer_confirmed && auth_data->trans == 2)
+ ieee80211_mark_sta_auth(sdata);
+
+ if (cont_auth && req->auth_type == NL80211_AUTHTYPE_EPPKE &&
+ auth_data->trans == 3)
ieee80211_mark_sta_auth(sdata);
if (ifmgd->associated) {
--
2.34.1
^ permalink raw reply related
* [PATCH wireless-next v4 6/9] wifi: mac80211: Check for MLE before appending in Authentication frame
From: Kavita Kavita @ 2026-01-14 11:18 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, kavita.kavita, ainy.kumari, sai.magam,
quic_drohan
In-Reply-To: <20260114111900.2196941-1-kavita.kavita@oss.qualcomm.com>
Currently, in MLO connections, userspace constructs most of the
Authentication frame body, excluding the Multi-Link element (MLE),
which mac80211 appends later in ieee80211_send_auth(). At present,
mac80211 always adds the MLE itself, since userspace
(e.g. wpa_supplicant) does not yet include it.
However, for new authentication protocols such as Enhanced Privacy
Protection Key Exchange (EPPKE), as specified in
"IEEE P802.11bi/D3.0 section 12.16.9", the MLE must be included in
userspace so that the Message Integrity Code (MIC) can be computed
correctly over the complete frame body. Table 9-71 specifies that
the MIC is mandatory. If mac80211 appends the MLE again, the
Authentication frame becomes invalid.
Add a check in ieee80211_send_auth() to detect whether the MLE is
already present in the Authentication frame body before appending.
Skip the append if the MLE exists, otherwise add it as before.
Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com>
---
net/mac80211/util.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 7d7650c91f4f..4d5680da7aa0 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1142,14 +1142,17 @@ void ieee80211_send_auth(struct ieee80211_sub_if_data *sdata,
.ml.control = cpu_to_le16(IEEE80211_ML_CONTROL_TYPE_BASIC),
.basic.len = sizeof(mle.basic),
};
+ bool add_mle;
int err;
- memcpy(mle.basic.mld_mac_addr, sdata->vif.addr, ETH_ALEN);
+ add_mle = (multi_link &&
+ !cfg80211_find_ext_elem(WLAN_EID_EXT_EHT_MULTI_LINK,
+ extra, extra_len));
/* 24 + 6 = header + auth_algo + auth_transaction + status_code */
skb = dev_alloc_skb(local->hw.extra_tx_headroom + IEEE80211_WEP_IV_LEN +
24 + 6 + extra_len + IEEE80211_WEP_ICV_LEN +
- multi_link * sizeof(mle));
+ add_mle * sizeof(mle));
if (!skb)
return;
@@ -1166,8 +1169,11 @@ void ieee80211_send_auth(struct ieee80211_sub_if_data *sdata,
mgmt->u.auth.status_code = cpu_to_le16(status);
if (extra)
skb_put_data(skb, extra, extra_len);
- if (multi_link)
+
+ if (add_mle) {
+ memcpy(mle.basic.mld_mac_addr, sdata->vif.addr, ETH_ALEN);
skb_put_data(skb, &mle, sizeof(mle));
+ }
if (auth_alg == WLAN_AUTH_SHARED_KEY && transaction == 3) {
mgmt->frame_control |= cpu_to_le16(IEEE80211_FCTL_PROTECTED);
--
2.34.1
^ permalink raw reply related
* [PATCH wireless-next v4 5/9] wifi: mac80211: allow key installation before association
From: Kavita Kavita @ 2026-01-14 11:18 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, kavita.kavita, ainy.kumari, sai.magam,
quic_drohan
In-Reply-To: <20260114111900.2196941-1-kavita.kavita@oss.qualcomm.com>
Currently, mac80211 allows key installation only after association
completes. However, Enhanced Privacy Protection Key Exchange (EPPKE)
requires key installation before association to enable encryption and
decryption of (Re)Association Request and Response frames.
Add support to install keys prior to association when the peer is an
Enhanced Privacy Protection (EPP) peer that requires encryption and
decryption of (Re)Association Request and Response frames.
Introduce a new boolean parameter "epp_peer" in the "ieee80211_sta"
profile to indicate that the peer supports the Enhanced Privacy
Protection Key Exchange (EPPKE) protocol. For non-AP STA mode, it
is set when the authentication algorithm is WLAN_AUTH_EPPKE during
station profile initialization. For AP mode, it is set during
NL80211_CMD_NEW_STA and NL80211_CMD_ADD_LINK_STA.
When "epp_peer" parameter is set, mac80211 now accepts keys before
association and enables encryption of the (Re)Association
Request/Response frames.
Co-developed-by: Sai Pratyusha Magam <sai.magam@oss.qualcomm.com>
Signed-off-by: Sai Pratyusha Magam <sai.magam@oss.qualcomm.com>
Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com>
---
include/net/mac80211.h | 2 ++
net/mac80211/cfg.c | 15 +++++++++++++--
net/mac80211/mlme.c | 4 ++++
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 36daccef6554..36ae7fe9ddf3 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2520,6 +2520,7 @@ struct ieee80211_link_sta {
* by the AP.
* @valid_links: bitmap of valid links, or 0 for non-MLO
* @spp_amsdu: indicates whether the STA uses SPP A-MSDU or not.
+ * @epp_peer: indicates that the peer is an EPP peer.
*/
struct ieee80211_sta {
u8 addr[ETH_ALEN] __aligned(2);
@@ -2544,6 +2545,7 @@ struct ieee80211_sta {
struct ieee80211_txq *txq[IEEE80211_NUM_TIDS + 1];
u16 valid_links;
+ bool epp_peer;
struct ieee80211_link_sta deflink;
struct ieee80211_link_sta __rcu *link[IEEE80211_MLD_MAX_NUM_LINKS];
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index fe6be11a7f44..964f440e31cd 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -680,10 +680,18 @@ static int ieee80211_add_key(struct wiphy *wiphy, struct net_device *dev,
* association has completed, this rejects that attempt
* so it will set the key again after association.
*
+ * With (re)association frame encryption enabled, cfg80211
+ * may deliver keys to mac80211 before the station has
+ * associated. In that case, accept the key if the station
+ * is an Enhanced Privacy Protection (EPP) peer.
+ * If (re)association frame encryption support is not present,
+ * cfg80211 will not allow key installation in non‑AP STA mode.
+ *
* TODO: accept the key if we have a station entry and
- * add it to the device after the station.
+ * add it to the device after the station associates.
*/
- if (!sta || !test_sta_flag(sta, WLAN_STA_ASSOC)) {
+ if (!sta || (!sta->sta.epp_peer &&
+ !test_sta_flag(sta, WLAN_STA_ASSOC))) {
ieee80211_key_free_unused(key);
return -ENOENT;
}
@@ -2198,6 +2206,9 @@ static int sta_apply_parameters(struct ieee80211_local *local,
mask = params->sta_flags_mask;
set = params->sta_flags_set;
+ if (params->epp_peer)
+ sta->sta.epp_peer = true;
+
if (ieee80211_vif_is_mesh(&sdata->vif)) {
/*
* In mesh mode, ASSOCIATED isn't part of the nl80211
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index ddff090e7dce..977303fdfd9f 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -8964,6 +8964,10 @@ static int ieee80211_prep_connection(struct ieee80211_sub_if_data *sdata,
goto out_err;
}
+ if (ifmgd->auth_data &&
+ ifmgd->auth_data->algorithm == WLAN_AUTH_EPPKE)
+ new_sta->sta.epp_peer = true;
+
new_sta->sta.mlo = mlo;
}
--
2.34.1
^ permalink raw reply related
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