* Re: [PATCH] Revert "wifi: iwlwifi: trans: remove STATUS_SUSPENDED"
From: Chris Bainbridge @ 2026-01-27 12:21 UTC (permalink / raw)
To: Korenblit, Miriam Rachel
Cc: kvalo@kernel.org, Berg, Johannes, benjamin@sipsolutions.net,
gustavoars@kernel.org, linux-intel-wifi@intel.com,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <DM3PPF63A6024A9FCE1CF29C0492A406E7AA390A@DM3PPF63A6024A9.namprd11.prod.outlook.com>
On Tue, Jan 27, 2026 at 05:05:31AM +0000, Korenblit, Miriam Rachel wrote:
>
> Just making sure: have you been able to reproduce the assert (ADVANCED_SYSASSERT in the log), and then the panic didn't happen?
Yes, the ADVANCED_SYSASSERT was logged but there was no subsequent null pointer
dereference.
> If yes, please test the attached patch, which is supposed to fix the assert itself. With this, you are not even supposed to see an assert.
I ran this through 15 suspend/resume cycles with network traffic. The
ADVANCED_SYSASSERT did not occur, so it looks like the patch does fix
the SYSASSERT. There was a warning logged once out of the 15 cycles:
[ 454.184873] ------------[ cut here ]------------
[ 454.184894] WR pointer moved while flushing 216 -> 239
[ 454.184898] WARNING: drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c:2570 at iwl_trans_pcie_wait_txq_empty+0x4f7/0x6d0 [iwlwifi], CPU#9: kworker/u64:38/4331
[ 454.184927] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat x_tables nf_tables br_netfilter bridge stp llc ccm overlay qrtr rfcomm cmac algif_hash algif_skcipher af_alg bnep binfmt_misc ext4 mbcache jbd2 nls_ascii nls_cp437 vfat fat snd_acp3x_pdm_dma snd_soc_dmic snd_acp3x_rn snd_hda_codec_generic snd_soc_core intel_rapl_msr snd_compress amd_atl intel_rapl_common snd_hda_codec_hdmi iwlmvm mac80211 snd_hda_intel libarc4 snd_usb_audio uvcvideo kvm_amd snd_hda_codec snd_pci_acp6x btusb videobuf2_vmalloc snd_usbmidi_lib snd_intel_dspcfg snd_pci_acp5x btrtl videobuf2_memops snd_rawmidi snd_hwdep btintel kvm btbcm uvc snd_seq_device snd_hda_core btmtk irqbypass videobuf2_v4l2 snd_rn_pci_acp3x iwlwifi snd_pcm rapl videodev snd_acp_config bluetooth pcspkr cfg80211 snd_soc_acpi snd_timer wmi_bmof ecdh_generic videobuf2_common ee1004 ecc k10temp snd_pci_acp3x mc snd
[ 454.185174] rfkill soundcore ccp ac battery sg button amd_pmc acpi_tad joydev evdev msr parport_pc ppdev lp parport nvme_fabrics fuse efi_pstore configfs nfnetlink efivarfs autofs4 crc32c_cryptoapi btrfs blake2b libblake2b xor raid6_pq dm_crypt hid_microsoft ff_memless hid_cmedia r8153_ecm cdc_ether usbnet dm_mod r8152 mii libphy mdio_bus sd_mod uas usb_storage scsi_mod usbhid scsi_common amdgpu drm_client_lib i2c_algo_bit drm_ttm_helper ttm drm_exec drm_suballoc_helper drm_buddy drm_panel_backlight_quirks gpu_sched amdxcp hid_multitouch drm_display_helper ucsi_acpi hid_generic typec_ucsi drm_kms_helper roles xhci_pci sp5100_tco video xhci_hcd typec cec i2c_hid_acpi watchdog i2c_hid amd_sfh ghash_clmulni_intel serio_raw rc_core usbcore nvme thunderbolt hid i2c_piix4 crc16 i2c_smbus nvme_core fan usb_common drm wmi aesni_intel
[ 454.185402] CPU: 9 UID: 0 PID: 4331 Comm: kworker/u64:38 Not tainted 6.19.0-rc6-00341-gf1d1ad131417 #406 PREEMPT(voluntary)
[ 454.185408] Hardware name: HP HP Pavilion Aero Laptop 13-be0xxx/8916, BIOS F.17 12/18/2024
[ 454.185412] Workqueue: async async_run_entry_fn
[ 454.185423] RIP: 0010:iwl_trans_pcie_wait_txq_empty+0x4fe/0x6d0 [iwlwifi]
[ 454.185446] Code: 48 c7 04 03 00 00 00 00 48 81 c4 88 00 00 00 89 d0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 8d 3d 99 65 09 00 0f b6 d3 40 0f b6 f6 <67> 48 0f b9 3a ba 92 ff ff ff eb bb 48 89 c7 e8 8e 7a 05 de e9 4e
[ 454.185450] RSP: 0018:ffff888110abf488 EFLAGS: 00010297
[ 454.185456] RAX: fffffbfff4a42250 RBX: 00000000000033ef RCX: 0000000000000006
[ 454.185460] RDX: 00000000000000ef RSI: 00000000000000d8 RDI: ffffffffc4c207b0
[ 454.185464] RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000
[ 454.185468] R10: 000000000000335f R11: 0000000000000006 R12: ffffed102c4293b0
[ 454.185471] R13: ffff888162149c00 R14: ffff888162149d80 R15: ffff888162149d00
[ 454.185475] FS: 0000000000000000(0000) GS:ffff8883e3d30000(0000) knlGS:0000000000000000
[ 454.185479] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 454.185483] CR2: 00007ff3d9400000 CR3: 00000002b9b2d000 CR4: 0000000000750ef0
[ 454.185487] PKRU: 55555554
[ 454.185490] Call Trace:
[ 454.185494] <TASK>
[ 454.185506] ? iwl_trans_pcie_rxq_dma_data+0x220/0x220 [iwlwifi]
[ 454.185530] ? __local_bh_enable_ip+0xab/0x130
[ 454.185540] iwl_mvm_wait_sta_queues_empty+0x8c/0xd0 [iwlmvm]
[ 454.185568] iwl_mvm_mac_flush+0x668/0xd20 [iwlmvm]
[ 454.185591] ? lock_is_held_type+0xd5/0x130
[ 454.185602] __ieee80211_flush_queues+0x3cd/0x7c0 [mac80211]
[ 454.185679] ieee80211_set_disassoc+0x123f/0x1ac0 [mac80211]
[ 454.185752] ? ieee80211_powersave_allowed+0x360/0x360 [mac80211]
[ 454.185818] ? unwind_next_frame+0x2e2/0x1ea0
[ 454.185830] ieee80211_mgd_deauth.cold+0xa3/0x71e [mac80211]
[ 454.185900] ? __lock_acquire+0x459/0x2170
[ 454.185908] ? ieee80211_mgd_assoc+0x4ae0/0x4ae0 [mac80211]
[ 454.185988] ? lock_is_held_type+0xd5/0x130
[ 454.185999] cfg80211_mlme_deauth+0x33b/0x890 [cfg80211]
[ 454.186080] ? cfg80211_mlme_assoc+0xa50/0xa50 [cfg80211]
[ 454.186164] cfg80211_mlme_down+0x17a/0x240 [cfg80211]
[ 454.186236] ? cfg80211_mlme_disassoc+0x540/0x540 [cfg80211]
[ 454.186315] cfg80211_disconnect+0x50f/0x800 [cfg80211]
[ 454.186393] wiphy_suspend+0x1f8/0x350 [cfg80211]
[ 454.186472] ? rdev_suspend+0x2a0/0x2a0 [cfg80211]
[ 454.186544] dpm_run_callback+0xfc/0x410
[ 454.186554] ? dpm_async_suspend_superior+0x2e0/0x2e0
[ 454.186561] ? pm_verb+0x90/0x90
[ 454.186566] ? _raw_spin_unlock_irqrestore+0x48/0x60
[ 454.186578] device_suspend+0x37b/0x1080
[ 454.186587] ? async_suspend_late+0x30/0x30
[ 454.186594] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90
[ 454.186601] ? lockdep_hardirqs_on+0x78/0x100
[ 454.186612] ? device_suspend+0x1080/0x1080
[ 454.186616] async_suspend+0x19/0x30
[ 454.186622] async_run_entry_fn+0x93/0x500
[ 454.186633] process_one_work+0x849/0x1420
[ 454.186651] ? pwq_dec_nr_in_flight+0xe00/0xe00
[ 454.186665] ? assign_work+0x168/0x240
[ 454.186670] ? lock_is_held_type+0xd5/0x130
[ 454.186679] worker_thread+0x5ef/0xfd0
[ 454.186697] ? process_one_work+0x1420/0x1420
[ 454.186701] kthread+0x3ad/0x760
[ 454.186709] ? kthread_is_per_cpu+0xb0/0xb0
[ 454.186713] ? ret_from_fork+0x71/0x800
[ 454.186719] ? ret_from_fork+0x71/0x800
[ 454.186725] ? _raw_spin_unlock_irq+0x24/0x50
[ 454.186732] ? kthread_is_per_cpu+0xb0/0xb0
[ 454.186739] ret_from_fork+0x54a/0x800
[ 454.186746] ? exit_thread+0x70/0x70
[ 454.186754] ? __switch_to+0x36f/0xd60
[ 454.186761] ? kthread_is_per_cpu+0xb0/0xb0
[ 454.186768] ret_from_fork_asm+0x11/0x20
[ 454.186789] </TASK>
[ 454.186792] irq event stamp: 1499703
[ 454.186795] hardirqs last enabled at (1499709): [<ffffffffa241cdee>] __up_console_sem+0x5e/0x70
[ 454.186802] hardirqs last disabled at (1499714): [<ffffffffa241cdd3>] __up_console_sem+0x43/0x70
[ 454.186808] softirqs last enabled at (1498148): [<ffffffffc4b8a152>] iwl_trans_pcie_wait_txq_empty+0x432/0x6d0 [iwlwifi]
[ 454.186831] softirqs last disabled at (1498146): [<ffffffffc4b8a00f>] iwl_trans_pcie_wait_txq_empty+0x2ef/0x6d0 [iwlwifi]
[ 454.186852] ---[ end trace 0000000000000000 ]---
I think that this is probably a different bug though - checking previous
logs with journalctl, I see the same warning occurred once with
6.17.0-06871-gf79e772258df which predates the "remove STATUS_SUSPENDED"
commit.
^ permalink raw reply
* Re: [PATCH] wifi: mt76: connac: fix txpower_cur not being updated
From: Felix Fietkau @ 2026-01-27 12:21 UTC (permalink / raw)
To: Lucid Duck, linux-wireless; +Cc: Lorenzo Bianconi, Ryder Lee
In-Reply-To: <20260125222235.36565-1-lucid_duck@justthetip.ca>
On 25.01.26 23:22, Lucid Duck wrote:
> The mt76_connac_mcu_set_rate_txpower() function sends TX power settings
> to the firmware but never updates phy->txpower_cur. This causes
> mt76_get_txpower() to return stale or incorrect values (typically
> showing 3 dBm regardless of actual transmit power) when userspace
> queries TX power via nl80211.
>
> This affects MT7921 and other connac-based devices. Users observe:
> $ iw dev wlan0 info
> ...
> txpower 3.00 dBm
>
> The firmware receives and applies the correct power level, but the
> reported value is wrong because txpower_cur is never set.
>
> Fix by updating phy->txpower_cur after successfully configuring TX
> power, matching the behavior of other mt76 drivers like mt7915.
>
> Signed-off-by: Lucid Duck <lucid_duck@justthetip.ca>
> ---
> drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
> index 045771228..7cd357419 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
> @@ -2251,7 +2251,7 @@ mt76_connac_mcu_rate_txpower_band(struct mt76_phy *phy,
>
> int mt76_connac_mcu_set_rate_txpower(struct mt76_phy *phy)
> {
> - int err;
> + int err, tx_power;
>
> if (phy->cap.has_2ghz) {
> err = mt76_connac_mcu_rate_txpower_band(phy,
> @@ -2272,6 +2272,12 @@ int mt76_connac_mcu_set_rate_txpower(struct mt76_phy *phy)
> return err;
> }
>
> + /* Update txpower_cur for accurate reporting via nl80211 */
> + tx_power = 2 * phy->hw->conf.power_level;
> + if (!tx_power)
> + tx_power = 127;
> + phy->txpower_cur = tx_power;
phy->hw->conf.power_level is the user configured power level, not what
the hardware is capable of transmitting.
To fix it properly, I think you should determine the maximum rate power
used in the loop within mt76_connac_mcu_rate_txpower_band (updated with
each call).
- Felix
^ permalink raw reply
* Re: [PATCH v6 00/13] wifi: mt76: stability fixes for deadlocks, NULL derefs, and race conditions
From: Felix Fietkau @ 2026-01-27 10:58 UTC (permalink / raw)
To: Zac, sean.wang
Cc: deren.wu, kvalo, linux-kernel, linux-mediatek, linux-wireless,
linux, lorenzo, ryder.lee, sean.wang, zbowling
In-Reply-To: <20260120201043.38225-1-zac@zacbowling.com>
On 20.01.26 21:10, Zac wrote:
> From: Zac Bowling <zac@zacbowling.com>
>
> TLDR: This series addresses stability issues in both the MT7921 and MT7925
> WiFi drivers that cause kernel panics, deadlocks, and system hangs
> on various systems using these drivers.
>
> This v6 series is rebased on Sean Wang's upstream deadlock fix already sent
> which is now included as patch 01/13. The remaining 12 patches are my stability
> fixes.
When you send v7, please include the "v7" in the subject for all
patches, instead of just the cover letter. Working through your patches
in patchwork is getting quite confusing...
- Felix
^ permalink raw reply
* Re: [PATCH 12/13] wifi: mt76: mt7925: fix ROC deadlocks and race conditions
From: Felix Fietkau @ 2026-01-27 11:06 UTC (permalink / raw)
To: Zac, sean.wang
Cc: deren.wu, kvalo, linux-kernel, linux-mediatek, linux-wireless,
linux, lorenzo, ryder.lee, sean.wang, zbowling
In-Reply-To: <20260120201043.38225-13-zac@zacbowling.com>
On 20.01.26 21:10, Zac wrote:
> From: Zac Bowling <zac@zacbowling.com>
>
> Fix multiple interrelated issues in the remain-on-channel (ROC) handling
> that cause deadlocks, race conditions, and resource leaks.
>
> Problems fixed:
>
> 1. Deadlock in sta removal ROC abort path:
> When a station is removed while a ROC operation is in progress, the
> driver would call mt7925_roc_abort_sync() which waits for ROC completion.
> However, the ROC work itself needs to acquire mt792x_mutex which is
> already held during station removal, causing a deadlock.
>
> Fix: Use async ROC abort (mt76_connac_mcu_abort_roc) when called from
> paths that already hold the mutex, and add MT76_STATE_ROC_ABORT flag
> to coordinate between the abort and the ROC timer.
>
> 2. ROC timer race during suspend:
> The ROC timer could fire after the device started suspending but before
> the ROC was properly aborted, causing undefined behavior.
>
> Fix: Delete ROC timer synchronously before suspend and check device
> state before processing ROC timeout.
>
> 3. ROC rate limiting for MLO auth failures:
> Rapid ROC requests during MLO authentication can overwhelm the firmware,
> causing authentication timeouts. The MT7925 firmware has limited ROC
> handling capacity.
>
> Fix: Add rate limiting infrastructure with configurable minimum interval
> between ROC requests. Track last ROC completion time and defer new
> requests if they arrive too quickly.
>
> 4. WCID leak in ROC cleanup:
> When ROC operations are aborted, the associated WCID resources were
> not being properly released, causing resource exhaustion over time.
>
> Fix: Ensure WCID cleanup happens in all ROC termination paths.
>
> 5. Async ROC abort race condition:
> The async ROC abort could race with normal ROC completion, causing
> double-free or use-after-free of ROC resources.
>
> Fix: Use MT76_STATE_ROC_ABORT flag and proper synchronization to
> prevent races between async abort and normal completion paths.
>
> These fixes work together to provide robust ROC handling that doesn't
> deadlock, properly releases resources, and handles edge cases during
> suspend and MLO operations.
>
> Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 device")
> Signed-off-by: Zac Bowling <zac@zacbowling.com>
The rate limiting code seems a bit suspicious to me.
What does "limited ROC handling capacity" mean? Outstanding ROC
requests? Does it need time to settle after a completed ROC?
This needs to be clarified and likely replaced with a more targeted fix.
- Felix
^ permalink raw reply
* Re: [PATCH 04/13] wifi: mt76: mt7921: add mutex protection in critical paths
From: Felix Fietkau @ 2026-01-27 10:59 UTC (permalink / raw)
To: Zac, sean.wang
Cc: deren.wu, kvalo, linux-kernel, linux-mediatek, linux-wireless,
linux, lorenzo, ryder.lee, sean.wang, zbowling
In-Reply-To: <20260120201043.38225-5-zac@zacbowling.com>
On 20.01.26 21:10, Zac wrote:
> From: Zac Bowling <zac@zacbowling.com>
>
> Add proper mutex protection for mt7921 driver operations that access
> hardware state without proper synchronization. This fixes multiple race
> conditions that can cause system instability.
>
> Fixes added:
>
> 1. mac.c: mt7921_mac_reset_work()
> - Wrap ieee80211_iterate_active_interfaces() with mt792x_mutex
> - The vif_connect_iter callback accesses hw_encap state
>
> 2. main.c: mt7921_remain_on_channel()
> - Remove mt792x_mutex_acquire/release around mt7925_set_channel_state()
> - The function is already called with mutex held from mac80211
> - This was causing double-lock deadlock
>
> 3. main.c: mt7921_cancel_remain_on_channel()
> - Remove mt792x_mutex_acquire/release
> - Function is called from mac80211 with mutex already held
>
> 4. pci.c: mt7921_pci_pm_complete()
> - Remove mt792x_mutex_acquire/release around ieee80211_iterate_active_interfaces
> - This was causing deadlock as the vif connect iteration tries
> to acquire the mutex again
>
> 5. usb.c: mt7921_usb_pm_complete()
> - Same fix as pci.c for USB driver path
Changelog should be below "---" after the commit description, so it
doesn't get picked up.
> These changes prevent both missing mutex protection and mutex deadlocks
> in the mt7921 driver.
>
> Fixes: 5c14a5f944b9 ("wifi: mt76: mt7921: introduce remain_on_channel support")
> Signed-off-by: Zac Bowling <zac@zacbowling.com>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/main.c b/drivers/net/wireless/mediatek/mt76/mt7921/main.c
> index 5fae9a6e273c..196fcb1e2e94 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7921/main.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7921/main.c
> @@ -373,6 +373,11 @@ void mt7921_roc_abort_sync(struct mt792x_dev *dev)
>
> timer_delete_sync(&phy->roc_timer);
> cancel_work_sync(&phy->roc_work);
> + /* Note: caller must hold mutex if ieee80211_iterate_interfaces is
> + * needed for ROC cleanup. Some call sites (like mt7921_mac_sta_remove)
> + * already hold the mutex via mt76_sta_remove(). For suspend paths,
> + * the mutex should be acquired before calling this function.
> + */
> if (test_and_clear_bit(MT76_STATE_ROC, &phy->mt76->state))
> ieee80211_iterate_interfaces(mt76_hw(dev),
> IEEE80211_IFACE_ITER_RESUME_ALL,
> @@ -619,6 +624,7 @@ void mt7921_set_runtime_pm(struct mt792x_dev *dev)
> bool monitor = !!(hw->conf.flags & IEEE80211_CONF_MONITOR);
>
> pm->enable = pm->enable_user && !monitor;
> + /* Note: caller (debugfs) must hold mutex before calling this function */
> ieee80211_iterate_active_interfaces(hw,
> IEEE80211_IFACE_ITER_RESUME_ALL,
> mt7921_pm_interface_iter, dev);
> @@ -765,6 +771,9 @@ mt7921_regd_set_6ghz_power_type(struct ieee80211_vif *vif, bool is_add)
> struct mt792x_dev *dev = phy->dev;
> u32 valid_vif_num = 0;
>
> + /* Note: caller (mt7921_mac_sta_add/remove via mt76_sta_add/remove)
> + * already holds dev->mt76.mutex, so we must not acquire it here.
> + */
> ieee80211_iterate_active_interfaces(mt76_hw(dev),
> IEEE80211_IFACE_ITER_RESUME_ALL,
> mt7921_calc_vif_num, &valid_vif_num);
It looks like these comments should be replaced with
lockdep_assert_held, so that these assumptions can be verified
automatically instead of doing so by hand.
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/pci.c b/drivers/net/wireless/mediatek/mt76/mt7921/pci.c
> index ec9686183251..9f76b334b93d 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7921/pci.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7921/pci.c
> @@ -426,7 +426,9 @@ static int mt7921_pci_suspend(struct device *device)
> cancel_delayed_work_sync(&pm->ps_work);
> cancel_work_sync(&pm->wake_work);
>
> + mt792x_mutex_acquire(dev);
> mt7921_roc_abort_sync(dev);
> + mt792x_mutex_release(dev);
The next patch is removing those...
- Felix
^ permalink raw reply
* Re: [PATCH v5 06/36] cleanup: Basic compatibility with context analysis
From: Lorenzo Stoakes @ 2026-01-27 10:21 UTC (permalink / raw)
To: Marco Elver
Cc: Peter Zijlstra, Boqun Feng, Ingo Molnar, Will Deacon,
David S. Miller, Luc Van Oostenryck, Chris Li, Paul E. McKenney,
Alexander Potapenko, Arnd Bergmann, Bart Van Assche,
Christoph Hellwig, Dmitry Vyukov, Eric Dumazet,
Frederic Weisbecker, Greg Kroah-Hartman, Herbert Xu, Ian Rogers,
Jann Horn, Joel Fernandes, Johannes Berg, Jonathan Corbet,
Josh Triplett, Justin Stitt, Kees Cook, Kentaro Takeda,
Lukas Bulwahn, Mark Rutland, Mathieu Desnoyers, Miguel Ojeda,
Nathan Chancellor, Neeraj Upadhyay, Nick Desaulniers,
Steven Rostedt, Tetsuo Handa, Thomas Gleixner, Thomas Graf,
Uladzislau Rezki, Waiman Long, kasan-dev, linux-crypto, linux-doc,
linux-kbuild, linux-kernel, linux-mm, linux-security-module,
linux-sparse, linux-wireless, llvm, rcu, Sidhartha Kumar
In-Reply-To: <CANpmjNNHmOzaCSc9hQJNuzNVHXA=LRgXB4Q69FNk6wBuuJGdAg@mail.gmail.com>
On Tue, Jan 27, 2026 at 11:17:24AM +0100, Marco Elver wrote:
> On Tue, 27 Jan 2026 at 11:14, Lorenzo Stoakes
> <lorenzo.stoakes@oracle.com> wrote:
> >
> > +cc Sid for awareness
> >
> > Hi,
> >
> > This patch breaks the radix tree and VMA userland tests. The next bots didn't
> > catch it but it seems now they're building the userland VMA tests
> > (e.g. https://lore.kernel.all/202601271308.b8d3fcb6-lkp@intel.com/) but maybe
> > not caught up to the issue this one caused (fails build in tools/testing/vma and
> > tools/testing/radix-tree).
> >
> > Anyway it's a really easy fix, just need to stub out __no_context_analysis in
> > the tools/include copy of compiler_types.h, fix-patch provided below.
> >
> > To avoid bisection hazard it'd be nice if it could be folded into this series
> > before this patch, but if we're too late in the cycle for that I can submit a
> > fix separately.
>
> Thanks, I saw. I have a more complete fix I'm about to send.
Great, thanks!
^ permalink raw reply
* Re: [PATCH v2 1/2] wifi: ath12k: Remove frequency range filtering for single-phy devices
From: Baochen Qiang @ 2026-01-27 10:21 UTC (permalink / raw)
To: Saikiran B; +Cc: ath12k, linux-wireless, kvalo
In-Reply-To: <CAAFDt1sdE3Wpp5CByTZmBk=YnQxFhAwmbC5XpYaqYq0Wdx547A@mail.gmail.com>
On 1/27/2026 4:58 PM, Saikiran B wrote:
> Hi Baochen,
>
> 1. Here are the MD5 sums from my /lib/firmware/ath12k/WCN7850/hw2.0/
> (sourced from linux-firmware 20250901):
this is a bit old. Please try the latest board-2.bin from linux-firmware repo:
commit 1d588f106ceea113c4c650b43d948da5746e704c
Author: Jeff Johnson <jjohnson@qti.qualcomm.com>
Date: Thu Sep 18 11:03:58 2025 -0700
ath12k: WCN7850 hw2.0: update board-2.bin
Signed-off-by: Jeff Johnson <jjohnson@qti.qualcomm.com>
$ md5sum board-2.bin
74878eeb4ea01b8ea6bd19b57c99d702 board-2.bin
>
> 2fa9a691f199b25aafce48967d93c85b amss.bin.zst
> 7cd6eb50e9a6ad98e658a53033214c9e board-2.bin.zst
> 62c117046e52cb78c922635bea177afe m3.bin.zst
> 953ba9719c55664a5d91d99b412caee1 Notice.txt.zst
>
> 2. Logs: I realized CONFIG_ATH12K_DEBUG was disabled in my recent
> build. I am rebuilding the kernel now with the debug mask enabled and
> will provide the verbose logs in a follow-up email once tested.
>
> 3. Regarding the Frequency Logic: While I gather the logs, I'd like to
> highlight that the issue likely persists regardless of the firmware
> behavior.
>
> The freq_range filter assumes ar has a single contiguous range (e.g.,
> start=5150, end=5850). For a Single-PHY device like WCN7850 that
> supports disjoint bands (2.4GHz + 5GHz), a single start/end pair
> cannot correctly represent the capabilities.
>
> If we set it to cover 2.4GHz, it filters 5GHz.
>
> If we set it to cover both (e.g., 2.4GHz to 7GHz), the filter allows
> everything and becomes redundant.
>
> I will get back to you shortly with the logs to confirm the firmware state.
>
> Thanks & Regards,
> Saikiran
>
> On Tue, Jan 27, 2026 at 1:11 PM Baochen Qiang
> <baochen.qiang@oss.qualcomm.com> wrote:
>>
>>
>>
>> On 1/27/2026 12:04 PM, Saikiran B wrote:
>>> Hi Baochen,
>>>
>>> I checked the logs again.
>>>
>>> The issue seems to be coming from how
>>> [ath12k_regd_update()](drivers/net/wireless/ath/ath12k/reg.c) handles
>>> frequency range updates for this device. WCN7850 is a single-phy
>>> device (single [ar](drivers/net/wireless/ath/ath12k/mac.c) that
>>> supports both 2.4GHz and 5GHz/6GHz.
>>>
>>> In ath12k_regd_update():
>>>
>>> 1. It updates the range for 2GHz capabilities (sets range to ~2.4GHz).
>>> 2. It then attempts to update for 5GHz capabilities.
>>> 3. Because `ar->supports_6ghz` is true, it uses the 6GHz path logic.
>>> 4. However, `ab->reg_freq_6ghz` appears to be uninitialized/invalid at
>>
>> Hmm, this seems like a known firmware bug. Are you using the latest board-2.bin? please
>> share md5sum of your firmware binaries under /lib/firmware/ath12k/WCN7850/hw2.0
>>
>> If you are using the latest, please help collect verbose ath12k dmesg log:
>>
>> modprobe ath12k debug_mask=0xffffffff
>> modprobe ath12k_wifi7
>>
>>> this stage (possibly due to regulatory init timing or country code
>>> issues, On Lenovo Yoga Slim 7x, SMBIOS does not seem to provide a
>>> valid country code. The driver attempts to set an invalid country code
>>> which the firmware rejects. This inturn triggers this issue. Fixing
>>> SMBIOS parsing/defaults is a separate, complex issue that varies by
>>> vendor.), causing the 5GHz range update to be skipped or invalid.
>>>
>>> [ 11.699027] ath12k_pci 0004:01:00.0: Failed to set the requested
>>> Country regulatory setting
>>> [ 31.111995] ath12k_pci 0004:01:00.0: Failed to set the requested
>>> Country regulatory setting
>>>
>>> As a result, `ar->freq_range` remains effectively set for only the 2.4GHz band.
>>>
>>> When ath12k_reg_update_chan_list() runs:
>>>
>>> It compares 5GHz channels (e.g., 5180 MHz) against a
>>> [freq_range](drivers/net/wireless/ath/ath12k/reg.c) that only covers
>>> 2.4GHz.
>>> Result: `center_freq > end_freq` is TRUE -> Channel is filtered out.
>>>
>>> The filtering logic added in acc152f9be20 works for split-phy topology
>>> where each host ar covers a specific range. For WCN7850, where a
>>> single host ar covers disjoint bands (2.4G + 5G), [freq_range] but
>>> [freq_range](drivers/net/wireless/ath/ath12k/reg.c) (start/end) cannot
>>> represent multiple disjoint bands at the same time.
>>>
>>> Removing this driver-level filter allows the firmware (which knows the
>>> true capabilities) to handle the channel list correctly.
>>>
>>> Thanks & Regards,
>>> Saikiran
>>>
>>> On Tue, Jan 27, 2026 at 8:52 AM Baochen Qiang
>>> <baochen.qiang@oss.qualcomm.com> wrote:
>>>>
>>>>
>>>>
>>>> On 1/26/2026 5:52 PM, Saikiran wrote:
>>>>> The frequency range filtering added in commit acc152f9be20 was designed
>>>>> for split-phy devices where multiple radios with overlapping frequency
>>>>> ranges within the same band are combined into a single wiphy. Each radio
>>>>> in such setups handles only a subset of channels within a band (e.g., two
>>>>> 5GHz radios covering 5GHz-low and 5GHz-high separately).
>>>>>
>>>>> However, this filtering breaks single-phy devices like WCN7850 that use
>>>>> a single radio to handle both 2.4GHz and 5GHz bands. On these devices,
>>>>
>>>> To be accurate, WCN7850 still gets two phys in hardware, it is just in host that we treat
>>>> it as single.
>>>>
>>>>> the freq_range is set to cover the entire supported spectrum, but the
>>>>
>>>> exactly
>>>>
>>>>> filtering logic incorrectly restricts channels, causing 5GHz to become
>>>>> completely unusable.
>>>>
>>>> how? what are the actual values of freq_range when you hit the issue and how are they
>>>> calculated?
>>>>
>>>>>
>>>>> The issue manifests as:
>>>>> - All 5GHz channels filtered out during channel list updates
>>>>> - No 5GHz SSIDs visible in scans
>>>>> - Only 2.4GHz networks functional
>>>>>
>>>>> Remove the frequency range filtering entirely and rely on the firmware
>>>>> to handle frequency restrictions based on actual hardware capabilities.
>>>>> This approach works correctly for both split-phy and single-phy devices,
>>>>> as the firmware has complete knowledge of what the hardware supports.
>>>>>
>>>>> Fixes: acc152f9be20 ("wifi: ath12k: combine channel list for split-phy devices in single-wiphy")
>>>>> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302 (Lenovo Yoga Slim 7x)
>>>>> Signed-off-by: Saikiran <bjsaikiran@gmail.com>
>>>>> ---
>>>>> drivers/net/wireless/ath/ath12k/reg.c | 13 -------------
>>>>> 1 file changed, 13 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/wireless/ath/ath12k/reg.c b/drivers/net/wireless/ath/ath12k/reg.c
>>>>> index 7898f6981e5a..48c362a86524 100644
>>>>> --- a/drivers/net/wireless/ath/ath12k/reg.c
>>>>> +++ b/drivers/net/wireless/ath/ath12k/reg.c
>>>>> @@ -153,12 +153,6 @@ int ath12k_reg_update_chan_list(struct ath12k *ar, bool wait)
>>>>> if (bands[band]->channels[i].flags &
>>>>> IEEE80211_CHAN_DISABLED)
>>>>> continue;
>>>>> - /* Skip Channels that are not in current radio's range */
>>>>> - if (bands[band]->channels[i].center_freq <
>>>>> - KHZ_TO_MHZ(ar->freq_range.start_freq) ||
>>>>> - bands[band]->channels[i].center_freq >
>>>>> - KHZ_TO_MHZ(ar->freq_range.end_freq))
>>>>> - continue;
>>>>>
>>>>> num_channels++;
>>>>> }
>>>>> @@ -190,13 +184,6 @@ int ath12k_reg_update_chan_list(struct ath12k *ar, bool wait)
>>>>> if (channel->flags & IEEE80211_CHAN_DISABLED)
>>>>> continue;
>>>>>
>>>>> - /* Skip Channels that are not in current radio's range */
>>>>> - if (bands[band]->channels[i].center_freq <
>>>>> - KHZ_TO_MHZ(ar->freq_range.start_freq) ||
>>>>> - bands[band]->channels[i].center_freq >
>>>>> - KHZ_TO_MHZ(ar->freq_range.end_freq))
>>>>> - continue;
>>>>> -
>>>>> /* TODO: Set to true/false based on some condition? */
>>>>> ch->allow_ht = true;
>>>>> ch->allow_vht = true;
>>>>
>>
^ permalink raw reply
* Re: [PATCH v5 06/36] cleanup: Basic compatibility with context analysis
From: Marco Elver @ 2026-01-27 10:17 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Peter Zijlstra, Boqun Feng, Ingo Molnar, Will Deacon,
David S. Miller, Luc Van Oostenryck, Chris Li, Paul E. McKenney,
Alexander Potapenko, Arnd Bergmann, Bart Van Assche,
Christoph Hellwig, Dmitry Vyukov, Eric Dumazet,
Frederic Weisbecker, Greg Kroah-Hartman, Herbert Xu, Ian Rogers,
Jann Horn, Joel Fernandes, Johannes Berg, Jonathan Corbet,
Josh Triplett, Justin Stitt, Kees Cook, Kentaro Takeda,
Lukas Bulwahn, Mark Rutland, Mathieu Desnoyers, Miguel Ojeda,
Nathan Chancellor, Neeraj Upadhyay, Nick Desaulniers,
Steven Rostedt, Tetsuo Handa, Thomas Gleixner, Thomas Graf,
Uladzislau Rezki, Waiman Long, kasan-dev, linux-crypto, linux-doc,
linux-kbuild, linux-kernel, linux-mm, linux-security-module,
linux-sparse, linux-wireless, llvm, rcu, Sidhartha Kumar
In-Reply-To: <0c2d9b69-c052-4075-8a4b-023d277b8509@lucifer.local>
On Tue, 27 Jan 2026 at 11:14, Lorenzo Stoakes
<lorenzo.stoakes@oracle.com> wrote:
>
> +cc Sid for awareness
>
> Hi,
>
> This patch breaks the radix tree and VMA userland tests. The next bots didn't
> catch it but it seems now they're building the userland VMA tests
> (e.g. https://lore.kernel.all/202601271308.b8d3fcb6-lkp@intel.com/) but maybe
> not caught up to the issue this one caused (fails build in tools/testing/vma and
> tools/testing/radix-tree).
>
> Anyway it's a really easy fix, just need to stub out __no_context_analysis in
> the tools/include copy of compiler_types.h, fix-patch provided below.
>
> To avoid bisection hazard it'd be nice if it could be folded into this series
> before this patch, but if we're too late in the cycle for that I can submit a
> fix separately.
Thanks, I saw. I have a more complete fix I'm about to send.
^ permalink raw reply
* Re: [PATCH v5 06/36] cleanup: Basic compatibility with context analysis
From: Lorenzo Stoakes @ 2026-01-27 10:14 UTC (permalink / raw)
To: Marco Elver
Cc: Peter Zijlstra, Boqun Feng, Ingo Molnar, Will Deacon,
David S. Miller, Luc Van Oostenryck, Chris Li, Paul E. McKenney,
Alexander Potapenko, Arnd Bergmann, Bart Van Assche,
Christoph Hellwig, Dmitry Vyukov, Eric Dumazet,
Frederic Weisbecker, Greg Kroah-Hartman, Herbert Xu, Ian Rogers,
Jann Horn, Joel Fernandes, Johannes Berg, Jonathan Corbet,
Josh Triplett, Justin Stitt, Kees Cook, Kentaro Takeda,
Lukas Bulwahn, Mark Rutland, Mathieu Desnoyers, Miguel Ojeda,
Nathan Chancellor, Neeraj Upadhyay, Nick Desaulniers,
Steven Rostedt, Tetsuo Handa, Thomas Gleixner, Thomas Graf,
Uladzislau Rezki, Waiman Long, kasan-dev, linux-crypto, linux-doc,
linux-kbuild, linux-kernel, linux-mm, linux-security-module,
linux-sparse, linux-wireless, llvm, rcu, Sidhartha Kumar
In-Reply-To: <20251219154418.3592607-7-elver@google.com>
+cc Sid for awareness
Hi,
This patch breaks the radix tree and VMA userland tests. The next bots didn't
catch it but it seems now they're building the userland VMA tests
(e.g. https://lore.kernel.all/202601271308.b8d3fcb6-lkp@intel.com/) but maybe
not caught up to the issue this one caused (fails build in tools/testing/vma and
tools/testing/radix-tree).
Anyway it's a really easy fix, just need to stub out __no_context_analysis in
the tools/include copy of compiler_types.h, fix-patch provided below.
To avoid bisection hazard it'd be nice if it could be folded into this series
before this patch, but if we're too late in the cycle for that I can submit a
fix separately.
Thanks, Lorenzo
----8<----
From cc2390dbefed156757f001e8c3a500a6f8aa1244 Mon Sep 17 00:00:00 2001
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date: Tue, 27 Jan 2026 10:10:55 +0000
Subject: [PATCH] fix
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
tools/include/linux/compiler_types.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/include/linux/compiler_types.h b/tools/include/linux/compiler_types.h
index 949b2cdd3412..ca60d491d4e8 100644
--- a/tools/include/linux/compiler_types.h
+++ b/tools/include/linux/compiler_types.h
@@ -60,4 +60,6 @@
__scalar_type_to_expr_cases(long long), \
default: (x)))
+#define __no_context_analysis
+
#endif /* __LINUX_COMPILER_TYPES_H */
--
2.52.0
^ permalink raw reply related
* Re: [PATCH wireless-next v2 1/2] wifi: mac80211: Add eMLSR/eMLMR action frame parsing support
From: Johannes Berg @ 2026-01-27 9:39 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Ryder Lee, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, linux-wireless, Felix Fietkau,
Shayne Chen, Christian Marangi, linux-mediatek, linux-arm-kernel
In-Reply-To: <aXiHUlHmrKz8JgXS@lore-desk>
On Tue, 2026-01-27 at 10:37 +0100, Lorenzo Bianconi wrote:
>
> > OK, I guess the memcpy was right after all:
> >
> > An AP affiliated with the AP MLD that receives an EML Operating Mode
> > Notification frame from a non-AP STA affiliated with the non-AP MLD
> > should send an EML Operating Mode Notification frame to confirm the
> > mode switch at the AP MLD to the non-AP STA with EML Control field
> > set to the same value as EML Control field in the received EML
> > Operating Mode Notification frame from the non-AP STA before the
> > transition timeout expires.
> >
> > But I think better restrict memcpy() then to just the EML Control field
> > and build the action header etc. directly.
>
> I guess we can just memcpy() control field + link_bitmap (if present) +
> eMLMR Supported MCS and NSS Set subfiled (if present). Agree?
Well, the link bitmap and MCS set subfields are all _part_ of the EML
Control field, so I'd not phrase it that way, but yes.
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v2 1/2] wifi: mac80211: Add eMLSR/eMLMR action frame parsing support
From: Lorenzo Bianconi @ 2026-01-27 9:37 UTC (permalink / raw)
To: Johannes Berg
Cc: Ryder Lee, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, linux-wireless, Felix Fietkau,
Shayne Chen, Christian Marangi, linux-mediatek, linux-arm-kernel
In-Reply-To: <b592a6c9a8f59f112b2221b9a46568769b1e9dcd.camel@sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1939 bytes --]
> On Mon, 2026-01-26 at 23:41 +0100, Lorenzo Bianconi wrote:
> >
> > > Per spec I'm also not sure what the MCS map should be when it's not
> > > included in the frame?
> >
> > IIUC the mcs map value are supposed to be in Operation mode notification frame
> > just for eMLMR. I think the driver should check if the bit is set in
> > ieee80211_eml_params control field to verify if mcs_map_bw values are valid.
>
> Yeah you're right, the MCS Map is always present if EMLMR Mode is set to
> 1. I thought it was also optional and then what values should you use?
>
> Can't mac80211 validate the values?
I guess we can validate eMLMR Supported MCS and NSS Set subfiled according to
the table 9-417t available in P802.11be standard.
>
> > Reading the standard, it is not clear to me if mcs map values are supposed to be
> > added in the Notification frame sent by the AP. What do you think?
>
> Hmm. I thought no, but then the language says it's present when the
> EMLMR Mode is set to 1, so ... it would have to be? Strange, because
> it's not really defined (well) in this direction.
>
> OK, I guess the memcpy was right after all:
>
> An AP affiliated with the AP MLD that receives an EML Operating Mode
> Notification frame from a non-AP STA affiliated with the non-AP MLD
> should send an EML Operating Mode Notification frame to confirm the
> mode switch at the AP MLD to the non-AP STA with EML Control field
> set to the same value as EML Control field in the received EML
> Operating Mode Notification frame from the non-AP STA before the
> transition timeout expires.
>
> But I think better restrict memcpy() then to just the EML Control field
> and build the action header etc. directly.
I guess we can just memcpy() control field + link_bitmap (if present) +
eMLMR Supported MCS and NSS Set subfiled (if present). Agree?
Regards,
Lorenzo
>
> johannes
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] wifi: ath12k: Remove frequency range filtering for single-phy devices
From: Saikiran B @ 2026-01-27 8:58 UTC (permalink / raw)
To: Baochen Qiang; +Cc: ath12k, linux-wireless, kvalo
In-Reply-To: <45061c9a-6f01-4228-9737-0222b4b49059@oss.qualcomm.com>
Hi Baochen,
1. Here are the MD5 sums from my /lib/firmware/ath12k/WCN7850/hw2.0/
(sourced from linux-firmware 20250901):
2fa9a691f199b25aafce48967d93c85b amss.bin.zst
7cd6eb50e9a6ad98e658a53033214c9e board-2.bin.zst
62c117046e52cb78c922635bea177afe m3.bin.zst
953ba9719c55664a5d91d99b412caee1 Notice.txt.zst
2. Logs: I realized CONFIG_ATH12K_DEBUG was disabled in my recent
build. I am rebuilding the kernel now with the debug mask enabled and
will provide the verbose logs in a follow-up email once tested.
3. Regarding the Frequency Logic: While I gather the logs, I'd like to
highlight that the issue likely persists regardless of the firmware
behavior.
The freq_range filter assumes ar has a single contiguous range (e.g.,
start=5150, end=5850). For a Single-PHY device like WCN7850 that
supports disjoint bands (2.4GHz + 5GHz), a single start/end pair
cannot correctly represent the capabilities.
If we set it to cover 2.4GHz, it filters 5GHz.
If we set it to cover both (e.g., 2.4GHz to 7GHz), the filter allows
everything and becomes redundant.
I will get back to you shortly with the logs to confirm the firmware state.
Thanks & Regards,
Saikiran
On Tue, Jan 27, 2026 at 1:11 PM Baochen Qiang
<baochen.qiang@oss.qualcomm.com> wrote:
>
>
>
> On 1/27/2026 12:04 PM, Saikiran B wrote:
> > Hi Baochen,
> >
> > I checked the logs again.
> >
> > The issue seems to be coming from how
> > [ath12k_regd_update()](drivers/net/wireless/ath/ath12k/reg.c) handles
> > frequency range updates for this device. WCN7850 is a single-phy
> > device (single [ar](drivers/net/wireless/ath/ath12k/mac.c) that
> > supports both 2.4GHz and 5GHz/6GHz.
> >
> > In ath12k_regd_update():
> >
> > 1. It updates the range for 2GHz capabilities (sets range to ~2.4GHz).
> > 2. It then attempts to update for 5GHz capabilities.
> > 3. Because `ar->supports_6ghz` is true, it uses the 6GHz path logic.
> > 4. However, `ab->reg_freq_6ghz` appears to be uninitialized/invalid at
>
> Hmm, this seems like a known firmware bug. Are you using the latest board-2.bin? please
> share md5sum of your firmware binaries under /lib/firmware/ath12k/WCN7850/hw2.0
>
> If you are using the latest, please help collect verbose ath12k dmesg log:
>
> modprobe ath12k debug_mask=0xffffffff
> modprobe ath12k_wifi7
>
> > this stage (possibly due to regulatory init timing or country code
> > issues, On Lenovo Yoga Slim 7x, SMBIOS does not seem to provide a
> > valid country code. The driver attempts to set an invalid country code
> > which the firmware rejects. This inturn triggers this issue. Fixing
> > SMBIOS parsing/defaults is a separate, complex issue that varies by
> > vendor.), causing the 5GHz range update to be skipped or invalid.
> >
> > [ 11.699027] ath12k_pci 0004:01:00.0: Failed to set the requested
> > Country regulatory setting
> > [ 31.111995] ath12k_pci 0004:01:00.0: Failed to set the requested
> > Country regulatory setting
> >
> > As a result, `ar->freq_range` remains effectively set for only the 2.4GHz band.
> >
> > When ath12k_reg_update_chan_list() runs:
> >
> > It compares 5GHz channels (e.g., 5180 MHz) against a
> > [freq_range](drivers/net/wireless/ath/ath12k/reg.c) that only covers
> > 2.4GHz.
> > Result: `center_freq > end_freq` is TRUE -> Channel is filtered out.
> >
> > The filtering logic added in acc152f9be20 works for split-phy topology
> > where each host ar covers a specific range. For WCN7850, where a
> > single host ar covers disjoint bands (2.4G + 5G), [freq_range] but
> > [freq_range](drivers/net/wireless/ath/ath12k/reg.c) (start/end) cannot
> > represent multiple disjoint bands at the same time.
> >
> > Removing this driver-level filter allows the firmware (which knows the
> > true capabilities) to handle the channel list correctly.
> >
> > Thanks & Regards,
> > Saikiran
> >
> > On Tue, Jan 27, 2026 at 8:52 AM Baochen Qiang
> > <baochen.qiang@oss.qualcomm.com> wrote:
> >>
> >>
> >>
> >> On 1/26/2026 5:52 PM, Saikiran wrote:
> >>> The frequency range filtering added in commit acc152f9be20 was designed
> >>> for split-phy devices where multiple radios with overlapping frequency
> >>> ranges within the same band are combined into a single wiphy. Each radio
> >>> in such setups handles only a subset of channels within a band (e.g., two
> >>> 5GHz radios covering 5GHz-low and 5GHz-high separately).
> >>>
> >>> However, this filtering breaks single-phy devices like WCN7850 that use
> >>> a single radio to handle both 2.4GHz and 5GHz bands. On these devices,
> >>
> >> To be accurate, WCN7850 still gets two phys in hardware, it is just in host that we treat
> >> it as single.
> >>
> >>> the freq_range is set to cover the entire supported spectrum, but the
> >>
> >> exactly
> >>
> >>> filtering logic incorrectly restricts channels, causing 5GHz to become
> >>> completely unusable.
> >>
> >> how? what are the actual values of freq_range when you hit the issue and how are they
> >> calculated?
> >>
> >>>
> >>> The issue manifests as:
> >>> - All 5GHz channels filtered out during channel list updates
> >>> - No 5GHz SSIDs visible in scans
> >>> - Only 2.4GHz networks functional
> >>>
> >>> Remove the frequency range filtering entirely and rely on the firmware
> >>> to handle frequency restrictions based on actual hardware capabilities.
> >>> This approach works correctly for both split-phy and single-phy devices,
> >>> as the firmware has complete knowledge of what the hardware supports.
> >>>
> >>> Fixes: acc152f9be20 ("wifi: ath12k: combine channel list for split-phy devices in single-wiphy")
> >>> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302 (Lenovo Yoga Slim 7x)
> >>> Signed-off-by: Saikiran <bjsaikiran@gmail.com>
> >>> ---
> >>> drivers/net/wireless/ath/ath12k/reg.c | 13 -------------
> >>> 1 file changed, 13 deletions(-)
> >>>
> >>> diff --git a/drivers/net/wireless/ath/ath12k/reg.c b/drivers/net/wireless/ath/ath12k/reg.c
> >>> index 7898f6981e5a..48c362a86524 100644
> >>> --- a/drivers/net/wireless/ath/ath12k/reg.c
> >>> +++ b/drivers/net/wireless/ath/ath12k/reg.c
> >>> @@ -153,12 +153,6 @@ int ath12k_reg_update_chan_list(struct ath12k *ar, bool wait)
> >>> if (bands[band]->channels[i].flags &
> >>> IEEE80211_CHAN_DISABLED)
> >>> continue;
> >>> - /* Skip Channels that are not in current radio's range */
> >>> - if (bands[band]->channels[i].center_freq <
> >>> - KHZ_TO_MHZ(ar->freq_range.start_freq) ||
> >>> - bands[band]->channels[i].center_freq >
> >>> - KHZ_TO_MHZ(ar->freq_range.end_freq))
> >>> - continue;
> >>>
> >>> num_channels++;
> >>> }
> >>> @@ -190,13 +184,6 @@ int ath12k_reg_update_chan_list(struct ath12k *ar, bool wait)
> >>> if (channel->flags & IEEE80211_CHAN_DISABLED)
> >>> continue;
> >>>
> >>> - /* Skip Channels that are not in current radio's range */
> >>> - if (bands[band]->channels[i].center_freq <
> >>> - KHZ_TO_MHZ(ar->freq_range.start_freq) ||
> >>> - bands[band]->channels[i].center_freq >
> >>> - KHZ_TO_MHZ(ar->freq_range.end_freq))
> >>> - continue;
> >>> -
> >>> /* TODO: Set to true/false based on some condition? */
> >>> ch->allow_ht = true;
> >>> ch->allow_vht = true;
> >>
>
^ permalink raw reply
* [PATCH rtw-next 6/6] wifi: rtw89: pci: warn if SPS OCP happens for RTL8922DE
From: Ping-Ke Shih @ 2026-01-27 8:50 UTC (permalink / raw)
To: linux-wireless; +Cc: gary.chang, dian_syuan0116, kevin_yang
In-Reply-To: <20260127085036.44060-1-pkshih@realtek.com>
SPS OCP (over current protection) is a mechanism to cut off power to
protect hardware. When this happens, raise an interrupt to signal driver,
which prints out a message to note hardware status.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/pci.c | 10 ++++++++--
drivers/net/wireless/realtek/rtw89/pci.h | 1 +
drivers/net/wireless/realtek/rtw89/pci_be.c | 2 ++
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw89/pci.c b/drivers/net/wireless/realtek/rtw89/pci.c
index 9f3445fa55a9..e5efc1c989ff 100644
--- a/drivers/net/wireless/realtek/rtw89/pci.c
+++ b/drivers/net/wireless/realtek/rtw89/pci.c
@@ -968,6 +968,9 @@ static irqreturn_t rtw89_pci_interrupt_threadfn(int irq, void *dev)
if (unlikely(isrs.halt_c2h_isrs & isr_def->isr_wdt_timeout))
rtw89_ser_notify(rtwdev, MAC_AX_ERR_L2_ERR_WDT_TIMEOUT_INT);
+ if (unlikely(isrs.halt_c2h_isrs & isr_def->isr_sps_ocp))
+ rtw89_warn(rtwdev, "SPS OCP alarm 0x%x\n", isrs.halt_c2h_isrs);
+
if (unlikely(rtwpci->under_recovery))
goto enable_intr;
@@ -4003,7 +4006,8 @@ static void rtw89_pci_recovery_intr_mask_v3(struct rtw89_dev *rtwdev)
struct rtw89_pci *rtwpci = (struct rtw89_pci *)rtwdev->priv;
rtwpci->ind_intrs = B_BE_HS0_IND_INT_EN0;
- rtwpci->halt_c2h_intrs = B_BE_HALT_C2H_INT_EN | B_BE_WDT_TIMEOUT_INT_EN;
+ rtwpci->halt_c2h_intrs = B_BE_HALT_C2H_INT_EN | B_BE_WDT_TIMEOUT_INT_EN |
+ B_BE_SPSANA_OCP_INT_EN | B_BE_SPS_OCP_INT_EN;
rtwpci->intrs[0] = 0;
rtwpci->intrs[1] = 0;
}
@@ -4013,7 +4017,8 @@ static void rtw89_pci_default_intr_mask_v3(struct rtw89_dev *rtwdev)
struct rtw89_pci *rtwpci = (struct rtw89_pci *)rtwdev->priv;
rtwpci->ind_intrs = B_BE_HS0_IND_INT_EN0;
- rtwpci->halt_c2h_intrs = B_BE_HALT_C2H_INT_EN | B_BE_WDT_TIMEOUT_INT_EN;
+ rtwpci->halt_c2h_intrs = B_BE_HALT_C2H_INT_EN | B_BE_WDT_TIMEOUT_INT_EN |
+ B_BE_SPSANA_OCP_INT_EN | B_BE_SPS_OCP_INT_EN;
rtwpci->intrs[0] = 0;
rtwpci->intrs[1] = B_BE_PCIE_RDU_CH1_IMR |
B_BE_PCIE_RDU_CH0_IMR |
@@ -4655,6 +4660,7 @@ const struct rtw89_pci_isr_def rtw89_pci_isr_ax = {
.isr_rdu = B_AX_RDU_INT,
.isr_halt_c2h = B_AX_HALT_C2H_INT_EN,
.isr_wdt_timeout = B_AX_WDT_TIMEOUT_INT_EN,
+ .isr_sps_ocp = 0,
.isr_clear_rpq = {R_AX_PCIE_HISR00, B_AX_RPQDMA_INT | B_AX_RPQBD_FULL_INT},
.isr_clear_rxq = {R_AX_PCIE_HISR00, B_AX_RXP1DMA_INT | B_AX_RXDMA_INT |
B_AX_RDU_INT},
diff --git a/drivers/net/wireless/realtek/rtw89/pci.h b/drivers/net/wireless/realtek/rtw89/pci.h
index b0081b694046..ccfa6d33623a 100644
--- a/drivers/net/wireless/realtek/rtw89/pci.h
+++ b/drivers/net/wireless/realtek/rtw89/pci.h
@@ -1331,6 +1331,7 @@ struct rtw89_pci_isr_def {
u32 isr_rdu;
u32 isr_halt_c2h;
u32 isr_wdt_timeout;
+ u32 isr_sps_ocp;
struct rtw89_reg2_def isr_clear_rpq;
struct rtw89_reg2_def isr_clear_rxq;
};
diff --git a/drivers/net/wireless/realtek/rtw89/pci_be.c b/drivers/net/wireless/realtek/rtw89/pci_be.c
index 33bdd3e66bf6..114f40c6c31b 100644
--- a/drivers/net/wireless/realtek/rtw89/pci_be.c
+++ b/drivers/net/wireless/realtek/rtw89/pci_be.c
@@ -763,6 +763,7 @@ const struct rtw89_pci_isr_def rtw89_pci_isr_be = {
.isr_rdu = B_BE_RDU_CH1_INT_V1 | B_BE_RDU_CH0_INT_V1,
.isr_halt_c2h = B_BE_HALT_C2H_INT,
.isr_wdt_timeout = B_BE_WDT_TIMEOUT_INT,
+ .isr_sps_ocp = 0,
.isr_clear_rpq = {R_BE_PCIE_DMA_ISR, B_BE_PCIE_RX_RPQ0_ISR_V1},
.isr_clear_rxq = {R_BE_PCIE_DMA_ISR, B_BE_PCIE_RX_RX0P2_ISR_V1},
};
@@ -772,6 +773,7 @@ const struct rtw89_pci_isr_def rtw89_pci_isr_be_v1 = {
.isr_rdu = B_BE_PCIE_RDU_CH1_INT | B_BE_PCIE_RDU_CH0_INT,
.isr_halt_c2h = B_BE_HALT_C2H_INT,
.isr_wdt_timeout = B_BE_WDT_TIMEOUT_INT,
+ .isr_sps_ocp = B_BE_SPS_OCP_INT | B_BE_SPSANA_OCP_INT,
.isr_clear_rpq = {R_BE_PCIE_DMA_ISR, B_BE_PCIE_RX_RPQ0_ISR_V1},
.isr_clear_rxq = {R_BE_PCIE_DMA_ISR, B_BE_PCIE_RX_RX0P2_ISR_V1},
};
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 5/6] wifi: rtw89: pci: restore LDO setting after device resume
From: Ping-Ke Shih @ 2026-01-27 8:50 UTC (permalink / raw)
To: linux-wireless; +Cc: gary.chang, dian_syuan0116, kevin_yang
In-Reply-To: <20260127085036.44060-1-pkshih@realtek.com>
From: Dian-Syuan Yang <dian_syuan0116@realtek.com>
The LDO (Low Dropout Regulator) setting is missing after suspend/resume
in some platforms, and it will cause card loss. Therefore, reconfigure
this setting to avoid it.
Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/realtek/rtw89/pci.c b/drivers/net/wireless/realtek/rtw89/pci.c
index 093960d7279f..9f3445fa55a9 100644
--- a/drivers/net/wireless/realtek/rtw89/pci.c
+++ b/drivers/net/wireless/realtek/rtw89/pci.c
@@ -4603,6 +4603,7 @@ static int __maybe_unused rtw89_pci_resume(struct device *dev)
rtw89_write32_clr(rtwdev, R_AX_PCIE_PS_CTRL_V1,
B_AX_SEL_REQ_ENTR_L1);
}
+ rtw89_pci_hci_ldo(rtwdev);
rtw89_pci_l2_hci_ldo(rtwdev);
rtw89_pci_basic_cfg(rtwdev, true);
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 4/6] wifi: rtw89: mac: set MU group membership and position to registers
From: Ping-Ke Shih @ 2026-01-27 8:50 UTC (permalink / raw)
To: linux-wireless; +Cc: gary.chang, dian_syuan0116, kevin_yang
In-Reply-To: <20260127085036.44060-1-pkshih@realtek.com>
The WiFi 7 chips use different registers to configure MU group for
beamforming. Define specific registers and refactor the common flow.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/mac.c | 21 +++++++++++++++------
drivers/net/wireless/realtek/rtw89/mac.h | 6 ++++++
drivers/net/wireless/realtek/rtw89/mac_be.c | 7 +++++++
drivers/net/wireless/realtek/rtw89/reg.h | 13 +++++++++++++
4 files changed, 41 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw89/mac.c b/drivers/net/wireless/realtek/rtw89/mac.c
index 4f0f17c499fa..8472f1a63951 100644
--- a/drivers/net/wireless/realtek/rtw89/mac.c
+++ b/drivers/net/wireless/realtek/rtw89/mac.c
@@ -4374,6 +4374,12 @@ static const struct rtw89_port_reg rtw89_port_base_ax = {
R_AX_PORT_HGQ_WINDOW_CFG + 3},
};
+static const struct rtw89_mac_mu_gid_addr rtw89_mac_mu_gid_addr_ax = {
+ .position_en = {R_AX_GID_POSITION_EN0, R_AX_GID_POSITION_EN1},
+ .position = {R_AX_GID_POSITION0, R_AX_GID_POSITION1,
+ R_AX_GID_POSITION2, R_AX_GID_POSITION3},
+};
+
static void rtw89_mac_check_packet_ctrl(struct rtw89_dev *rtwdev,
struct rtw89_vif_link *rtwvif_link, u8 type)
{
@@ -6770,6 +6776,8 @@ void rtw89_mac_bf_disassoc(struct rtw89_dev *rtwdev,
void rtw89_mac_bf_set_gid_table(struct rtw89_dev *rtwdev, struct ieee80211_vif *vif,
struct ieee80211_bss_conf *conf)
{
+ const struct rtw89_mac_gen_def *mac = rtwdev->chip->mac_def;
+ const struct rtw89_mac_mu_gid_addr *addr = mac->mu_gid;
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
struct rtw89_vif_link *rtwvif_link;
u8 mac_idx;
@@ -6789,20 +6797,20 @@ void rtw89_mac_bf_set_gid_table(struct rtw89_dev *rtwdev, struct ieee80211_vif *
p = (__le32 *)conf->mu_group.membership;
rtw89_write32(rtwdev,
- rtw89_mac_reg_by_idx(rtwdev, R_AX_GID_POSITION_EN0, mac_idx),
+ rtw89_mac_reg_by_idx(rtwdev, addr->position_en[0], mac_idx),
le32_to_cpu(p[0]));
rtw89_write32(rtwdev,
- rtw89_mac_reg_by_idx(rtwdev, R_AX_GID_POSITION_EN1, mac_idx),
+ rtw89_mac_reg_by_idx(rtwdev, addr->position_en[1], mac_idx),
le32_to_cpu(p[1]));
p = (__le32 *)conf->mu_group.position;
- rtw89_write32(rtwdev, rtw89_mac_reg_by_idx(rtwdev, R_AX_GID_POSITION0, mac_idx),
+ rtw89_write32(rtwdev, rtw89_mac_reg_by_idx(rtwdev, addr->position[0], mac_idx),
le32_to_cpu(p[0]));
- rtw89_write32(rtwdev, rtw89_mac_reg_by_idx(rtwdev, R_AX_GID_POSITION1, mac_idx),
+ rtw89_write32(rtwdev, rtw89_mac_reg_by_idx(rtwdev, addr->position[1], mac_idx),
le32_to_cpu(p[1]));
- rtw89_write32(rtwdev, rtw89_mac_reg_by_idx(rtwdev, R_AX_GID_POSITION2, mac_idx),
+ rtw89_write32(rtwdev, rtw89_mac_reg_by_idx(rtwdev, addr->position[2], mac_idx),
le32_to_cpu(p[2]));
- rtw89_write32(rtwdev, rtw89_mac_reg_by_idx(rtwdev, R_AX_GID_POSITION3, mac_idx),
+ rtw89_write32(rtwdev, rtw89_mac_reg_by_idx(rtwdev, addr->position[3], mac_idx),
le32_to_cpu(p[3]));
}
@@ -7282,6 +7290,7 @@ const struct rtw89_mac_gen_def rtw89_mac_gen_ax = {
.port_base = &rtw89_port_base_ax,
.agg_len_ht = R_AX_AGG_LEN_HT_0,
.ps_status = R_AX_PPWRBIT_SETTING,
+ .mu_gid = &rtw89_mac_mu_gid_addr_ax,
.muedca_ctrl = {
.addr = R_AX_MUEDCA_EN,
diff --git a/drivers/net/wireless/realtek/rtw89/mac.h b/drivers/net/wireless/realtek/rtw89/mac.h
index 0c8614fc3000..e71a71648ab8 100644
--- a/drivers/net/wireless/realtek/rtw89/mac.h
+++ b/drivers/net/wireless/realtek/rtw89/mac.h
@@ -1015,6 +1015,11 @@ struct rtw89_mac_size_set {
extern const struct rtw89_mac_size_set rtw89_mac_size;
+struct rtw89_mac_mu_gid_addr {
+ u32 position_en[2];
+ u32 position[4];
+};
+
struct rtw89_mac_gen_def {
u32 band1_offset;
u32 filter_model_addr;
@@ -1025,6 +1030,7 @@ struct rtw89_mac_gen_def {
const struct rtw89_port_reg *port_base;
u32 agg_len_ht;
u32 ps_status;
+ const struct rtw89_mac_mu_gid_addr *mu_gid;
struct rtw89_reg_def muedca_ctrl;
struct rtw89_reg_def bfee_ctrl;
diff --git a/drivers/net/wireless/realtek/rtw89/mac_be.c b/drivers/net/wireless/realtek/rtw89/mac_be.c
index 3a84cd529148..dc66b1ee851a 100644
--- a/drivers/net/wireless/realtek/rtw89/mac_be.c
+++ b/drivers/net/wireless/realtek/rtw89/mac_be.c
@@ -62,6 +62,12 @@ static const struct rtw89_port_reg rtw89_port_base_be = {
R_BE_PORT_HGQ_WINDOW_CFG + 3},
};
+static const struct rtw89_mac_mu_gid_addr rtw89_mac_mu_gid_addr_be = {
+ .position_en = {R_BE_GID_POSITION_EN0, R_BE_GID_POSITION_EN1},
+ .position = {R_BE_GID_POSITION0, R_BE_GID_POSITION1,
+ R_BE_GID_POSITION2, R_BE_GID_POSITION3},
+};
+
static int rtw89_mac_check_mac_en_be(struct rtw89_dev *rtwdev, u8 mac_idx,
enum rtw89_mac_hwmod_sel sel)
{
@@ -3170,6 +3176,7 @@ const struct rtw89_mac_gen_def rtw89_mac_gen_be = {
.port_base = &rtw89_port_base_be,
.agg_len_ht = R_BE_AGG_LEN_HT_0,
.ps_status = R_BE_WMTX_POWER_BE_BIT_CTL,
+ .mu_gid = &rtw89_mac_mu_gid_addr_be,
.muedca_ctrl = {
.addr = R_BE_MUEDCA_EN,
diff --git a/drivers/net/wireless/realtek/rtw89/reg.h b/drivers/net/wireless/realtek/rtw89/reg.h
index 9b2e97ed5c7d..9b605617c3f0 100644
--- a/drivers/net/wireless/realtek/rtw89/reg.h
+++ b/drivers/net/wireless/realtek/rtw89/reg.h
@@ -6501,6 +6501,19 @@
#define BE_WMAC_RFMOD_160M 3
#define BE_WMAC_RFMOD_320M 4
+#define R_BE_GID_POSITION0 0x10070
+#define R_BE_GID_POSITION0_C1 0x14070
+#define R_BE_GID_POSITION1 0x10074
+#define R_BE_GID_POSITION1_C1 0x14074
+#define R_BE_GID_POSITION2 0x10078
+#define R_BE_GID_POSITION2_C1 0x14078
+#define R_BE_GID_POSITION3 0x1007C
+#define R_BE_GID_POSITION3_C1 0x1407C
+#define R_BE_GID_POSITION_EN0 0x10080
+#define R_BE_GID_POSITION_EN0_C1 0x14080
+#define R_BE_GID_POSITION_EN1 0x10084
+#define R_BE_GID_POSITION_EN1_C1 0x14084
+
#define R_BE_TX_SUB_BAND_VALUE 0x10088
#define R_BE_TX_SUB_BAND_VALUE_C1 0x14088
#define B_BE_PRI20_BITMAP_MASK GENMASK(31, 16)
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 3/6] wifi: rtw89: wow: disable interrupt before swapping FW for 8922D
From: Ping-Ke Shih @ 2026-01-27 8:50 UTC (permalink / raw)
To: linux-wireless; +Cc: gary.chang, dian_syuan0116, kevin_yang
In-Reply-To: <20260127085036.44060-1-pkshih@realtek.com>
From: Chih-Kang Chang <gary.chang@realtek.com>
Except for the 8852A, 8852B, 8851B, 8852BT, all subsequent chips use
HAXIDMA. Therefore, interrupts need to be disabled before swapping
firmware to avoid unexpected SER.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/wow.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw89/wow.c b/drivers/net/wireless/realtek/rtw89/wow.c
index 5d3227e2b3e4..b67ceda59e92 100644
--- a/drivers/net/wireless/realtek/rtw89/wow.c
+++ b/drivers/net/wireless/realtek/rtw89/wow.c
@@ -1267,15 +1267,15 @@ static int rtw89_wow_swap_fw(struct rtw89_dev *rtwdev, bool wow)
enum rtw89_core_chip_id chip_id = rtwdev->chip->chip_id;
const struct rtw89_chip_info *chip = rtwdev->chip;
bool include_bb = !!chip->bbmcu_nr;
- bool disable_intr_for_dlfw = false;
+ bool disable_intr_for_dlfw = true;
struct ieee80211_sta *wow_sta;
struct rtw89_sta_link *rtwsta_link = NULL;
struct rtw89_sta *rtwsta;
bool is_conn = true;
int ret;
- if (chip_id == RTL8852C || chip_id == RTL8922A)
- disable_intr_for_dlfw = true;
+ if (chip->chip_gen == RTW89_CHIP_AX && chip_id != RTL8852C)
+ disable_intr_for_dlfw = false;
wow_sta = ieee80211_find_sta(wow_vif, wow_vif->cfg.ap_addr);
if (wow_sta) {
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 2/6] wifi: rtw89: debug: tweak Wi-Fi 7 SER L0/L1 simulation methods
From: Ping-Ke Shih @ 2026-01-27 8:50 UTC (permalink / raw)
To: linux-wireless; +Cc: gary.chang, dian_syuan0116, kevin_yang
In-Reply-To: <20260127085036.44060-1-pkshih@realtek.com>
From: Zong-Zhe Yang <kevin_yang@realtek.com>
SER (system error recovery) L0/L1 simulation has two kinds of methods.
How to choose them depends on FW features. But, Wi-Fi 7 misused them.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/debug.c | 69 ++++++++++++++++++----
drivers/net/wireless/realtek/rtw89/reg.h | 4 ++
2 files changed, 62 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw89/debug.c b/drivers/net/wireless/realtek/rtw89/debug.c
index 56b52e780dac..d46691fa09bc 100644
--- a/drivers/net/wireless/realtek/rtw89/debug.c
+++ b/drivers/net/wireless/realtek/rtw89/debug.c
@@ -3538,7 +3538,7 @@ rtw89_debug_priv_early_h2c_set(struct rtw89_dev *rtwdev,
return count;
}
-static int rtw89_dbg_trigger_l1_error_by_halt_h2c(struct rtw89_dev *rtwdev)
+static int rtw89_dbg_trigger_l1_error_by_halt_h2c_ax(struct rtw89_dev *rtwdev)
{
if (!test_bit(RTW89_FLAG_FW_RDY, rtwdev->flags))
return -EBUSY;
@@ -3546,6 +3546,31 @@ static int rtw89_dbg_trigger_l1_error_by_halt_h2c(struct rtw89_dev *rtwdev)
return rtw89_mac_set_err_status(rtwdev, MAC_AX_ERR_L1_RESET_FORCE);
}
+static int rtw89_dbg_trigger_l1_error_by_halt_h2c_be(struct rtw89_dev *rtwdev)
+{
+ if (!test_bit(RTW89_FLAG_FW_RDY, rtwdev->flags))
+ return -EBUSY;
+
+ rtw89_write32_set(rtwdev, R_BE_FW_TRIGGER_IDCT_ISR,
+ B_BE_DMAC_FW_TRIG_IDCT | B_BE_DMAC_FW_ERR_IDCT_IMR);
+
+ return 0;
+}
+
+static int rtw89_dbg_trigger_l1_error_by_halt_h2c(struct rtw89_dev *rtwdev)
+{
+ const struct rtw89_chip_info *chip = rtwdev->chip;
+
+ switch (chip->chip_gen) {
+ case RTW89_CHIP_AX:
+ return rtw89_dbg_trigger_l1_error_by_halt_h2c_ax(rtwdev);
+ case RTW89_CHIP_BE:
+ return rtw89_dbg_trigger_l1_error_by_halt_h2c_be(rtwdev);
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
static int rtw89_dbg_trigger_l1_error(struct rtw89_dev *rtwdev)
{
const struct rtw89_mac_gen_def *mac = rtwdev->chip->mac_def;
@@ -3600,19 +3625,22 @@ static int rtw89_dbg_trigger_l0_error_ax(struct rtw89_dev *rtwdev)
static int rtw89_dbg_trigger_l0_error_be(struct rtw89_dev *rtwdev)
{
+ u8 val8;
int ret;
ret = rtw89_mac_check_mac_en(rtwdev, RTW89_MAC_0, RTW89_CMAC_SEL);
if (ret)
return ret;
- rtw89_write32_set(rtwdev, R_BE_CMAC_FW_TRIGGER_IDCT_ISR,
- B_BE_CMAC_FW_TRIG_IDCT | B_BE_CMAC_FW_ERR_IDCT_IMR);
+ val8 = rtw89_read8(rtwdev, R_BE_CMAC_FUNC_EN);
+ rtw89_write8(rtwdev, R_BE_CMAC_FUNC_EN, val8 & ~B_BE_TMAC_EN);
+ mdelay(1);
+ rtw89_write8(rtwdev, R_BE_CMAC_FUNC_EN, val8);
return 0;
}
-static int rtw89_dbg_trigger_l0_error_by_halt_h2c(struct rtw89_dev *rtwdev)
+static int rtw89_dbg_trigger_l0_error_by_halt_h2c_ax(struct rtw89_dev *rtwdev)
{
if (!test_bit(RTW89_FLAG_FW_RDY, rtwdev->flags))
return -EBUSY;
@@ -3620,23 +3648,42 @@ static int rtw89_dbg_trigger_l0_error_by_halt_h2c(struct rtw89_dev *rtwdev)
return rtw89_mac_set_err_status(rtwdev, MAC_AX_ERR_L0_RESET_FORCE);
}
-static int rtw89_dbg_trigger_l0_error(struct rtw89_dev *rtwdev)
+static int rtw89_dbg_trigger_l0_error_by_halt_h2c_be(struct rtw89_dev *rtwdev)
{
- const struct rtw89_chip_info *chip = rtwdev->chip;
+ if (!test_bit(RTW89_FLAG_FW_RDY, rtwdev->flags))
+ return -EBUSY;
- if (RTW89_CHK_FW_FEATURE(SIM_SER_L0L1_BY_HALT_H2C, &rtwdev->fw))
- return rtw89_dbg_trigger_l0_error_by_halt_h2c(rtwdev);
+ rtw89_write32_set(rtwdev, R_BE_CMAC_FW_TRIGGER_IDCT_ISR,
+ B_BE_CMAC_FW_TRIG_IDCT | B_BE_CMAC_FW_ERR_IDCT_IMR);
- rtw89_leave_ps_mode(rtwdev);
+ return 0;
+}
+
+static int rtw89_dbg_trigger_l0_error(struct rtw89_dev *rtwdev)
+{
+ const struct rtw89_chip_info *chip = rtwdev->chip;
+ int (*sim_l0_by_halt_h2c)(struct rtw89_dev *rtwdev);
+ int (*sim_l0)(struct rtw89_dev *rtwdev);
switch (chip->chip_gen) {
case RTW89_CHIP_AX:
- return rtw89_dbg_trigger_l0_error_ax(rtwdev);
+ sim_l0_by_halt_h2c = rtw89_dbg_trigger_l0_error_by_halt_h2c_ax;
+ sim_l0 = rtw89_dbg_trigger_l0_error_ax;
+ break;
case RTW89_CHIP_BE:
- return rtw89_dbg_trigger_l0_error_be(rtwdev);
+ sim_l0_by_halt_h2c = rtw89_dbg_trigger_l0_error_by_halt_h2c_be;
+ sim_l0 = rtw89_dbg_trigger_l0_error_be;
+ break;
default:
return -EOPNOTSUPP;
}
+
+ if (RTW89_CHK_FW_FEATURE(SIM_SER_L0L1_BY_HALT_H2C, &rtwdev->fw))
+ return sim_l0_by_halt_h2c(rtwdev);
+
+ rtw89_leave_ps_mode(rtwdev);
+
+ return sim_l0(rtwdev);
}
static ssize_t
diff --git a/drivers/net/wireless/realtek/rtw89/reg.h b/drivers/net/wireless/realtek/rtw89/reg.h
index 3239f358aafc..9b2e97ed5c7d 100644
--- a/drivers/net/wireless/realtek/rtw89/reg.h
+++ b/drivers/net/wireless/realtek/rtw89/reg.h
@@ -4960,6 +4960,10 @@
#define R_BE_SER_L1_DBG_CNT_7 0x845C
#define B_BE_SER_L1_DBG_2_MASK GENMASK(31, 0)
+#define R_BE_FW_TRIGGER_IDCT_ISR 0x8508
+#define B_BE_DMAC_FW_ERR_IDCT_IMR BIT(31)
+#define B_BE_DMAC_FW_TRIG_IDCT BIT(0)
+
#define R_BE_DMAC_ERR_IMR 0x8520
#define B_BE_DMAC_NOTX_ERR_INT_EN BIT(21)
#define B_BE_DMAC_NORX_ERR_INT_EN BIT(20)
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 1/6] wifi: rtw89: debug: rename mac/ctrl error to L0/L1 error
From: Ping-Ke Shih @ 2026-01-27 8:50 UTC (permalink / raw)
To: linux-wireless; +Cc: gary.chang, dian_syuan0116, kevin_yang
In-Reply-To: <20260127085036.44060-1-pkshih@realtek.com>
From: Zong-Zhe Yang <kevin_yang@realtek.com>
Sync Realtek terms on SER (system error recovery) simulation.
No logic is changed.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/debug.c | 32 +++++++++++-----------
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw89/debug.c b/drivers/net/wireless/realtek/rtw89/debug.c
index 969b9c7e35a3..56b52e780dac 100644
--- a/drivers/net/wireless/realtek/rtw89/debug.c
+++ b/drivers/net/wireless/realtek/rtw89/debug.c
@@ -3538,7 +3538,7 @@ rtw89_debug_priv_early_h2c_set(struct rtw89_dev *rtwdev,
return count;
}
-static int rtw89_dbg_trigger_ctrl_error_by_halt_h2c(struct rtw89_dev *rtwdev)
+static int rtw89_dbg_trigger_l1_error_by_halt_h2c(struct rtw89_dev *rtwdev)
{
if (!test_bit(RTW89_FLAG_FW_RDY, rtwdev->flags))
return -EBUSY;
@@ -3546,7 +3546,7 @@ static int rtw89_dbg_trigger_ctrl_error_by_halt_h2c(struct rtw89_dev *rtwdev)
return rtw89_mac_set_err_status(rtwdev, MAC_AX_ERR_L1_RESET_FORCE);
}
-static int rtw89_dbg_trigger_ctrl_error(struct rtw89_dev *rtwdev)
+static int rtw89_dbg_trigger_l1_error(struct rtw89_dev *rtwdev)
{
const struct rtw89_mac_gen_def *mac = rtwdev->chip->mac_def;
struct rtw89_cpuio_ctrl ctrl_para = {0};
@@ -3554,7 +3554,7 @@ static int rtw89_dbg_trigger_ctrl_error(struct rtw89_dev *rtwdev)
int ret;
if (RTW89_CHK_FW_FEATURE(SIM_SER_L0L1_BY_HALT_H2C, &rtwdev->fw))
- return rtw89_dbg_trigger_ctrl_error_by_halt_h2c(rtwdev);
+ return rtw89_dbg_trigger_l1_error_by_halt_h2c(rtwdev);
rtw89_leave_ps_mode(rtwdev);
@@ -3576,7 +3576,7 @@ static int rtw89_dbg_trigger_ctrl_error(struct rtw89_dev *rtwdev)
return 0;
}
-static int rtw89_dbg_trigger_mac_error_ax(struct rtw89_dev *rtwdev)
+static int rtw89_dbg_trigger_l0_error_ax(struct rtw89_dev *rtwdev)
{
u16 val16;
u8 val8;
@@ -3598,7 +3598,7 @@ static int rtw89_dbg_trigger_mac_error_ax(struct rtw89_dev *rtwdev)
return 0;
}
-static int rtw89_dbg_trigger_mac_error_be(struct rtw89_dev *rtwdev)
+static int rtw89_dbg_trigger_l0_error_be(struct rtw89_dev *rtwdev)
{
int ret;
@@ -3612,7 +3612,7 @@ static int rtw89_dbg_trigger_mac_error_be(struct rtw89_dev *rtwdev)
return 0;
}
-static int rtw89_dbg_trigger_mac_error_by_halt_h2c(struct rtw89_dev *rtwdev)
+static int rtw89_dbg_trigger_l0_error_by_halt_h2c(struct rtw89_dev *rtwdev)
{
if (!test_bit(RTW89_FLAG_FW_RDY, rtwdev->flags))
return -EBUSY;
@@ -3620,20 +3620,20 @@ static int rtw89_dbg_trigger_mac_error_by_halt_h2c(struct rtw89_dev *rtwdev)
return rtw89_mac_set_err_status(rtwdev, MAC_AX_ERR_L0_RESET_FORCE);
}
-static int rtw89_dbg_trigger_mac_error(struct rtw89_dev *rtwdev)
+static int rtw89_dbg_trigger_l0_error(struct rtw89_dev *rtwdev)
{
const struct rtw89_chip_info *chip = rtwdev->chip;
if (RTW89_CHK_FW_FEATURE(SIM_SER_L0L1_BY_HALT_H2C, &rtwdev->fw))
- return rtw89_dbg_trigger_mac_error_by_halt_h2c(rtwdev);
+ return rtw89_dbg_trigger_l0_error_by_halt_h2c(rtwdev);
rtw89_leave_ps_mode(rtwdev);
switch (chip->chip_gen) {
case RTW89_CHIP_AX:
- return rtw89_dbg_trigger_mac_error_ax(rtwdev);
+ return rtw89_dbg_trigger_l0_error_ax(rtwdev);
case RTW89_CHIP_BE:
- return rtw89_dbg_trigger_mac_error_be(rtwdev);
+ return rtw89_dbg_trigger_l0_error_be(rtwdev);
default:
return -EOPNOTSUPP;
}
@@ -3653,8 +3653,8 @@ rtw89_debug_priv_fw_crash_get(struct rtw89_dev *rtwdev,
enum rtw89_dbg_crash_simulation_type {
RTW89_DBG_SIM_CPU_EXCEPTION = 1,
- RTW89_DBG_SIM_CTRL_ERROR = 2,
- RTW89_DBG_SIM_MAC_ERROR = 3,
+ RTW89_DBG_SIM_L1_ERROR = 2,
+ RTW89_DBG_SIM_L0_ERROR = 3,
};
static ssize_t
@@ -3679,11 +3679,11 @@ rtw89_debug_priv_fw_crash_set(struct rtw89_dev *rtwdev,
return -EOPNOTSUPP;
sim = rtw89_fw_h2c_trigger_cpu_exception;
break;
- case RTW89_DBG_SIM_CTRL_ERROR:
- sim = rtw89_dbg_trigger_ctrl_error;
+ case RTW89_DBG_SIM_L1_ERROR:
+ sim = rtw89_dbg_trigger_l1_error;
break;
- case RTW89_DBG_SIM_MAC_ERROR:
- sim = rtw89_dbg_trigger_mac_error;
+ case RTW89_DBG_SIM_L0_ERROR:
+ sim = rtw89_dbg_trigger_l0_error;
/* Driver SER flow won't get involved; only FW will. */
announce = false;
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 0/6] wifi: rtw89: update fw crash simulation and settings of MAC and PCI
From: Ping-Ke Shih @ 2026-01-27 8:50 UTC (permalink / raw)
To: linux-wireless; +Cc: gary.chang, dian_syuan0116, kevin_yang
Update to simulate firmware crash via debugfs to ensure we can recovery
connection in field by first two patches. The later four patches are
to set proper settings to MAC and PCI.
Chih-Kang Chang (1):
wifi: rtw89: wow: disable interrupt before swapping FW for 8922D
Dian-Syuan Yang (1):
wifi: rtw89: pci: restore LDO setting after device resume
Ping-Ke Shih (2):
wifi: rtw89: mac: set MU group membership and position to registers
wifi: rtw89: pci: warn if SPS OCP happens for RTL8922DE
Zong-Zhe Yang (2):
wifi: rtw89: debug: rename mac/ctrl error to L0/L1 error
wifi: rtw89: debug: tweak Wi-Fi 7 SER L0/L1 simulation methods
drivers/net/wireless/realtek/rtw89/debug.c | 89 ++++++++++++++++-----
drivers/net/wireless/realtek/rtw89/mac.c | 21 +++--
drivers/net/wireless/realtek/rtw89/mac.h | 6 ++
drivers/net/wireless/realtek/rtw89/mac_be.c | 7 ++
drivers/net/wireless/realtek/rtw89/pci.c | 11 ++-
drivers/net/wireless/realtek/rtw89/pci.h | 1 +
drivers/net/wireless/realtek/rtw89/pci_be.c | 2 +
drivers/net/wireless/realtek/rtw89/reg.h | 17 ++++
drivers/net/wireless/realtek/rtw89/wow.c | 6 +-
9 files changed, 128 insertions(+), 32 deletions(-)
base-commit: 8da7e88682d58a7c2e2c2101e49d3c9c9ac481b0
--
2.25.1
^ permalink raw reply
* Re: [PATCH wireless-next v2 1/2] wifi: mac80211: Add eMLSR/eMLMR action frame parsing support
From: Johannes Berg @ 2026-01-27 8:02 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Ryder Lee, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, linux-wireless, Felix Fietkau,
Shayne Chen, Christian Marangi, linux-mediatek, linux-arm-kernel
In-Reply-To: <aXftjdCtqnQk69ys@lore-desk>
On Mon, 2026-01-26 at 23:41 +0100, Lorenzo Bianconi wrote:
>
> > Per spec I'm also not sure what the MCS map should be when it's not
> > included in the frame?
>
> IIUC the mcs map value are supposed to be in Operation mode notification frame
> just for eMLMR. I think the driver should check if the bit is set in
> ieee80211_eml_params control field to verify if mcs_map_bw values are valid.
Yeah you're right, the MCS Map is always present if EMLMR Mode is set to
1. I thought it was also optional and then what values should you use?
Can't mac80211 validate the values?
> Reading the standard, it is not clear to me if mcs map values are supposed to be
> added in the Notification frame sent by the AP. What do you think?
Hmm. I thought no, but then the language says it's present when the
EMLMR Mode is set to 1, so ... it would have to be? Strange, because
it's not really defined (well) in this direction.
OK, I guess the memcpy was right after all:
An AP affiliated with the AP MLD that receives an EML Operating Mode
Notification frame from a non-AP STA affiliated with the non-AP MLD
should send an EML Operating Mode Notification frame to confirm the
mode switch at the AP MLD to the non-AP STA with EML Control field
set to the same value as EML Control field in the received EML
Operating Mode Notification frame from the non-AP STA before the
transition timeout expires.
But I think better restrict memcpy() then to just the EML Control field
and build the action header etc. directly.
johannes
^ permalink raw reply
* Re: [PATCH v2 1/2] wifi: ath12k: Remove frequency range filtering for single-phy devices
From: Baochen Qiang @ 2026-01-27 7:41 UTC (permalink / raw)
To: Saikiran B; +Cc: ath12k, linux-wireless, kvalo
In-Reply-To: <CAAFDt1sgAC6bHOVtELmcQVx=L1dTXDsQFtO+N3R_C2C35VOxhA@mail.gmail.com>
On 1/27/2026 12:04 PM, Saikiran B wrote:
> Hi Baochen,
>
> I checked the logs again.
>
> The issue seems to be coming from how
> [ath12k_regd_update()](drivers/net/wireless/ath/ath12k/reg.c) handles
> frequency range updates for this device. WCN7850 is a single-phy
> device (single [ar](drivers/net/wireless/ath/ath12k/mac.c) that
> supports both 2.4GHz and 5GHz/6GHz.
>
> In ath12k_regd_update():
>
> 1. It updates the range for 2GHz capabilities (sets range to ~2.4GHz).
> 2. It then attempts to update for 5GHz capabilities.
> 3. Because `ar->supports_6ghz` is true, it uses the 6GHz path logic.
> 4. However, `ab->reg_freq_6ghz` appears to be uninitialized/invalid at
Hmm, this seems like a known firmware bug. Are you using the latest board-2.bin? please
share md5sum of your firmware binaries under /lib/firmware/ath12k/WCN7850/hw2.0
If you are using the latest, please help collect verbose ath12k dmesg log:
modprobe ath12k debug_mask=0xffffffff
modprobe ath12k_wifi7
> this stage (possibly due to regulatory init timing or country code
> issues, On Lenovo Yoga Slim 7x, SMBIOS does not seem to provide a
> valid country code. The driver attempts to set an invalid country code
> which the firmware rejects. This inturn triggers this issue. Fixing
> SMBIOS parsing/defaults is a separate, complex issue that varies by
> vendor.), causing the 5GHz range update to be skipped or invalid.
>
> [ 11.699027] ath12k_pci 0004:01:00.0: Failed to set the requested
> Country regulatory setting
> [ 31.111995] ath12k_pci 0004:01:00.0: Failed to set the requested
> Country regulatory setting
>
> As a result, `ar->freq_range` remains effectively set for only the 2.4GHz band.
>
> When ath12k_reg_update_chan_list() runs:
>
> It compares 5GHz channels (e.g., 5180 MHz) against a
> [freq_range](drivers/net/wireless/ath/ath12k/reg.c) that only covers
> 2.4GHz.
> Result: `center_freq > end_freq` is TRUE -> Channel is filtered out.
>
> The filtering logic added in acc152f9be20 works for split-phy topology
> where each host ar covers a specific range. For WCN7850, where a
> single host ar covers disjoint bands (2.4G + 5G), [freq_range] but
> [freq_range](drivers/net/wireless/ath/ath12k/reg.c) (start/end) cannot
> represent multiple disjoint bands at the same time.
>
> Removing this driver-level filter allows the firmware (which knows the
> true capabilities) to handle the channel list correctly.
>
> Thanks & Regards,
> Saikiran
>
> On Tue, Jan 27, 2026 at 8:52 AM Baochen Qiang
> <baochen.qiang@oss.qualcomm.com> wrote:
>>
>>
>>
>> On 1/26/2026 5:52 PM, Saikiran wrote:
>>> The frequency range filtering added in commit acc152f9be20 was designed
>>> for split-phy devices where multiple radios with overlapping frequency
>>> ranges within the same band are combined into a single wiphy. Each radio
>>> in such setups handles only a subset of channels within a band (e.g., two
>>> 5GHz radios covering 5GHz-low and 5GHz-high separately).
>>>
>>> However, this filtering breaks single-phy devices like WCN7850 that use
>>> a single radio to handle both 2.4GHz and 5GHz bands. On these devices,
>>
>> To be accurate, WCN7850 still gets two phys in hardware, it is just in host that we treat
>> it as single.
>>
>>> the freq_range is set to cover the entire supported spectrum, but the
>>
>> exactly
>>
>>> filtering logic incorrectly restricts channels, causing 5GHz to become
>>> completely unusable.
>>
>> how? what are the actual values of freq_range when you hit the issue and how are they
>> calculated?
>>
>>>
>>> The issue manifests as:
>>> - All 5GHz channels filtered out during channel list updates
>>> - No 5GHz SSIDs visible in scans
>>> - Only 2.4GHz networks functional
>>>
>>> Remove the frequency range filtering entirely and rely on the firmware
>>> to handle frequency restrictions based on actual hardware capabilities.
>>> This approach works correctly for both split-phy and single-phy devices,
>>> as the firmware has complete knowledge of what the hardware supports.
>>>
>>> Fixes: acc152f9be20 ("wifi: ath12k: combine channel list for split-phy devices in single-wiphy")
>>> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302 (Lenovo Yoga Slim 7x)
>>> Signed-off-by: Saikiran <bjsaikiran@gmail.com>
>>> ---
>>> drivers/net/wireless/ath/ath12k/reg.c | 13 -------------
>>> 1 file changed, 13 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath12k/reg.c b/drivers/net/wireless/ath/ath12k/reg.c
>>> index 7898f6981e5a..48c362a86524 100644
>>> --- a/drivers/net/wireless/ath/ath12k/reg.c
>>> +++ b/drivers/net/wireless/ath/ath12k/reg.c
>>> @@ -153,12 +153,6 @@ int ath12k_reg_update_chan_list(struct ath12k *ar, bool wait)
>>> if (bands[band]->channels[i].flags &
>>> IEEE80211_CHAN_DISABLED)
>>> continue;
>>> - /* Skip Channels that are not in current radio's range */
>>> - if (bands[band]->channels[i].center_freq <
>>> - KHZ_TO_MHZ(ar->freq_range.start_freq) ||
>>> - bands[band]->channels[i].center_freq >
>>> - KHZ_TO_MHZ(ar->freq_range.end_freq))
>>> - continue;
>>>
>>> num_channels++;
>>> }
>>> @@ -190,13 +184,6 @@ int ath12k_reg_update_chan_list(struct ath12k *ar, bool wait)
>>> if (channel->flags & IEEE80211_CHAN_DISABLED)
>>> continue;
>>>
>>> - /* Skip Channels that are not in current radio's range */
>>> - if (bands[band]->channels[i].center_freq <
>>> - KHZ_TO_MHZ(ar->freq_range.start_freq) ||
>>> - bands[band]->channels[i].center_freq >
>>> - KHZ_TO_MHZ(ar->freq_range.end_freq))
>>> - continue;
>>> -
>>> /* TODO: Set to true/false based on some condition? */
>>> ch->allow_ht = true;
>>> ch->allow_vht = true;
>>
^ permalink raw reply
* Re: [PATCH] wifi: rtw89: usb: fix TX flow control by tracking in-flight URBs
From: Lucid Duck @ 2026-01-27 5:00 UTC (permalink / raw)
To: pkshih; +Cc: linux-wireless, mh_chen, rtl8821cerfe2, Lucid Duck
In-Reply-To: <290226f1d7144477a668f045cbd8eb56@realtek.com>
On Mon, 26 Jan 2026, Ping-Ke Shih wrote:
> Then URB becomes exhausted?
Yes. Without proper flow control, mac80211 continuously queues frames
since we always report resources available. URBs accumulate until
submission fails, causing TX stalls or instability under load.
> Curiously. How did you decide this value? Have you tested USB2 and USB3
> devices? How about their throughput before/after this patch?
The value of 32 was based on similar USB wireless drivers (mt76, ath9k_htc)
as a reasonable starting point. I'm open to tuning this if testing reveals
a better value, and it may need adjustment for optimal USB2 vs USB3
performance at different bands.
I have both USB2 and USB3 test capability and will be running more
rigorous throughput testing on both configurations shortly. Initial
testing showed the patch stable under sustained load, but I want to
collect proper iperf3 measurements before providing specific numbers.
I'll follow up with detailed test results and a v2 addressing your
comments.
> I feel we don't need repeatedly adding this comment. If you like it,
> just keep one.
Understood. Will clean this up in v2.
Thanks for the review.
--
Lucid Duck
^ permalink raw reply
* RE: [PATCH] Revert "wifi: iwlwifi: trans: remove STATUS_SUSPENDED"
From: Korenblit, Miriam Rachel @ 2026-01-27 5:05 UTC (permalink / raw)
To: Chris Bainbridge
Cc: kvalo@kernel.org, Berg, Johannes, benjamin@sipsolutions.net,
gustavoars@kernel.org, linux-intel-wifi@intel.com,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <CAP-bSRZ60CSEtR-_9OL6k_Lzg=w8MtD2i79KpwF+nYYzgak=-Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2041 bytes --]
> -----Original Message-----
> From: Chris Bainbridge <chris.bainbridge@gmail.com>
> Sent: Tuesday, January 27, 2026 12:05 AM
> To: Korenblit, Miriam Rachel <miriam.rachel.korenblit@intel.com>
> Cc: kvalo@kernel.org; Berg, Johannes <johannes.berg@intel.com>;
> benjamin@sipsolutions.net; gustavoars@kernel.org; linux-intel-wifi@intel.com;
> linux-wireless@vger.kernel.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org
> Subject: Re: [PATCH] Revert "wifi: iwlwifi: trans: remove STATUS_SUSPENDED"
>
> On Mon, 26 Jan 2026 at 13:45, Korenblit, Miriam Rachel
> <miriam.rachel.korenblit@intel.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Chris Bainbridge <chris.bainbridge@gmail.com>
> > > Sent: Monday, January 26, 2026 10:42 AM
> > > To: Korenblit, Miriam Rachel <miriam.rachel.korenblit@intel.com>
> > > Cc: kvalo@kernel.org; Berg, Johannes <johannes.berg@intel.com>;
> > > benjamin@sipsolutions.net; gustavoars@kernel.org;
> > > linux-intel-wifi@intel.com; linux-wireless@vger.kernel.org;
> > > netdev@vger.kernel.org; linux- kernel@vger.kernel.org;
> > > stable@vger.kernel.org
> > > Subject: Re: [PATCH] Revert "wifi: iwlwifi: trans: remove
> STATUS_SUSPENDED"
> > >
> > > On Mon, Jan 26, 2026 at 07:15:54AM +0000, Korenblit, Miriam Rachel wrote:
> > > >
> > > > Hi Chris, could you please provide the full log?
> > > >
> > > > Miri
> > >
> > > Sure, for 6.18.0 see https://lore.kernel.org/linux-
> > > wireless/aTDoDiD55qlUZ0pn@debian.local/
> > >
> > >
> > Thanks!
> >
> > could you please test if the attached patch eliminates the panic?
>
> Yes, that seems to work fine.
>
> Reported-and-tested-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Just making sure: have you been able to reproduce the assert (ADVANCED_SYSASSERT in the log), and then the panic didn't happen?
If yes, please test the attached patch, which is supposed to fix the assert itself. With this, you are not even supposed to see an assert.
Miri
[-- Attachment #2: 0001-wifi-iwlwifi-mvm-pause-TCM-on-fast-resume.patch --]
[-- Type: application/octet-stream, Size: 1440 bytes --]
From 74ff1670ee94e69bc78a8e553cfe27995811f645 Mon Sep 17 00:00:00 2001
From: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Date: Tue, 27 Jan 2026 06:58:56 +0200
Subject: [PATCH] wifi: iwlwifi: mvm: pause TCM on fast resume
Organization: Intel Israel (74) Limited
Not pausing it means that we can have work queued into a non-freezable
workqueue, which, in resume, are re-activated before the driver's
resume.
The TCM work might send command to the FW before we resumed the device,
leading to an assert.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Change-Id: I44df9cf9183b5143df8078131e0d87c0fd7e1763
---
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
index f5a41f275d99..110690da63ee 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
@@ -3214,6 +3214,8 @@ void iwl_mvm_fast_suspend(struct iwl_mvm *mvm)
IWL_DEBUG_WOWLAN(mvm, "Starting fast suspend flow\n");
+ iwl_mvm_pause_tcm(mvm, true);
+
mvm->fast_resume = true;
set_bit(IWL_MVM_STATUS_IN_D3, &mvm->status);
@@ -3270,6 +3272,8 @@ int iwl_mvm_fast_resume(struct iwl_mvm *mvm)
mvm->trans->state = IWL_TRANS_NO_FW;
}
+ iwl_mvm_resume_tcm(mvm);
+
out:
clear_bit(IWL_MVM_STATUS_IN_D3, &mvm->status);
mvm->fast_resume = false;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 2/2] wifi: ath12k: Fix firmware stats leak when pdev list is empty
From: Saikiran B @ 2026-01-27 4:40 UTC (permalink / raw)
To: Baochen Qiang; +Cc: ath12k, linux-wireless, kvalo
In-Reply-To: <CAAFDt1sxWMb1xPaWGWGE1XVFxRKwjOuQPZ__fNTH2+ujXJ6d5A@mail.gmail.com>
I have analyzed the logs and code flow in depth to provide more
definitive answers for your questions.
The log entries showing the failure are:
[ 563.574076] ath12k_pci 0004:01:00.0: failed to pull fw stats: -71
[ 564.575896] ath12k_pci 0004:01:00.0: time out while waiting for get fw stats
1. Why are other stats populated?
The "failed to pull fw stats: -71" error is not the initial failure
but a symptom that appears after repeated operations. The leak happens
during *successful* calls prior to this error.
Code flow proving the leak:
- ath12k_mac_get_fw_stats() sends WMI_REQUEST_PDEV_STAT.
- Firmware responds. ath12k_update_stats_event() parses the response.
- ath12k_wmi_fw_stats_process() is called, which splices 'vdevs' and
'beacon' stats into ar->fw_stats.vdevs/bcn.
- ath12k_mac_get_fw_stats() returns 0 (Success).
- In ath12k_mac_op_get_txpower(), the check `if (!pdev)` fails if the
pdev-specific list is empty (but vdev list is NOT empty).
- The function exits via `err_fallback` WITHOUT calling ath12k_fw_stats_reset().
- Result: The 'vdev' and 'beacon' stats that were spliced into
ar->fw_stats remain there, leaking memory and accumulating with every
call.
2. Exact place where -71 is printed:
The error "failed to pull fw stats: -71" is printed in
[ath12k_update_stats_event()](drivers/net/wireless/ath/ath12k/wmi.c).
It corresponds to "ret = ath12k_wmi_pull_fw_stats()" returning -EPROTO.
This propagates from
[ath12k_wmi_tlv_fw_stats_data_parse()](drivers/net/wireless/ath/ath12k/wmi.c),
when buffer validation checks (like `len < sizeof(*src)`) fail.
Conclusion:
The fix in my patch (resetting stats when `!pdev`) is critical because
it ensures that the accumulated 'vdev' and 'beacon' stats are freed
even when the 'pdev' list ends up empty.
Let me know if you need anything else.
Thanks & Regards,
Saikiran
On Tue, Jan 27, 2026 at 9:47 AM Saikiran B <bjsaikiran@gmail.com> wrote:
>
> Hi Baochen,
>
> Regarding your questions:
>
> "Are other stats populated?"
>
> Yes. When ath12k_mac_get_fw_stats() returns success (0), it means the
> firmware response was received and valid WMI events were processed.
> The firmware response to WMI_REQUEST_PDEV_STAT typically includes
> multiple stats TLVs (vdev stats, beacon stats, etc.). Even if the
> "pdev stats" list ends up empty (e.g., due to specific filtering or
> availability), the firmware should have populated other lists (like
> vdevs or beacons) in the ar->fw_stats structure. If we don't reset,
> these valid entries leak and accumulate.
>
> "Where exactly is -71 (EPROTO) printed?"
>
> The log "failed to pull fw stats: -71" is printed in
> ath12k_update_stats_event() (wmi.c line 8500 in my tree). This error
> code (-EPROTO) propagates from ath12k_wmi_tlv_fw_stats_data_parse(),
> where it is returned when buffer validation checks fail (e.g., if (len
> < sizeof(*src))). This failure suggests that the accumulated state or
> memory corruption from the leak eventually causes the parser to fail
> on subsequent events.
>
> So, fixing the leak is necessary for correctness regardless of the
> specific side-effect error code.
>
> Thanks & Regards,
> Saikiran
>
> On Tue, Jan 27, 2026 at 8:57 AM Baochen Qiang
> <baochen.qiang@oss.qualcomm.com> wrote:
> >
> >
> >
> > On 1/26/2026 5:52 PM, Saikiran wrote:
> > > The commits bd6ec8111e65 and 2977567b244f changed firmware stats handling
> > > to be caller-driven, requiring explicit ath12k_fw_stats_reset() calls
> > > after using ath12k_mac_get_fw_stats().
> > >
> > > In ath12k_mac_op_get_txpower(), when ath12k_mac_get_fw_stats() succeeds
> > > but the pdev stats list is empty, the function exits without calling
> > > ath12k_fw_stats_reset(). Even though the pdev list is empty, the firmware
> > > may have populated other stats lists (vdevs, beacons, etc.) in the
> >
> > 'may' is not enough, we need to be 100% sure whether other stats are populated. This is
> > critical for us to find the root cause.
> >
> > > ar->fw_stats structure.
> > >
> > > Without resetting the stats buffer, this data accumulates across multiple
> > > calls, eventually causing the stats buffer to overflow and leading to
> > > firmware communication failures (error -71/EPROTO) during subsequent
> > > operations.
> > >
> > > The issue manifests during 5GHz scanning which triggers multiple TX power
> > > queries. Symptoms include:
> > > - "failed to pull fw stats: -71" errors in dmesg
> >
> > still, can you please check the logs to see at which exact place is this printed?
> >
> > > - 5GHz networks not detected despite hardware support
> > > - 2.4GHz networks work normally
> > >
> > > Fix by calling ath12k_fw_stats_reset() when the pdev list is empty,
> > > ensuring the stats buffer is properly cleaned up even when only partial
> > > stats data is received from firmware.
> > >
> > > Fixes: bd6ec8111e65 ("wifi: ath12k: Make firmware stats reset caller-driven")
> > > Link: https://bugs.launchpad.net/ubuntu-concept/+bug/2138308
> > > Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302 (Lenovo Yoga Slim 7x)
> > > Signed-off-by: Saikiran <bjsaikiran@gmail.com>
> > > ---
> > > drivers/net/wireless/ath/ath12k/mac.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
> > > index e0e49f782bf8..6e35c3ee9864 100644
> > > --- a/drivers/net/wireless/ath/ath12k/mac.c
> > > +++ b/drivers/net/wireless/ath/ath12k/mac.c
> > > @@ -5169,6 +5169,7 @@ static int ath12k_mac_op_get_txpower(struct ieee80211_hw *hw,
> > > struct ath12k_fw_stats_pdev, list);
> > > if (!pdev) {
> > > spin_unlock_bh(&ar->data_lock);
> > > + ath12k_fw_stats_reset(ar);
> > > goto err_fallback;
> > > }
> > >
> >
^ permalink raw reply
* Re: [PATCH v2 2/2] wifi: ath12k: Fix firmware stats leak when pdev list is empty
From: Saikiran B @ 2026-01-27 4:17 UTC (permalink / raw)
To: Baochen Qiang; +Cc: ath12k, linux-wireless, kvalo
In-Reply-To: <9ca7ceac-2799-4993-844c-8427508c7d9b@oss.qualcomm.com>
Hi Baochen,
Regarding your questions:
"Are other stats populated?"
Yes. When ath12k_mac_get_fw_stats() returns success (0), it means the
firmware response was received and valid WMI events were processed.
The firmware response to WMI_REQUEST_PDEV_STAT typically includes
multiple stats TLVs (vdev stats, beacon stats, etc.). Even if the
"pdev stats" list ends up empty (e.g., due to specific filtering or
availability), the firmware should have populated other lists (like
vdevs or beacons) in the ar->fw_stats structure. If we don't reset,
these valid entries leak and accumulate.
"Where exactly is -71 (EPROTO) printed?"
The log "failed to pull fw stats: -71" is printed in
ath12k_update_stats_event() (wmi.c line 8500 in my tree). This error
code (-EPROTO) propagates from ath12k_wmi_tlv_fw_stats_data_parse(),
where it is returned when buffer validation checks fail (e.g., if (len
< sizeof(*src))). This failure suggests that the accumulated state or
memory corruption from the leak eventually causes the parser to fail
on subsequent events.
So, fixing the leak is necessary for correctness regardless of the
specific side-effect error code.
Thanks & Regards,
Saikiran
On Tue, Jan 27, 2026 at 8:57 AM Baochen Qiang
<baochen.qiang@oss.qualcomm.com> wrote:
>
>
>
> On 1/26/2026 5:52 PM, Saikiran wrote:
> > The commits bd6ec8111e65 and 2977567b244f changed firmware stats handling
> > to be caller-driven, requiring explicit ath12k_fw_stats_reset() calls
> > after using ath12k_mac_get_fw_stats().
> >
> > In ath12k_mac_op_get_txpower(), when ath12k_mac_get_fw_stats() succeeds
> > but the pdev stats list is empty, the function exits without calling
> > ath12k_fw_stats_reset(). Even though the pdev list is empty, the firmware
> > may have populated other stats lists (vdevs, beacons, etc.) in the
>
> 'may' is not enough, we need to be 100% sure whether other stats are populated. This is
> critical for us to find the root cause.
>
> > ar->fw_stats structure.
> >
> > Without resetting the stats buffer, this data accumulates across multiple
> > calls, eventually causing the stats buffer to overflow and leading to
> > firmware communication failures (error -71/EPROTO) during subsequent
> > operations.
> >
> > The issue manifests during 5GHz scanning which triggers multiple TX power
> > queries. Symptoms include:
> > - "failed to pull fw stats: -71" errors in dmesg
>
> still, can you please check the logs to see at which exact place is this printed?
>
> > - 5GHz networks not detected despite hardware support
> > - 2.4GHz networks work normally
> >
> > Fix by calling ath12k_fw_stats_reset() when the pdev list is empty,
> > ensuring the stats buffer is properly cleaned up even when only partial
> > stats data is received from firmware.
> >
> > Fixes: bd6ec8111e65 ("wifi: ath12k: Make firmware stats reset caller-driven")
> > Link: https://bugs.launchpad.net/ubuntu-concept/+bug/2138308
> > Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302 (Lenovo Yoga Slim 7x)
> > Signed-off-by: Saikiran <bjsaikiran@gmail.com>
> > ---
> > drivers/net/wireless/ath/ath12k/mac.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
> > index e0e49f782bf8..6e35c3ee9864 100644
> > --- a/drivers/net/wireless/ath/ath12k/mac.c
> > +++ b/drivers/net/wireless/ath/ath12k/mac.c
> > @@ -5169,6 +5169,7 @@ static int ath12k_mac_op_get_txpower(struct ieee80211_hw *hw,
> > struct ath12k_fw_stats_pdev, list);
> > if (!pdev) {
> > spin_unlock_bh(&ar->data_lock);
> > + ath12k_fw_stats_reset(ar);
> > goto err_fallback;
> > }
> >
>
^ 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