summaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)Author
2025-07-15Merge tag 'iwlwifi-fixes-2025-07-15' of ↵Johannes Berg
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Miri Korenblit says: ==================== iwlwifi-fixes - missing unlock in error path - Avoid FW assert on bad command values - fix kernel panic due to incorrect index calculation ==================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: iwlwifi: Fix botched indexing conversionVille Syrjälä
The conversion from compiler assisted indexing to manual indexing wasn't done correctly. The array is still made up of __le16 elements so multiplying the outer index by the element size is not what we want. Fix it up. This causes the kernel to oops when trying to transfer any significant amount of data over wifi: BUG: unable to handle page fault for address: ffffc900009f5282 PGD 100000067 P4D 100000067 PUD 1000fb067 PMD 102e82067 PTE 0 Oops: Oops: 0002 [#1] SMP CPU: 1 UID: 0 PID: 99 Comm: kworker/u8:3 Not tainted 6.15.0-rc2-cl-bisect3-00604-g6204d5130a64-dirty #78 PREEMPT Hardware name: Dell Inc. Latitude E5400 /0D695C, BIOS A19 06/13/2013 Workqueue: events_unbound cfg80211_wiphy_work [cfg80211] RIP: 0010:iwl_trans_pcie_tx+0x4dd/0xe60 [iwlwifi] Code: 00 00 66 81 fa ff 0f 0f 87 42 09 00 00 3d ff 00 00 00 0f 8f 37 09 00 00 41 c1 e0 0c 41 09 d0 48 8d 14 b6 48 c1 e2 07 48 01 ca <66> 44 89 04 57 48 8d 0c 12 83 f8 3f 0f 8e 84 01 00 00 41 8b 85 80 RSP: 0018:ffffc900001c3b50 EFLAGS: 00010206 RAX: 00000000000000c1 RBX: ffff88810b180028 RCX: 00000000000000c1 RDX: 0000000000002141 RSI: 000000000000000d RDI: ffffc900009f1000 RBP: 0000000000000002 R08: 0000000000000025 R09: ffffffffa050fa60 R10: 00000000fbdbf4bc R11: 0000000000000082 R12: ffff88810e5ade40 R13: ffff88810af81588 R14: 000000000000001a R15: ffff888100dfe0c8 FS: 0000000000000000(0000) GS:ffff8881998c3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc900009f5282 CR3: 0000000001e39000 CR4: 00000000000426f0 Call Trace: <TASK> ? rcu_is_watching+0xd/0x40 ? __iwl_dbg+0xb1/0xe0 [iwlwifi] iwlagn_tx_skb+0x8e2/0xcb0 [iwldvm] iwlagn_mac_tx+0x18/0x30 [iwldvm] ieee80211_handle_wake_tx_queue+0x6c/0xc0 [mac80211] ieee80211_agg_start_txq+0x140/0x2e0 [mac80211] ieee80211_agg_tx_operational+0x126/0x210 [mac80211] ieee80211_process_addba_resp+0x27b/0x2a0 [mac80211] ieee80211_iface_work+0x4bd/0x4d0 [mac80211] ? _raw_spin_unlock_irq+0x1f/0x40 cfg80211_wiphy_work+0x117/0x1f0 [cfg80211] process_one_work+0x1ee/0x570 worker_thread+0x1c5/0x3b0 ? bh_worker+0x240/0x240 kthread+0x110/0x220 ? kthread_queue_delayed_work+0x90/0x90 ret_from_fork+0x28/0x40 ? kthread_queue_delayed_work+0x90/0x90 ret_from_fork_asm+0x11/0x20 </TASK> Modules linked in: ctr aes_generic ccm sch_fq_codel bnep xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables btusb btrtl btintel btbcm bluetooth ecdh_generic ecc libaes hid_generic usbhid hid binfmt_misc joydev mousedev snd_hda_codec_hdmi iwldvm snd_hda_codec_idt snd_hda_codec_generic mac80211 coretemp iTCO_wdt watchdog kvm_intel i2c_dev snd_hda_intel libarc4 kvm snd_intel_dspcfg sdhci_pci sdhci_uhs2 snd_hda_codec iwlwifi sdhci irqbypass cqhci snd_hwdep snd_hda_core cfg80211 firewire_ohci mmc_core psmouse snd_pcm i2c_i801 firewire_core pcspkr led_class uhci_hcd i2c_smbus tg3 crc_itu_t iosf_mbi snd_timer rfkill libphy ehci_pci snd ehci_hcd lpc_ich mfd_core usbcore video intel_agp usb_common soundcore intel_gtt evdev agpgart parport_pc wmi parport backlight CR2: ffffc900009f5282 ---[ end trace 0000000000000000 ]--- RIP: 0010:iwl_trans_pcie_tx+0x4dd/0xe60 [iwlwifi] Code: 00 00 66 81 fa ff 0f 0f 87 42 09 00 00 3d ff 00 00 00 0f 8f 37 09 00 00 41 c1 e0 0c 41 09 d0 48 8d 14 b6 48 c1 e2 07 48 01 ca <66> 44 89 04 57 48 8d 0c 12 83 f8 3f 0f 8e 84 01 00 00 41 8b 85 80 RSP: 0018:ffffc900001c3b50 EFLAGS: 00010206 RAX: 00000000000000c1 RBX: ffff88810b180028 RCX: 00000000000000c1 RDX: 0000000000002141 RSI: 000000000000000d RDI: ffffc900009f1000 RBP: 0000000000000002 R08: 0000000000000025 R09: ffffffffa050fa60 R10: 00000000fbdbf4bc R11: 0000000000000082 R12: ffff88810e5ade40 R13: ffff88810af81588 R14: 000000000000001a R15: ffff888100dfe0c8 FS: 0000000000000000(0000) GS:ffff8881998c3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc900009f5282 CR3: 0000000001e39000 CR4: 00000000000426f0 Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: disabled ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- Cc: Miri Korenblit <miriam.rachel.korenblit@intel.com> Fixes: 6204d5130a64 ("wifi: iwlwifi: use bc entries instead of bc table also for pre-ax210") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20250711205744.28723-1-ville.syrjala@linux.intel.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2025-07-11wifi: ath12k: Fix packets received in WBM error ring with REO LUT enabledNithyanantham Paramasivam
Currently, packets are being received into the WBM error ring when REO queue lookup is enabled, resulting in degraded RX performance. The issue arises because the REO queue LUT TID memory reference is set to zero-it's being assigned before the memory is allocated. Fix this by assigning the REO queue TID memory reference in the LUT immediately after memory allocation to ensure correct packet processing. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Reported-by: Tanguy Serrat <tanguy@squaremind.io> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220282 Fixes: 3b9cbce6fdd3 ("wifi: ath12k: alloc REO queue per station") Signed-off-by: Nithyanantham Paramasivam <nithyanantham.paramasivam@oss.qualcomm.com> Reviewed-by: Baochen Qiang <quic_bqiang@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250710011754.559817-1-nithyanantham.paramasivam@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-07-09wifi: iwlwifi: mask reserved bits in chan_state_active_bitmapPagadala Yesu Anjaneyulu
Mask the reserved bits as firmware will assert if reserved bits are set. Fixes: ef7ddf4e2f94 ("wifi: iwlwifi: Add support for LARI_CONFIG_CHANGE_CMD v12") Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709065608.7a72c70bdc9d.Ic9be0a3fc3aabde0c4b88568f3bb7b76e375f8d4@changeid
2025-07-07wifi: mt76: mt792x: Limit the concurrent STA and SoftAP to operate on the ↵Leon Yen
same channel Due to the lack of NoA(Notice of Absence) mechanism in SoftAP mode, it is inappropriate to allow concurrent SoftAP and STA to operate on the different channels. This patch restricts the concurrent SoftAP and STA to be setup on the same channel only. Signed-off-by: Leon Yen <leon.yen@mediatek.com> Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com> Link: https://patch.msgid.link/20250625073720.1385210-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-07-07wifi: mt76: mt7925: Fix null-ptr-deref in mt7925_thermal_init()Henry Martin
devm_kasprintf() returns NULL on error. Currently, mt7925_thermal_init() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. Fixes: 396e41a74a88 ("wifi: mt76: mt7925: support temperature sensor") Signed-off-by: Henry Martin <bsdhenryma@tencent.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20250625124901.1839832-1-bsdhenryma@tencent.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-07-07wifi: mt76: fix queue assignment for deauth packetsFelix Fietkau
When running in AP mode and deauthenticating a client that's in powersave mode, the disassoc/deauth packet can get stuck in a tx queue along with other buffered frames. This can fill up hardware queues with frames that are only released after the WTBL slot is reused for another client. Fix this by moving deauth packets to the ALTX queue. Reported-by: Chad Monroe <chad.monroe@adtran.com> Link: https://patch.msgid.link/20250707154702.1726-2-nbd@nbd.name Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-07-07wifi: mt76: add a wrapper for wcid access with validationFelix Fietkau
Several places use rcu_dereference to get a wcid entry without validating if the index exceeds the array boundary. Fix this by using a helper function, which handles validation. Link: https://patch.msgid.link/20250707154702.1726-1-nbd@nbd.name Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-07-07wifi: mt76: mt7921: prevent decap offload config before STA initializationDeren Wu
The decap offload configuration should only be applied after the STA has been successfully initialized. Attempting to configure it earlier can lead to corruption of the MAC configuration in the chip's hardware state. Add an early check for `msta->deflink.wcid.sta` to ensure the station peer is properly initialized before proceeding with decapsulation offload configuration. Cc: stable@vger.kernel.org Fixes: 24299fc869f7 ("mt76: mt7921: enable rx header traslation offload") Signed-off-by: Deren Wu <deren.wu@mediatek.com> Link: https://patch.msgid.link/f23a72ba7a3c1ad38ba9e13bb54ef21d6ef44ffb.1748149855.git.deren.wu@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-07-07wifi: mt76: mt7925: prevent NULL pointer dereference in ↵Deren Wu
mt7925_sta_set_decap_offload() Add a NULL check for msta->vif before accessing its members to prevent a kernel panic in AP mode deployment. This also fix the issue reported in [1]. The crash occurs when this function is triggered before the station is fully initialized. The call trace shows a page fault at mt7925_sta_set_decap_offload() due to accessing resources when msta->vif is NULL. Fix this by adding an early return if msta->vif is NULL and also check wcid.sta is ready. This ensures we only proceed with decap offload configuration when the station's state is properly initialized. [14739.655703] Unable to handle kernel paging request at virtual address ffffffffffffffa0 [14739.811820] CPU: 0 UID: 0 PID: 895854 Comm: hostapd Tainted: G [14739.821394] Tainted: [C]=CRAP, [O]=OOT_MODULE [14739.825746] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) [14739.831577] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [14739.838538] pc : mt7925_sta_set_decap_offload+0xc0/0x1b8 [mt7925_common] [14739.845271] lr : mt7925_sta_set_decap_offload+0x58/0x1b8 [mt7925_common] [14739.851985] sp : ffffffc085efb500 [14739.855295] x29: ffffffc085efb500 x28: 0000000000000000 x27: ffffff807803a158 [14739.862436] x26: ffffff8041ececb8 x25: 0000000000000001 x24: 0000000000000001 [14739.869577] x23: 0000000000000001 x22: 0000000000000008 x21: ffffff8041ecea88 [14739.876715] x20: ffffff8041c19ca0 x19: ffffff8078031fe0 x18: 0000000000000000 [14739.883853] x17: 0000000000000000 x16: ffffffe2aeac1110 x15: 000000559da48080 [14739.890991] x14: 0000000000000001 x13: 0000000000000000 x12: 0000000000000000 [14739.898130] x11: 0a10020001008e88 x10: 0000000000001a50 x9 : ffffffe26457bfa0 [14739.905269] x8 : ffffff8042013bb0 x7 : ffffff807fb6cbf8 x6 : dead000000000100 [14739.912407] x5 : dead000000000122 x4 : ffffff80780326c8 x3 : 0000000000000000 [14739.919546] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff8041ececb8 [14739.926686] Call trace: [14739.929130] mt7925_sta_set_decap_offload+0xc0/0x1b8 [mt7925_common] [14739.935505] ieee80211_check_fast_rx+0x19c/0x510 [mac80211] [14739.941344] _sta_info_move_state+0xe4/0x510 [mac80211] [14739.946860] sta_info_move_state+0x1c/0x30 [mac80211] [14739.952116] sta_apply_auth_flags.constprop.0+0x90/0x1b0 [mac80211] [14739.958708] sta_apply_parameters+0x234/0x5e0 [mac80211] [14739.964332] ieee80211_add_station+0xdc/0x190 [mac80211] [14739.969950] nl80211_new_station+0x46c/0x670 [cfg80211] [14739.975516] genl_family_rcv_msg_doit+0xdc/0x150 [14739.980158] genl_rcv_msg+0x218/0x298 [14739.983830] netlink_rcv_skb+0x64/0x138 [14739.987670] genl_rcv+0x40/0x60 [14739.990816] netlink_unicast+0x314/0x380 [14739.994742] netlink_sendmsg+0x198/0x3f0 [14739.998664] __sock_sendmsg+0x64/0xc0 [14740.002324] ____sys_sendmsg+0x260/0x298 [14740.006242] ___sys_sendmsg+0xb4/0x110 Cc: stable@vger.kernel.org Link: https://github.com/morrownr/USB-WiFi/issues/603 [1] Fixes: b859ad65309a ("wifi: mt76: mt7925: add link handling in mt7925_sta_set_decap_offload") Signed-off-by: Deren Wu <deren.wu@mediatek.com> Link: https://patch.msgid.link/35aedbffa050e98939264300407a52ba4e236d52.1748149855.git.deren.wu@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-07-07wifi: mt76: mt7925: fix incorrect scan probe IE handling for hw_scanMing Yen Hsieh
The IEs should be processed and filled into the command tlv separately according to each band. Cc: stable@vger.kernel.org Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com> Link: https://patch.msgid.link/20250616063649.1100503-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-07-07wifi: mt76: mt7925: fix invalid array index in ssid assignment during hw scanMichael Lo
Update the destination index to use 'n_ssids', which is incremented only when a valid SSID is present. Previously, both mt76_connac_mcu_hw_scan() and mt7925_mcu_hw_scan() used the loop index 'i' for the destination array, potentially leaving gaps if any source SSIDs had zero length. Cc: stable@vger.kernel.org Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Michael Lo <michael.lo@mediatek.com> Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com> Link: https://patch.msgid.link/20250612062046.160598-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-07-07wifi: mt76: mt7925: fix the wrong config for tx interruptMing Yen Hsieh
MT_INT_TX_DONE_MCU_WM may cause tx interrupt to be mishandled during a reset failure, leading to the reset process failing. By using MT_INT_TX_DONE_MCU instead of MT_INT_TX_DONE_MCU_WM, the handling of tx interrupt is improved. Cc: stable@vger.kernel.org Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com> Link: https://patch.msgid.link/20250612060931.135635-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-07-07wifi: mt76: Remove RCU section in mt7996_mac_sta_rc_work()Lorenzo Bianconi
Since mt7996_mcu_add_rate_ctrl() and mt7996_mcu_set_fixed_field() can't run in atomic context, move RCU critical section in mt7996_mcu_add_rate_ctrl() and mt7996_mcu_set_fixed_field(). This patch fixes a 'sleep while atomic' issue in mt7996_mac_sta_rc_work(). Fixes: 0762bdd30279 ("wifi: mt76: mt7996: rework mt7996_mac_sta_rc_work to support MLO") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Tested-by: Ben Greear <greearb@candelatech.com> Link: https://patch.msgid.link/20250605-mt7996-sleep-while-atomic-v1-5-d46d15f9203c@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-07-07wifi: mt76: Move RCU section in mt7996_mcu_add_rate_ctrl()Lorenzo Bianconi
Since mt76_mcu_skb_send_msg() routine can't be executed in atomic context, move RCU section in mt7996_mcu_add_rate_ctrl() and execute mt76_mcu_skb_send_msg() in non-atomic context. This is a preliminary patch to fix a 'sleep while atomic' issue in mt7996_mac_sta_rc_work(). Fixes: 0762bdd30279 ("wifi: mt76: mt7996: rework mt7996_mac_sta_rc_work to support MLO") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250605-mt7996-sleep-while-atomic-v1-4-d46d15f9203c@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-07-07wifi: mt76: Move RCU section in mt7996_mcu_add_rate_ctrl_fixed()Lorenzo Bianconi
Since mt7996_mcu_set_fixed_field() can't be executed in a RCU critical section, move RCU section in mt7996_mcu_add_rate_ctrl_fixed() and run mt7996_mcu_set_fixed_field() in non-atomic context. This is a preliminary patch to fix a 'sleep while atomic' issue in mt7996_mac_sta_rc_work(). Fixes: 0762bdd30279 ("wifi: mt76: mt7996: rework mt7996_mac_sta_rc_work to support MLO") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250605-mt7996-sleep-while-atomic-v1-3-d46d15f9203c@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-07-07wifi: mt76: Move RCU section in mt7996_mcu_set_fixed_field()Lorenzo Bianconi
Since mt76_mcu_skb_send_msg() routine can't be executed in atomic context, move RCU section in mt7996_mcu_set_fixed_field() and execute mt76_mcu_skb_send_msg() in non-atomic context. This is a preliminary patch to fix a 'sleep while atomic' issue in mt7996_mac_sta_rc_work(). Fixes: 0762bdd30279 ("wifi: mt76: mt7996: rework mt7996_mac_sta_rc_work to support MLO") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250605-mt7996-sleep-while-atomic-v1-2-d46d15f9203c@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-07-07wifi: mt76: Assume __mt76_connac_mcu_alloc_sta_req runs in atomic contextLorenzo Bianconi
Rely on GFP_ATOMIC flag in __mt76_connac_mcu_alloc_sta_req since it can run in atomic context. This is a preliminary patch to fix a 'sleep while atomic' issue in mt7996_mac_sta_rc_work(). Fixes: 0762bdd30279 ("wifi: mt76: mt7996: rework mt7996_mac_sta_rc_work to support MLO") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250605-mt7996-sleep-while-atomic-v1-1-d46d15f9203c@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-07-07wifi: rt2x00: fix remove callback type mismatchFelix Fietkau
The function is used as remove callback for a platform driver. It was missed during the conversion from int to void Fixes: 0edb555a65d1 ("platform: Make platform_driver::remove() return void") Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://patch.msgid.link/20250706092053.97724-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-07wifi: mwifiex: discard erroneous disassoc frames on STA interfaceVitor Soares
When operating in concurrent STA/AP mode with host MLME enabled, the firmware incorrectly sends disassociation frames to the STA interface when clients disconnect from the AP interface. This causes kernel warnings as the STA interface processes disconnect events that don't apply to it: [ 1303.240540] WARNING: CPU: 0 PID: 513 at net/wireless/mlme.c:141 cfg80211_process_disassoc+0x78/0xec [cfg80211] [ 1303.250861] Modules linked in: 8021q garp stp mrp llc rfcomm bnep btnxpuart nls_iso8859_1 nls_cp437 onboard_us [ 1303.327651] CPU: 0 UID: 0 PID: 513 Comm: kworker/u9:2 Not tainted 6.16.0-rc1+ #3 PREEMPT [ 1303.335937] Hardware name: Toradex Verdin AM62 WB on Verdin Development Board (DT) [ 1303.343588] Workqueue: MWIFIEX_RX_WORK_QUEUE mwifiex_rx_work_queue [mwifiex] [ 1303.350856] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1303.357904] pc : cfg80211_process_disassoc+0x78/0xec [cfg80211] [ 1303.364065] lr : cfg80211_process_disassoc+0x70/0xec [cfg80211] [ 1303.370221] sp : ffff800083053be0 [ 1303.373590] x29: ffff800083053be0 x28: 0000000000000000 x27: 0000000000000000 [ 1303.380855] x26: 0000000000000000 x25: 00000000ffffffff x24: ffff000002c5b8ae [ 1303.388120] x23: ffff000002c5b884 x22: 0000000000000001 x21: 0000000000000008 [ 1303.395382] x20: ffff000002c5b8ae x19: ffff0000064dd408 x18: 0000000000000006 [ 1303.402646] x17: 3a36333a61623a30 x16: 32206d6f72662063 x15: ffff800080bfe048 [ 1303.409910] x14: ffff000003625300 x13: 0000000000000001 x12: 0000000000000000 [ 1303.417173] x11: 0000000000000002 x10: ffff000003958600 x9 : ffff000003625300 [ 1303.424434] x8 : ffff00003fd9ef40 x7 : ffff0000039fc280 x6 : 0000000000000002 [ 1303.431695] x5 : ffff0000038976d4 x4 : 0000000000000000 x3 : 0000000000003186 [ 1303.438956] x2 : 000000004836ba20 x1 : 0000000000006986 x0 : 00000000d00479de [ 1303.446221] Call trace: [ 1303.448722] cfg80211_process_disassoc+0x78/0xec [cfg80211] (P) [ 1303.454894] cfg80211_rx_mlme_mgmt+0x64/0xf8 [cfg80211] [ 1303.460362] mwifiex_process_mgmt_packet+0x1ec/0x460 [mwifiex] [ 1303.466380] mwifiex_process_sta_rx_packet+0x1bc/0x2a0 [mwifiex] [ 1303.472573] mwifiex_handle_rx_packet+0xb4/0x13c [mwifiex] [ 1303.478243] mwifiex_rx_work_queue+0x158/0x198 [mwifiex] [ 1303.483734] process_one_work+0x14c/0x28c [ 1303.487845] worker_thread+0x2cc/0x3d4 [ 1303.491680] kthread+0x12c/0x208 [ 1303.495014] ret_from_fork+0x10/0x20 Add validation in the STA receive path to verify that disassoc/deauth frames originate from the connected AP. Frames that fail this check are discarded early, preventing them from reaching the MLME layer and triggering WARN_ON(). This filtering logic is similar with that used in the ieee80211_rx_mgmt_disassoc() function in mac80211, which drops disassoc frames that don't match the current BSSID (!ether_addr_equal(mgmt->bssid, sdata->vif.cfg.ap_addr)), ensuring only relevant frames are processed. Tested on: - 8997 with FW 16.68.1.p197 Fixes: 36995892c271 ("wifi: mwifiex: add host mlme for client mode") Cc: stable@vger.kernel.org Signed-off-by: Vitor Soares <vitor.soares@toradex.com> Reviewed-by: Jeff Chen <jeff.chen_1@nxp.con> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://patch.msgid.link/20250701142643.658990-1-ivitro@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-30wifi: zd1211rw: Fix potential NULL pointer dereference in zd_mac_tx_to_dev()Daniil Dulov
There is a potential NULL pointer dereference in zd_mac_tx_to_dev(). For example, the following is possible: T0 T1 zd_mac_tx_to_dev() /* len == skb_queue_len(q) */ while (len > ZD_MAC_MAX_ACK_WAITERS) { filter_ack() spin_lock_irqsave(&q->lock, flags); /* position == skb_queue_len(q) */ for (i=1; i<position; i++) skb = __skb_dequeue(q) if (mac->type == NL80211_IFTYPE_AP) skb = __skb_dequeue(q); spin_unlock_irqrestore(&q->lock, flags); skb_dequeue() -> NULL Since there is a small gap between checking skb queue length and skb being unconditionally dequeued in zd_mac_tx_to_dev(), skb_dequeue() can return NULL. Then the pointer is passed to zd_mac_tx_status() where it is dereferenced. In order to avoid potential NULL pointer dereference due to situations like above, check if skb is not NULL before passing it to zd_mac_tx_status(). Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 459c51ad6e1f ("zd1211rw: port to mac80211") Signed-off-by: Daniil Dulov <d.dulov@aladdin.ru> Link: https://patch.msgid.link/20250626114619.172631-1-d.dulov@aladdin.ru Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-29wifi: iwlwifi: pcie: fix locking on invalid TOP resetJohannes Berg
If a TOP reset were to ever be erroneously requested on HW prior to SC, the code warns and returns, but doesn't take care to unlock the mutex in this case. Fix that. Fixes: 909e1be65462 ("wifi: iwlwifi: implement TOP reset") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202506100707.WAnP5ePA-lkp@intel.com/ Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250625204210.19a0378838b1.I6bdc58d4996e995e1358ad94d4cc5017f3abf47b@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2025-06-25Merge tag 'iwlwifi-fixes-2025-06-25' of ↵Johannes Berg
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Miri Korenblit says: ==================== iwlwifi-fixes: fix failure in interface up ==================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-24wifi: iwlwifi: mvm: assume '1' as the default mac_config_cmd versionMiri Korenblit
Unfortunately, FWs of some devices don't have the version of the iwl_mac_config_cmd defined in the TLVs. We send 0 as the 'def argument to iwl_fw_lookup_cmd_ver, so for such FWs, the return value will be 0, leading to a warning, and to not sending the command. Fix this by assuming that the default version is 1. Fixes: 83f3ac2848b4 ("wifi: iwlwifi: Fix incorrect logic on cmd_ver range checking") Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250624071427.2662621-1-miriam.rachel.korenblit@intel.com
2025-06-24wifi: iwlegacy: work around excessive stack usage on clang/kasanArnd Bergmann
In some rare randconfig builds, I seem to trigger a bug in clang where it unrolls a loop but then runs out of registers, which then get spilled to the stack: net/wireless/intel/iwlegacy/4965-rs.c:2262:1: error: stack frame size (1696) exceeds limit (1280) in 'il4965_rs_rate_init' [-Werror,-Wframe-larger-than] This seems to be the same one I saw in the omapdrm driver, and there is an easy workaround by not inlining the il4965_rs_rate_scale_clear_win function. Link: https://github.com/llvm/llvm-project/issues/143908 Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Link: https://patch.msgid.link/20250620113946.3987160-1-arnd@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-18Merge tag 'iwlwifi-fixes-2025-06-18' of ↵Johannes Berg
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Miri Korenblit says: ==================== fixes for 6.16-rc3 ==================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-18wifi: iwlwifi: Fix incorrect logic on cmd_ver range checkingColin Ian King
The current cmd_ver range checking on cmd_ver < 1 && cmd_ver > 3 can never be true because the logical operator && is being used, cmd_ver can never be less than 1 and also greater than 3. Fix this by using the logical || operator. Fixes: df6146a0296e ("wifi: iwlwifi: Add a new version for mac config command") Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://patch.msgid.link/20250522121703.2766764-1-colin.i.king@gmail.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2025-06-18wifi: iwlwifi: dvm: restore n_no_reclaim_cmds settingJohannes Berg
Apparently I accidentally removed this setting in my transport configuration rework, leading to an endless stream of warnings from the PCIe code when relevant notifications are received by the driver from firmware. Restore it. Reported-by: Woody Suwalski <terraluna977@gmail.com> Closes: https://lore.kernel.org/r/e8c45d32-6129-8a5e-af80-ccc42aaf200b@gmail.com/ Fixes: 08e77d5edf70 ("wifi: iwlwifi: rework transport configuration") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20250616134902.222342908ca4.I47a551c86cbc0e9de4f980ca2fd0d67bf4052e50@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2025-06-18wifi: iwlwifi: cfg: Limit cb_size to valid rangePei Xiao
on arm64 defconfig build failed with gcc-8: drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info.c:208:3: include/linux/bitfield.h:195:3: error: call to '__field_overflow' declared with attribute error: value doesn't fit into mask __field_overflow(); \ ^~~~~~~~~~~~~~~~~~ include/linux/bitfield.h:215:2: note: in expansion of macro '____MAKE_OP' ____MAKE_OP(u##size,u##size,,) ^~~~~~~~~~~ include/linux/bitfield.h:218:1: note: in expansion of macro '__MAKE_OP' __MAKE_OP(32) Limit cb_size to valid range to fix it. Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> Link: https://patch.msgid.link/7b373a4426070d50b5afb3269fd116c18ce3aea8.1748332709.git.xiaopei01@kylinos.cn Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2025-06-18wifi: iwlwifi: restore missing initialization of async_handlers_list (again)Miri Korenblit
The initialization of async_handlers_list was accidentally removed in a previous change. Then it was restoted by commit 175e69e33c66 ("wifi: iwlwifi: restore missing initialization of async_handlers_list"). Somehow, the initialization disappeared again. Restote it. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2025-06-18Merge tag 'ath-current-20250617' of ↵Johannes Berg
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath Jeff Johnson says: ================== ath.git updates for v6.16-rc3 Fix the following 3 issues: wifi: ath12k: avoid burning CPU while waiting for firmware stats wifi: ath12k: don't activate more links than firmware supports wifi: carl9170: do not ping device which has failed to load firmware ================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-18wifi: ath6kl: remove WARN on bad firmware inputJohannes Berg
If the firmware gives bad input, that's nothing to do with the driver's stack at this point etc., so the WARN_ON() doesn't add any value. Additionally, this is one of the top syzbot reports now. Just print a message, and as an added bonus, print the sizes too. Reported-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com Tested-by: syzbot+92c6dd14aaa230be6855@syzkaller.appspotmail.com Acked-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Link: https://patch.msgid.link/20250617114529.031a677a348e.I58bf1eb4ac16a82c546725ff010f3f0d2b0cca49@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-17wifi: carl9170: do not ping device which has failed to load firmwareDmitry Antipov
Syzkaller reports [1, 2] crashes caused by an attempts to ping the device which has failed to load firmware. Since such a device doesn't pass 'ieee80211_register_hw()', an internal workqueue managed by 'ieee80211_queue_work()' is not yet created and an attempt to queue work on it causes null-ptr-deref. [1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff [2] https://syzkaller.appspot.com/bug?extid=0d8afba53e8fb2633217 Fixes: e4a668c59080 ("carl9170: fix spurious restart due to high latency") Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Acked-by: Christian Lamparter <chunkeey@gmail.com> Link: https://patch.msgid.link/20250616181205.38883-1-dmantipov@yandex.ru Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-06-17wifi: ath12k: don't wait when there is no vdev startedBaochen Qiang
For WMI_REQUEST_VDEV_STAT request, firmware might split response into multiple events dut to buffer limit, hence currently in ath12k_wmi_fw_stats_process() host waits until all events received. In case there is no vdev started, this results in that below condition would never get satisfied ((++ar->fw_stats.num_vdev_recvd) == total_vdevs_started) consequently the requestor would be blocked until time out. The same applies to WMI_REQUEST_BCN_STAT request as well due to: ((++ar->fw_stats.num_bcn_recvd) == ar->num_started_vdevs) Change to check the number of started vdev first: if it is zero, finish directly; if not, follow the old way. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284.1-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Tested-on: QCN9274 hw2.0 WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1 Fixes: e367c924768b ("wifi: ath12k: Request vdev stats from firmware") Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/20250612-ath12k-fw-fixes-v1-4-12f594f3b857@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-06-17wifi: ath12k: don't use static variables in ath12k_wmi_fw_stats_process()Baochen Qiang
Currently ath12k_wmi_fw_stats_process() is using static variables to count firmware stat events. Taking num_vdev as an example, if for whatever reason (say ar->num_started_vdevs is 0 or firmware bug etc.) the following condition (++num_vdev) == total_vdevs_started is not met, is_end is not set thus num_vdev won't be cleared. Next time when firmware stats is requested again, even if everything is working fine, failure is expected due to the condition above will never be satisfied. The same applies to num_bcn as well. Change to use non-static counters and reset them each time before firmware stats is requested. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284.1-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Tested-on: QCN9274 hw2.0 WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1 Fixes: e367c924768b ("wifi: ath12k: Request vdev stats from firmware") Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/20250612-ath12k-fw-fixes-v1-3-12f594f3b857@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-06-17wifi: ath12k: avoid burning CPU while waiting for firmware statsBaochen Qiang
ath12k_mac_get_fw_stats() is busy polling fw_stats_done flag while waiting firmware finishing sending all events. This is not good as CPU is monopolized and kept burning during the wait. Change to the completion mechanism to fix it. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284.1-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Tested-on: QCN9274 hw2.0 WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1 Fixes: e367c924768b ("wifi: ath12k: Request vdev stats from firmware") Reported-by: Grégoire Stein <gregoire.s93@live.fr> Closes: https://lore.kernel.org/ath12k/AS8P190MB120575BBB25FCE697CD7D4988763A@AS8P190MB1205.EURP190.PROD.OUTLOOK.COM/ Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Tested-by: Grégoire Stein <gregoire.s93@live.fr> Link: https://patch.msgid.link/20250612-ath12k-fw-fixes-v1-2-12f594f3b857@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-06-17wifi: ath12k: fix documentation on firmware statsBaochen Qiang
Regarding the firmware stats events handling, the comment in ath12k_mac_get_fw_stats() says host determines whether all events have been received based on 'end' tag in TLV. This is wrong as there is no such tag at all, actually host makes the decision totally by itself based on the stats type and active pdev/vdev counts etc. Fix it to correctly reflect the logic. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284.1-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Tested-on: QCN9274 hw2.0 WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/20250612-ath12k-fw-fixes-v1-1-12f594f3b857@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-06-17wifi: ath12k: don't activate more links than firmware supportsBaochen Qiang
In case of ML connection, currently all useful links are activated at ASSOC stage: ieee80211_set_active_links(vif, ieee80211_vif_usable_links(vif)) this results in firmware crash when the number of links activated on the same device is more than supported. Since firmware supports activating at most 2 links for a ML connection, to avoid firmware crash, host needs to select 2 links out of the useful links. As the assoc link has already been chosen, the question becomes how to determine partner links. A straightforward principle applied here is that the resulted combination should achieve the best throughput. For that purpose, ideally various factors like bandwidth, RSSI etc should be considered. But that would be too complicate. To make it easy, the choice is to only take hardware modes into consideration. The SBS (single band simultaneously) mode frequency range covers 5 GHz and 6 GHz bands. In this mode, the two individual MACs are both active, with one working on 5g-high band and the other on 5g-low band (from hardware perspective 5 GHz and 6 GHz bands are referred to as a 'large' single 5 GHz band). The DBS (dual band simultaneously) mode covers 2 GHz band and the 'large' 5 GHz band, with one MAC working on 2 GHz band and the other working on 5 GHz band or 6 GHz band. Since 5,6 GHz bands could provide higher bandwidth than 2 GHz band, the preference is given to SBS mode. Other hardware modes results in only one working MAC at any given time, so it is chosen only when both SBS are DBS are not possible. For each hardware mode, if there are more than one partner candidate, just choose the first one. For now only single device MLO case is handled as it is easy. Other cases could be addressed in the future. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250522-ath12k-sbs-dbs-v1-6-54a29e7a3a88@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-06-17wifi: ath12k: update link active in case two links fall on the same MACBaochen Qiang
In case of two links established on the same device in an ML connection, depending on device's hardware mode capability, it is possible that both links fall on the same MAC. Currently, no specific action is taken to address this but just keep both links active. However this would result in lower throughput compared to even one link, because switching between these two links on the resulted MAC significantly impacts throughput. Check if both links fall in the frequency range of a single MAC. If so, send WMI_MLO_LINK_SET_ACTIVE_CMDID command to firmware such that firmware can deactivate one of them. Note the decision of which link getting deactivated is made by firmware, host only sends the vdev lists. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250522-ath12k-sbs-dbs-v1-5-54a29e7a3a88@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-06-17wifi: ath12k: support WMI_MLO_LINK_SET_ACTIVE_CMDID commandBaochen Qiang
Add WMI_MLO_LINK_SET_ACTIVE_CMDID command. This command allows host to send required link information to firmware such that firmware can make decision on activating/deactivating links in various scenarios. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250522-ath12k-sbs-dbs-v1-4-54a29e7a3a88@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-06-17wifi: ath12k: update freq range for each hardware modeBaochen Qiang
Previous patches parse and save hardware MAC frequency range information in ath12k_svc_ext_info structure. Such range represents hardware capability hence needs to be updated based on host information, e.g. guard the range based on host's low/high boundary. So update frequency range. The updated range is saved in ath12k_hw_mode_info structure and would be used when doing vdev activation and link selection in following patches. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250522-ath12k-sbs-dbs-v1-3-54a29e7a3a88@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-06-17wifi: ath12k: parse and save sbs_lower_band_end_freq from ↵Baochen Qiang
WMI_SERVICE_READY_EXT2_EVENTID event Firmware sends the boundary between lower and higher bands in ath12k_wmi_dbs_or_sbs_cap_params structure embedded in WMI_SERVICE_READY_EXT2_EVENTID event. The boundary is needed when updating frequency range in the following patch. So parse and save it for later use. Note ath12k_wmi_dbs_or_sbs_cap_params is placed after some other structures, so placeholders for them are added as well. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250522-ath12k-sbs-dbs-v1-2-54a29e7a3a88@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-06-17wifi: ath12k: parse and save hardware mode info from ↵Baochen Qiang
WMI_SERVICE_READY_EXT_EVENTID event for later use WLAN hardware might support various hardware modes such as DBS (dual band simultaneously), SBS (single band simultaneously) and DBS_OR_SBS etc, see enum wmi_host_hw_mode_config_type. Firmware advertises actual supported modes in WMI_SERVICE_READY_EXT_EVENTID event. For each mode, firmware advertises frequency range each hardware MAC can operate on. In MLO case such information is necessary during vdev activation and link selection (which is done in following patches), so add a new structure ath12k_svc_ext_info to ath12k_wmi_base, then parse and save those information to it for later use. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250522-ath12k-sbs-dbs-v1-1-54a29e7a3a88@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-06-17wifi: ath12k: Avoid CPU busy-wait by handling VDEV_STAT and BCN_STATBjorn Andersson
When the ath12k driver is built without CONFIG_ATH12K_DEBUG, the recently refactored stats code can cause any user space application (such at NetworkManager) to consume 100% CPU for 3 seconds, every time stats are read. Commit 'b8a0d83fe4c7 ("wifi: ath12k: move firmware stats out of debugfs")' moved ath12k_debugfs_fw_stats_request() out of debugfs, by merging the additional logic into ath12k_mac_get_fw_stats(). Among the added responsibility of ath12k_mac_get_fw_stats() was the busy-wait for `fw_stats_done`. Signalling of `fw_stats_done` happens when one of the WMI_REQUEST_PDEV_STAT, WMI_REQUEST_VDEV_STAT, and WMI_REQUEST_BCN_STAT messages are received, but the handling of the latter two commands remained in the debugfs code. As `fw_stats_done` isn't signalled, the calling processes will spin until the timeout (3 seconds) is reached. Moving the handling of these two additional responses out of debugfs resolves the issue. Fixes: b8a0d83fe4c7 ("wifi: ath12k: move firmware stats out of debugfs") Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Tested-by: Abel Vesa <abel.vesa@linaro.org> Link: https://patch.msgid.link/20250609-ath12k-fw-stats-done-v1-1-2b3624656697@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-06-12Merge tag 'net-6.16-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Jakub Kicinski: "Including fixes from bluetooth and wireless. Current release - regressions: - af_unix: allow passing cred for embryo without SO_PASSCRED/SO_PASSPIDFD Current release - new code bugs: - eth: airoha: correct enable mask for RX queues 16-31 - veth: prevent NULL pointer dereference in veth_xdp_rcv when peer disappears under traffic - ipv6: move fib6_config_validate() to ip6_route_add(), prevent invalid routes Previous releases - regressions: - phy: phy_caps: don't skip better duplex match on non-exact match - dsa: b53: fix untagged traffic sent via cpu tagged with VID 0 - Revert "wifi: mwifiex: Fix HT40 bandwidth issue.", it caused transient packet loss, exact reason not fully understood, yet Previous releases - always broken: - net: clear the dst when BPF is changing skb protocol (IPv4 <> IPv6) - sched: sfq: fix a potential crash on gso_skb handling - Bluetooth: intel: improve rx buffer posting to avoid causing issues in the firmware - eth: intel: i40e: make reset handling robust against multiple requests - eth: mlx5: ensure FW pages are always allocated on the local NUMA node, even when device is configure to 'serve' another node - wifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850, prevent kernel crashes - wifi: ath11k: avoid burning CPU in ath11k_debugfs_fw_stats_request() for 3 sec if fw_stats_done is not set" * tag 'net-6.16-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (70 commits) selftests: drv-net: rss_ctx: Add test for ntuple rules targeting default RSS context net: ethtool: Don't check if RSS context exists in case of context 0 af_unix: Allow passing cred for embryo without SO_PASSCRED/SO_PASSPIDFD. ipv6: Move fib6_config_validate() to ip6_route_add(). net: drv: netdevsim: don't napi_complete() from netpoll net/mlx5: HWS, Add error checking to hws_bwc_rule_complex_hash_node_get() veth: prevent NULL pointer dereference in veth_xdp_rcv net_sched: remove qdisc_tree_flush_backlog() net_sched: ets: fix a race in ets_qdisc_change() net_sched: tbf: fix a race in tbf_change() net_sched: red: fix a race in __red_change() net_sched: prio: fix a race in prio_tune() net_sched: sch_sfq: reject invalid perturb period net: phy: phy_caps: Don't skip better duplex macth on non-exact match MAINTAINERS: Update Kuniyuki Iwashima's email address. selftests: net: add test case for NAT46 looping back dst net: clear the dst when changing skb protocol net/mlx5e: Fix number of lanes to UNKNOWN when using data_rate_oper net/mlx5e: Fix leak of Geneve TLV option object net/mlx5: HWS, make sure the uplink is the last destination ...
2025-06-11Merge tag 'ath-current-20250608' of ↵Johannes Berg
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath Jeff Johnson says: ================== ath.git updates for v6.16-rc2 Fix a handful of both build and stability issues across multiple drivers. ================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-11wifi: iwlwifi: fix merge damage related to iwl_pci_resumeEmmanuel Grumbach
The changes I made in wifi: iwlwifi: don't warn if the NIC is gone in resume conflicted with a major rework done in this area. The merge de-facto removed my changes. Re-add them. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20250603091754.70182-1-emmanuel.grumbach@intel.com Fixes: 06c4b2036818 ("Merge tag 'iwlwifi-next-2025-05-15' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-11Revert "wifi: mwifiex: Fix HT40 bandwidth issue."Francesco Dolcini
This reverts commit 4fcfcbe45734 ("wifi: mwifiex: Fix HT40 bandwidth issue.") That commit introduces a regression, when HT40 mode is enabled, received packets are lost, this was experience with W8997 with both SDIO-UART and SDIO-SDIO variants. From an initial investigation the issue solves on its own after some time, but it's not clear what is the reason. Given that this was just a performance optimization, let's revert it till we have a better understanding of the issue and a proper fix. Cc: Jeff Chen <jeff.chen_1@nxp.com> Cc: stable@vger.kernel.org Fixes: 4fcfcbe45734 ("wifi: mwifiex: Fix HT40 bandwidth issue.") Closes: https://lore.kernel.org/all/20250603203337.GA109929@francesco-nb/ Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://patch.msgid.link/20250605130302.55555-1-francesco@dolcini.it [fix commit reference format] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-08treewide, timers: Rename from_timer() to timer_container_of()Ingo Molnar
Move this API to the canonical timer_*() namespace. [ tglx: Redone against pre rc1 ] Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com
2025-06-07wifi: ath12k: fix uaf in ath12k_core_init()Miaoqing Pan
When the execution of ath12k_core_hw_group_assign() or ath12k_core_hw_group_create() fails, the registered notifier chain is not unregistered properly. Its memory is freed after rmmod, which may trigger to a use-after-free (UAF) issue if there is a subsequent access to this notifier chain. Fixes the issue by calling ath12k_core_panic_notifier_unregister() in failure cases. Call trace: notifier_chain_register+0x4c/0x1f0 (P) atomic_notifier_chain_register+0x38/0x68 ath12k_core_init+0x50/0x4e8 [ath12k] ath12k_pci_probe+0x5f8/0xc28 [ath12k] pci_device_probe+0xbc/0x1a8 really_probe+0xc8/0x3a0 __driver_probe_device+0x84/0x1b0 driver_probe_device+0x44/0x130 __driver_attach+0xcc/0x208 bus_for_each_dev+0x84/0x100 driver_attach+0x2c/0x40 bus_add_driver+0x130/0x260 driver_register+0x70/0x138 __pci_register_driver+0x68/0x80 ath12k_pci_init+0x30/0x68 [ath12k] ath12k_init+0x28/0x78 [ath12k] Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: 6f245ea0ec6c ("wifi: ath12k: introduce device group abstraction") Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/20250604055250.1228501-1-miaoqing.pan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
generated by cgit (git 2.34.1) at 2025-07-30 03:44:54 +0000