summaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)AuthorFilesLines
2026-03-04net: intel: fix PCI device ID conflict between i40e and ipw2200Ethan Nelson-Moore1-1/+7
[ Upstream commit d03e094473ecdeb68d853752ba467abe13e1de44 ] The ID 8086:104f is matched by both i40e and ipw2200. The same device ID should not be in more than one driver, because in that case, which driver is used is unpredictable. Fix this by taking advantage of the fact that i40e devices use PCI_CLASS_NETWORK_ETHERNET and ipw2200 devices use PCI_CLASS_NETWORK_OTHER to differentiate the devices. Fixes: 2e45d3f4677a ("i40e: Add support for X710 B/P & SFP+ cards") Cc: stable@vger.kernel.org Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Link: https://patch.msgid.link/20260210021235.16315-1-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04net: qrtr: Drop the MHI auto_queue feature for IPCR DL channelsManivannan Sadhasivam2-8/+0
[ Upstream commit 51731792a25cb312ca94cdccfa139eb46de1b2ef ] MHI stack offers the 'auto_queue' feature, which allows the MHI stack to auto queue the buffers for the RX path (DL channel). Though this feature simplifies the client driver design, it introduces race between the client drivers and the MHI stack. For instance, with auto_queue, the 'dl_callback' for the DL channel may get called before the client driver is fully probed. This means, by the time the dl_callback gets called, the client driver's structures might not be initialized, leading to NULL ptr dereference. Currently, the drivers have to workaround this issue by initializing the internal structures before calling mhi_prepare_for_transfer_autoqueue(). But even so, there is a chance that the client driver's internal code path may call the MHI queue APIs before mhi_prepare_for_transfer_autoqueue() is called, leading to similar NULL ptr dereference. This issue has been reported on the Qcom X1E80100 CRD machines affecting boot. So to properly fix all these races, drop the MHI 'auto_queue' feature altogether and let the client driver (QRTR) manage the RX buffers manually. In the QRTR driver, queue the RX buffers based on the ring length during probe and recycle the buffers in 'dl_callback' once they are consumed. This also warrants removing the setting of 'auto_queue' flag from controller drivers. Currently, this 'auto_queue' feature is only enabled for IPCR DL channel. So only the QRTR client driver requires the modification. Fixes: 227fee5fc99e ("bus: mhi: core: Add an API for auto queueing buffers for DL channel") Fixes: 68a838b84eff ("net: qrtr: start MHI channel after endpoit creation") Reported-by: Johan Hovold <johan@kernel.org> Closes: https://lore.kernel.org/linux-arm-msm/ZyTtVdkCCES0lkl4@hovoldconsulting.com Suggested-by: Chris Lew <quic_clew@quicinc.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Acked-by: Jeff Johnson <jjohnson@kernel.org> # drivers/net/wireless/ath/... Acked-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251218-qrtr-fix-v2-1-c7499bfcfbe0@oss.qualcomm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: brcmfmac: Fix potential kernel oops when probe failsMarek Szyprowski3-8/+8
[ Upstream commit 243307a0d1b0d01538e202c00454c28b21d4432e ] When probe of the sdio brcmfmac device fails for some reasons (i.e. missing firmware), the sdiodev->bus is set to error instead of NULL, thus the cleanup later in brcmf_sdio_remove() tries to free resources via invalid bus pointer. This happens because sdiodev->bus is set 2 times: first in brcmf_sdio_probe() and second time in brcmf_sdiod_probe(). Fix this by chaning the brcmf_sdio_probe() function to return the error code and set sdio->bus only there. Fixes: 0ff0843310b7 ("wifi: brcmfmac: Add optional lpo clock enable support") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Arend van Spriel<arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260203102133.1478331-1-m.szyprowski@samsung.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: ath10k: fix lock protection in ath10k_wmi_event_peer_sta_ps_state_chg()Ziyi Guo1-2/+2
[ Upstream commit 820ba7dd6859ef8b1eaf6014897e7aa4756fc65d ] ath10k_wmi_event_peer_sta_ps_state_chg() uses lockdep_assert_held() to assert that ar->data_lock should be held by the caller, but neither ath10k_wmi_10_2_op_rx() nor ath10k_wmi_10_4_op_rx() acquire this lock before calling this function. The field arsta->peer_ps_state is documented as protected by ar->data_lock in core.h, and other accessors (ath10k_peer_ps_state_disable, ath10k_dbg_sta_read_peer_ps_state) properly acquire this lock. Add spin_lock_bh()/spin_unlock_bh() around the peer_ps_state update, and remove the lockdep_assert_held() to be aligned with new locking, following the pattern used by other WMI event handlers in the driver. Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260123175611.767731-1-n7l8m4@u.northwestern.edu [removed excess blank line] Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw89: pci: restore LDO setting after device resumeDian-Syuan Yang1-0/+1
[ Upstream commit af1e82232b988f8fc6d635c60609765e49221a64 ] 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> Link: https://patch.msgid.link/20260127085036.44060-6-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw89: pci: validate release report content before using for RTL8922DEPing-Ke Shih1-2/+4
[ Upstream commit 5f93d611b33a05bd03d6843c8efe8cb6a1992620 ] The commit 957eda596c76 ("wifi: rtw89: pci: validate sequence number of TX release report") does validation on existing chips, which somehow a release report of SKB becomes malformed. As no clear cause found, add rules ahead for RTL8922DE to avoid crash if it happens. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260123013957.16418-11-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: iwlegacy: add missing mutex protection in il3945_store_measurement()Ziyi Guo1-0/+2
[ Upstream commit 4dd1dda65265ecbc9f43ffc08e333684cf715152 ] il3945_store_measurement() calls il3945_get_measurement() which internally calls il_send_cmd_sync() without holding il->mutex. However, il_send_cmd_sync() has lockdep_assert_held(&il->mutex) indicating that callers must hold this lock. Other sysfs store functions in the same file properly acquire the mutex: - il3945_store_flags() acquires mutex at 3945-mac.c:3110 - il3945_store_filter_flags() acquires mutex at 3945-mac.c:3144 Add mutex_lock()/mutex_unlock() around the il3945_get_measurement() call in the sysfs store function to fix the missing lock protection. Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Link: https://patch.msgid.link/20260125193005.1090429-1-n7l8m4@u.northwestern.edu Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: iwlegacy: add missing mutex protection in il4965_store_tx_power()Ziyi Guo1-0/+2
[ Upstream commit e31fa691d0b1c07b6094a6cf0cce894192c462b3 ] il4965_store_tx_power() calls il_set_tx_power() without holding il->mutex. However, il_set_tx_power() has lockdep_assert_held(&il->mutex) indicating that callers must hold this lock. All other callers of il_set_tx_power() properly acquire the mutex: - il_bg_scan_completed() acquires mutex at common.c:1683 - il_mac_config() acquires mutex at common.c:5006 - il3945_commit_rxon() and il4965_commit_rxon() are called via work queues that hold the mutex (like il4965_bg_alive_start) Add mutex_lock()/mutex_unlock() around the il_set_tx_power() call in the sysfs store function to fix the missing lock protection. Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Link: https://patch.msgid.link/20260125194039.1196488-1-n7l8m4@u.northwestern.edu Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw89: 8922a: add digital compensation for 2GHzPo-Hao Huang1-10/+47
[ Upstream commit 8da7e88682d58a7c2e2c2101e49d3c9c9ac481b0 ] This fixes transmit power too low under 2GHz connection. Previously we missed the settings of 2GHz, add the according calibrated tables. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260117044157.2392958-10-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw89: fix unable to receive probe responses under MLO connectionPo-Hao Huang1-0/+3
[ Upstream commit 6f6d7a325fbde4f025ee1b1277f6f44727e21223 ] During MLO connections, A1 of the probe responses we received are in link address, these frames will then be dropped by mac80211 due to not matching the MLD address in ieee80211_scan_accept_presp(). Fix this by using MLD address to scan when not using random MAC address. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260114013950.19704-13-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw89: Add default ID 28de:2432 for RTL8832CUShin-Yi Lin1-0/+2
[ Upstream commit 5f65ebf9aaf00c7443252136066138435ec03958 ] Add 28de:2432 for RTL8832CU-based adapters that use this default ID. Signed-off-by: Shin-Yi Lin <isaiah@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260114014906.21829-1-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: iwlwifi: mld: Fix primary link selection logicNidhish A N1-8/+15
[ Upstream commit 7a749db26cab2334d5b356ac31e6f1147c7682da ] When assigning emlsr.primary with emlsr.selected_primary we are checking if BIT(mld_vif->emlsr.selected_links) are a part of vif->active_links. This is incorrect as emlsr.selected_links is a bitmap of possibly two selected links. Therefore, performing the BIT() operation on it does not yield any meaningful result and almost always leads to incorrect primary link selection. Additionally, we cannot rely on vif->active_links at this stage of the link switch flow because it contains both the removed links and also the newly added links. For example, if we had selected links in the past (0x11) and we now select links because of TTLM/debugfs (0x100), vif->active_links will now be (0x111) and primary link will be 0, while 0 is not even an active link. Thus, we create our own bitmap of final active links. Signed-off-by: Nidhish A N <nidhish.a.n@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260111193638.38b2e14e3a20.Ie81a88dfff0c5d2becedabab8398702808f6b1bf@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: iwlwifi: mld: fix chandef start calculationMiri Korenblit1-2/+2
[ Upstream commit d2fcdf36554316cc51f7928b777944738d06e332 ] A link pair in which both links are in 5 GHz can be used for EMLSR only if they are separated enough. To check this condition we calculate the start and the end of the chandefs of both links in the pair and do some checks. But the calculation of the start/end of the chandef is currently done by subtracting/adding half the bandwidth from/to the control channel's center frequency, when it should really be subtracted/added from/to the center frequency of the entire chandef. Fix the wrong calculation. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260111193638.2138fdb99bd5.I4d2e5957b22482a57b1d6ca444e90fcf73bf2cab@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: iwlwifi: fix 22000 series SMEM parsingJohannes Berg1-2/+6
[ Upstream commit 58192b9ce09b0f0f86e2036683bd542130b91a98 ] If the firmware were to report three LMACs (which doesn't exist in hardware) then using "fwrt->smem_cfg.lmac[2]" is an overrun of the array. Reject such and use IWL_FW_CHECK instead of WARN_ON in this function. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20251110150012.16e8c2d70c26.Iadfcc1aedf43c5175b3f0757bea5aa232454f1ac@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: iwlwifi: mvm: check the validity of noa_lenMiri Korenblit1-0/+14
[ Upstream commit 1e3fb3c4a8e6c581d0f4533dba887fabf53d607d ] Validate iwl_probe_resp_data_notif::noa_attr::len_low since we are using its value to determine the noa_len, which is later used for the NoA attribute. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20251110150012.99b663d9b424.I206fd54c990ca9e1160b9b94fa8be44e67bcc1b9@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: iwlwifi: mld: Handle rate selection for NAN interfaceIlan Peer1-0/+5
[ Upstream commit dbbeebece03050cd510073ce89fee83844e06b00 ] Frames transmitted over a NAN interface might not have channel information assigned to them. In such cases assign the lowest OFDM to the frame. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20251110180612.72046f98f878.Ib784931fffd0747acd9d7bb22eabbbec5282733e@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: ath12k: fix mac phy capability parsingBaochen Qiang1-8/+14
[ Upstream commit b5151c9b6e3a347416a4b4b55fc00195526d8771 ] Currently ath12k_pull_mac_phy_cap_svc_ready_ext() assumes only one band supported in each phy, hence it skips 5 GHz band if 2 GHz band support is detected. This does not work for device which gets only one phy but has both bands supported, such as QCC2072. Change to check each band individually to fix this issue. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-6-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: ath12k: fix preferred hardware mode calculationBaochen Qiang1-1/+1
[ Upstream commit 7f852de0003219c431a6f2ffd951fd82a4673660 ] For single pdev device like WCN7850/QCC2072, preferred_hw_mode is initialized to WMI_HOST_HW_MODE_SINGLE. Later when firmware sends supported modes to host, each mode is compared with the initial one and if the priority of the new mode is higher, update the parameter and store mode capability. For WCN7850, this does not result in issue, as one of the supported mode indeed has a higher priority. However the only available mode of QCC2072 at this stage is WMI_HOST_HW_MODE_SINGLE, which fails the comparison, hence mode capability is not stored. Subsequently driver initialization fails. Fix it by accepting a mode with the same priority. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-4-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: ath11k: Fix failure to connect to a 6 GHz APQian Zhang1-3/+6
[ Upstream commit 0bc8c48de6f06c0cac52dde024ffda4433de6234 ] STA fails to connect to a 6 GHz AP with the following errors: ath11k_pci 0000:01:00.0: failed to handle chan list with power type 1 wlp1s0: deauthenticating from c8:a3:e8:dd:41:e3 by local choice (Reason: 3=DEAUTH_LEAVING) ath11k_reg_handle_chan_list() treats the update as redundant and returns -EINVAL. That causes the connection attempt to fail. Avoid unnecessary validation during association. Apply the regulatory redundant check only when the power type is IEEE80211_REG_UNSET_AP, which only occurs during core initialization. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Signed-off-by: Qian Zhang <qian.zhang@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260108034607.812885-1-qian.zhang@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: ath11k: add pm quirk for Thinkpad Z13/Z16 Gen1Ross Vandegrift1-0/+28
[ Upstream commit 4015b1972763d7d513172276e51439f37e622a92 ] Z16 Gen1 has the wakeup-from-suspend issues from [1] but was never added to the appropriate quirk list. I've tested this patch on top of 6.18.2, it fixes the issue for me on 21D4 Mark Pearson provided the other product IDs covering the second Z16 Gen1 and both Z13 Gen1 identifiers. They share the same firmware, and folks in the bugzilla report do indeed see the problem on Z13. [1] - https://bugzilla.kernel.org/show_bug.cgi?id=219196 Signed-off-by: Ross Vandegrift <ross@kallisti.us> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Link: https://patch.msgid.link/wj7o2kmb7g54stdjvxp2hjqrnutnq3jbf4s2uh4ctvmlxdq7tf@nbkj2ebakhrd Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw89: disable EHT protocol by chip capabilitiesPing-Ke Shih4-1/+11
[ Upstream commit 7fd36ffedeedc97c44a10249a3f12d471bb2dc26 ] For certain chip models, EHT protocol is disabled, and driver must follow the capabilities. Otherwise, chips become unusable. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260110022019.2254969-5-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw89: wow: add reason codes for disassociation in WoWLAN modeChin-Yen Lee2-0/+5
[ Upstream commit 2fd8f953f25173d14981d8736b6f5bfcd757e51b ] Some APs disconnect clients by sending a Disassociation frame rather than a Deauthentication frame. Since these frames use different reason codes in WoWLAN mode, this commit adds support for handling Disassociation to prevent missed disconnection events. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260110022019.2254969-3-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw89: mac: correct page number for CSI responsePing-Ke Shih1-1/+1
[ Upstream commit aa2a44d0d22d45d659b9f01638809b1735e46cff ] For beamforming procedure, hardware reserve memory page for CSI response. The unit of register is (value - 1), so add one accordingly as expected. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260110022019.2254969-7-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw89: pci: validate sequence number of TX release reportPing-Ke Shih1-1/+6
[ Upstream commit 957eda596c7665f2966970fd1dcc35fe299b38e8 ] Hardware rarely reports abnormal sequence number in TX release report, which will access out-of-bounds of wd_ring->pages array, causing NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 1085 Comm: irq/129-rtw89_p Tainted: G S U 6.1.145-17510-g2f3369c91536 #1 (HASH:69e8 1) Call Trace: <IRQ> rtw89_pci_release_tx+0x18f/0x300 [rtw89_pci (HASH:4c83 2)] rtw89_pci_napi_poll+0xc2/0x190 [rtw89_pci (HASH:4c83 2)] net_rx_action+0xfc/0x460 net/core/dev.c:6578 net/core/dev.c:6645 net/core/dev.c:6759 handle_softirqs+0xbe/0x290 kernel/softirq.c:601 ? rtw89_pci_interrupt_threadfn+0xc5/0x350 [rtw89_pci (HASH:4c83 2)] __local_bh_enable_ip+0xeb/0x120 kernel/softirq.c:499 kernel/softirq.c:423 </IRQ> <TASK> rtw89_pci_interrupt_threadfn+0xf8/0x350 [rtw89_pci (HASH:4c83 2)] ? irq_thread+0xa7/0x340 kernel/irq/manage.c:0 irq_thread+0x177/0x340 kernel/irq/manage.c:1205 kernel/irq/manage.c:1314 ? thaw_kernel_threads+0xb0/0xb0 kernel/irq/manage.c:1202 ? irq_forced_thread_fn+0x80/0x80 kernel/irq/manage.c:1220 kthread+0xea/0x110 kernel/kthread.c:376 ? synchronize_irq+0x1a0/0x1a0 kernel/irq/manage.c:1287 ? kthread_associate_blkcg+0x80/0x80 kernel/kthread.c:331 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> To prevent crash, validate rpp_info.seq before using. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260110022019.2254969-2-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw89: Add support for D-Link VR Air Bridge (DWA-F18)Zenm Chen1-0/+2
[ Upstream commit 292c0bc8acb687de7e83fc454bb98af19187b6bf ] Add the ID 2001:3323 to the table to support an additional RTL8832AU adapter: D-Link VR Air Bridge (DWA-F18). Compile tested only. Link: https://github.com/morrownr/rtw89/pull/44 Signed-off-by: Zenm Chen <zenmchen@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260112004759.6028-1-zenmchen@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw89: Add support for MSI AX1800 Nano (GUAX18N)Zenm Chen1-0/+2
[ Upstream commit 3116f287b81fe777a00b93ab07ec3c270093b185 ] Add the ID 0db0:f0c8 to the table to support an additional RTL8832BU adapter: MSI AX1800 Nano (GUAX18N). Compile tested only. Link: https://github.com/morrownr/rtl8852bu-20250826/pull/2 Signed-off-by: Zenm Chen <zenmchen@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260112004358.5516-1-zenmchen@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: libertas: fix WARNING in usb_tx_blockSzymon Wilczek1-0/+2
[ Upstream commit d66676e6ca96bf8680f869a9bd6573b26c634622 ] The function usb_tx_block() submits cardp->tx_urb without ensuring that any previous transmission on this URB has completed. If a second call occurs while the URB is still active (e.g. during rapid firmware loading), usb_submit_urb() detects the active state and triggers a warning: 'URB submitted while active'. Fix this by enforcing serialization: call usb_kill_urb() before submitting the new request. This ensures the URB is idle and safe to reuse. Reported-by: syzbot+67969ab6a2551c27f71b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=67969ab6a2551c27f71b Signed-off-by: Szymon Wilczek <swilczek.lx@gmail.com> Link: https://patch.msgid.link/20251221155806.23925-1-swilczek.lx@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw89: fix potential zero beacon interval in beacon trackingKuan-Chung Chen1-6/+8
[ Upstream commit eb57be32f438c57c88d6ce756101c1dfbcc03bba ] During fuzz testing, it was discovered that bss_conf->beacon_int might be zero, which could result in a division by zero error in subsequent calculations. Set a default value of 100 TU if the interval is zero to ensure stability. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251231090647.56407-11-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw89: regd: 6 GHz power type marks default when inactiveZong-Zhe Yang1-0/+1
[ Upstream commit 8c96752d99c0b094af68317a8c701b09bd0862d9 ] When inactive, 6 GHz power type has been assigned to the default one, but missed to mark the local control variable, dflt, true. Then, this might let some 6 GHz power info of disconnected APs keep being taken into account under certain cases. So, mark default when inactive. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251229030926.27004-12-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw88: Fix inadvertent sharing of struct ieee80211_supported_band dataBitterblue Smith1-5/+29
[ Upstream commit fcac0f23d4d20b11014a39f8e2527cdc12ec9c82 ] Internally wiphy writes to individual channels in this structure, so we must not share one static definition of channel list between multiple device instances, because that causes hard to debug breakage. For example, with two rtw88 driven devices in the system, channel information may get incoherent, preventing channel use. Copied from commit 0ae36391c804 ("wifi: rtw89: Fix inadverent sharing of struct ieee80211_supported_band data"). Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/e94ad653-2b6d-4284-a33c-8c694f88955b@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw88: Use devm_kmemdup() in rtw_set_supported_band()Bitterblue Smith1-13/+6
[ Upstream commit 2ba12401cc1f2d970fa2e7d5b15abde3f5abd40d ] Simplify the code by using device managed memory allocations. This also fixes a memory leak in rtw_register_hw(). The supported bands were not freed in the error path. Copied from commit 145df52a8671 ("wifi: rtw89: Convert rtw89_core_set_supported_band to use devm_*"). Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/1aa7fdef-2d5b-4a31-a4e9-fac8257ed30d@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw89: mcc: reset probe counter when receiving beaconChih-Kang Chang2-1/+5
[ Upstream commit 1b40c1c7571fcf926095ed92f25bd87900bdc8ed ] For BE chips, needs to transmit QoS null data periodically to ensure the connection with AP in GC+STA mode. However, in environments with interference, the Qos null data might fail to transmit successfully. Therefore, when receive the beacon from AP will reset the QoS null data failure counter to avoid unnecessary disconnection. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251223030651.480633-13-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw89: setting TBTT AGG number when mac port initializationChih-Kang Chang1-0/+12
[ Upstream commit 5e5f83fba48381098b26a8b2513a6d5fc5c66ccb ] When initializing mac port, needs to set TBTT AGG number to trigger TBTT related interrupts. Otherwise, after sending join info H2C command with disconnection mode, firmware will clear TBTT AGG number. Without the setting from mac port initialization after that, this port will not be able to transmit beacons. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251223030651.480633-12-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw89: ser: enable error IMR after recovering from L1Zong-Zhe Yang4-0/+13
[ Upstream commit f4de946bdb379f543e3a599f8f048d741ad4a58e ] After recovering from L1, explicitly enable error IMR to ensure next L1 SER (system error recovery) can work normally. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251223030651.480633-6-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw89: 8922a: set random mac if efuse contains zeroesJose Ignacio Tornos Martinez1-4/+18
[ Upstream commit 41be33d3efc120f6a2c02d12742655f2aa09e1b6 ] I have some rtl8922ae devices with no permanent mac stored in efuse. It could be properly saved and/or configured from user tools like NetworkManager, but it would be desirable to be able to initialize it somehow to get the device working by default. So, in the same way as with other devices, if the mac address read from efuse contains zeros, a random mac address is assigned to at least allow operation, and the user is warned about this in case any action needs to be considered. Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251126091905.217951-1-jtornosm@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw88: rtw8821cu: Add ID for Mercusys MU6HHsiu-Ming Chang1-0/+2
[ Upstream commit 77653c327e11c71c5363b18a53fbf2b92ed21da4 ] Add support for Mercusys MU6H AC650 High Gain Wireless Dual Band USB Adapter V1.30. It is based on RTL8811CU, usb device ID is 2c4e:0105. Signed-off-by: Hsiu-Ming Chang <cges30901@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251205003245.5762-1-cges30901@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw88: 8822b: Avoid WARNING in rtw8822b_config_trx_mode()Bitterblue Smith1-1/+2
[ Upstream commit 44d1f624bbdd2d60319374ba85f7195a28d00c90 ] rtw8822b_set_antenna() can be called from userspace when the chip is powered off. In that case a WARNING is triggered in rtw8822b_config_trx_mode() because trying to read the RF registers when the chip is powered off returns an unexpected value. Call rtw8822b_config_trx_mode() in rtw8822b_set_antenna() only when the chip is powered on. ------------[ cut here ]------------ write RF mode table fail WARNING: CPU: 0 PID: 7183 at rtw8822b.c:824 rtw8822b_config_trx_mode.constprop.0+0x835/0x840 [rtw88_8822b] CPU: 0 UID: 0 PID: 7183 Comm: iw Tainted: G W OE 6.17.5-arch1-1 #1 PREEMPT(full) 01c39fc421df2af799dd5e9180b572af860b40c1 Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: LENOVO 82KR/LNVNB161216, BIOS HBCN18WW 08/27/2021 RIP: 0010:rtw8822b_config_trx_mode.constprop.0+0x835/0x840 [rtw88_8822b] Call Trace: <TASK> rtw8822b_set_antenna+0x57/0x70 [rtw88_8822b 370206f42e5890d8d5f48eb358b759efa37c422b] rtw_ops_set_antenna+0x50/0x80 [rtw88_core 711c8fb4f686162be4625b1d0b8e8c6a5ac850fb] ieee80211_set_antenna+0x60/0x100 [mac80211 f1845d85d2ecacf3b71867635a050ece90486cf3] nl80211_set_wiphy+0x384/0xe00 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? netdev_run_todo+0x63/0x550 genl_family_rcv_msg_doit+0xfc/0x160 genl_rcv_msg+0x1aa/0x2b0 ? __pfx_nl80211_pre_doit+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? __pfx_nl80211_set_wiphy+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? __pfx_nl80211_post_doit+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x59/0x110 genl_rcv+0x28/0x40 netlink_unicast+0x285/0x3c0 ? __alloc_skb+0xdb/0x1a0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x39f/0x3d0 ? import_iovec+0x2f/0x40 ___sys_sendmsg+0x99/0xe0 ? refill_obj_stock+0x12e/0x240 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x81/0x970 ? do_syscall_64+0x81/0x970 ? ksys_read+0x73/0xf0 ? do_syscall_64+0x81/0x970 ? count_memcg_events+0xc2/0x190 ? handle_mm_fault+0x1d7/0x2d0 ? do_user_addr_fault+0x21a/0x690 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> ---[ end trace 0000000000000000 ]--- Link: https://github.com/lwfinger/rtw88/issues/366 Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/fb9a3444-9319-4aa2-8719-35a6308bf568@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw89: 8852au: add support for TP TX30U PlusJan Gerber1-0/+2
[ Upstream commit a2f1fc9ab6fb0d5c9d701a516c342944258fb20e ] the device shows up like this and everything seams to work: Bus 004 Device 003: ID 3625:010d Realtek 802.11ax WLAN Adapter Signed-off-by: Jan Gerber <j@mailb.org> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251212005515.2059533-1-j@mailb.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: rtw88: fix DTIM period handling when conf->dtim_period is zeroRoman Peshkichev2-3/+3
[ Upstream commit 9f68fdcdc9dbf21be2a48feced90ff7f77d07443 ] The function rtw_set_dtim_period() accepted an 'int' dtim_period parameter, while mac80211 provides dtim_period as 'u8' in struct ieee80211_bss_conf. In IBSS (ad-hoc) mode mac80211 may set dtim_period to 0. The driver unconditionally wrote (dtim_period - 1) to REG_DTIM_COUNTER_ROOT, which resulted in 0xFF when dtim_period was 0. This caused delays in broadcast/multicast traffic processing and issues with ad-hoc operation. Convert the function parameter to u8 to match ieee80211_bss_conf and avoid the underflow by writing 0 when dtim_period is 0. Link: https://github.com/lwfinger/rtw88/issues/406 Signed-off-by: Roman Peshkichev <roman.peshkichev@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251125180937.22977-1-roman.peshkichev@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-27wifi: ath12k: clear stale link mapping of ahvif->links_mapAaradhana Sahu1-1/+3
[ Upstream commit 2c1ba9c2adf0fda96eaaebd8799268a7506a8fc9 ] When an arvif is initialized in non-AP STA mode but MLO connection preparation fails before the arvif is created (arvif->is_created remains false), the error path attempts to delete all links. However, link deletion only executes when arvif->is_created is true. As a result, ahvif retains a stale entry of arvif that is initialized but not created. When a new arvif is initialized with the same link id, this stale mapping triggers the following WARN_ON. WARNING: drivers/net/wireless/ath/ath12k/mac.c:4271 at ath12k_mac_op_change_vif_links+0x140/0x180 [ath12k], CPU#3: wpa_supplicant/275 Call trace: ath12k_mac_op_change_vif_links+0x140/0x180 [ath12k] (P) drv_change_vif_links+0xbc/0x1a4 [mac80211] ieee80211_vif_update_links+0x54c/0x6a0 [mac80211] ieee80211_vif_set_links+0x40/0x70 [mac80211] ieee80211_prep_connection+0x84/0x450 [mac80211] ieee80211_mgd_auth+0x200/0x480 [mac80211] ieee80211_auth+0x14/0x20 [mac80211] cfg80211_mlme_auth+0x90/0xf0 [cfg80211] nl80211_authenticate+0x32c/0x380 [cfg80211] genl_family_rcv_msg_doit+0xc8/0x134 Fix this issue by unassigning the link vif and clearing ahvif->links_map if arvif is only initialized but not created. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1 Fixes: 81e4be30544e ("wifi: ath12k: handle link removal in change_vif_links()") Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260127033400.1721220-1-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-27wifi: ath12k: Fix index decrement when array_len is zeroAaradhana Sahu1-3/+5
[ Upstream commit e4763898bb1325dbb3792961b6d607b5c6452d64 ] Currently, print_array_to_buf_index() decrements index unconditionally. This may lead to invalid buffer access when array_len is zero. Fix this by decrementing index only when array_len is non-zero. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Fixes: adf6df963c03 ("wifi: ath12k: Add support to parse requested stats_type") Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260123071253.2202644-2-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-27wifi: ath11k: add usecase firmware handling based on device compatibleMiaoqing Pan2-0/+31
[ Upstream commit c386a2b1068910538e87ef1cf2fc938ebf7e218f ] For M.2 WLAN chips, there is no suitable DTS node to specify the firmware-name property. In addition, assigning firmware for the M.2 PCIe interface causes chips that do not use usecase specific firmware to fail. Therefore, abandoning the approach of specifying firmware in DTS. As an alternative, propose a static lookup table mapping device compatible to firmware names. Currently, only WCN6855 HW2.1 requires this. However, support for the firmware-name property is retained to keep the ABI backwards compatible. For details on usecase specific firmware, see: https://lore.kernel.org/all/20250522013444.1301330-3-miaoqing.pan@oss.qualcomm.com/. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Fixes: edbbc647c4f3 ("wifi: ath11k: support usercase-specific firmware overrides") Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260121095055.3683957-2-miaoqing.pan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-27wifi: ath10k: sdio: add missing lock protection in ath10k_sdio_fw_crashed_dump()Ziyi Guo1-0/+6
[ Upstream commit e55ac348089e579fc224569c7bd90340bf2439f9 ] ath10k_sdio_fw_crashed_dump() calls ath10k_coredump_new() which requires ar->dump_mutex to be held, as indicated by lockdep_assert_held() in that function. However, the SDIO implementation does not acquire this lock, unlike the PCI and SNOC implementations which properly hold the mutex. Additionally, ar->stats.fw_crash_counter is documented as protected by ar->data_lock in core.h, but the SDIO implementation modifies it without holding this spinlock. Add the missing mutex_lock()/mutex_unlock() around the coredump operations, and add spin_lock_bh()/spin_unlock_bh() around the fw_crash_counter increment, following the pattern used in ath10k_pci_fw_dump_work() and ath10k_snoc_fw_crashed_dump(). Fixes: 3c45f21af84e ("ath10k: sdio: add firmware coredump support") Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260123045822.2221549-1-n7l8m4@u.northwestern.edu Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-27wifi: rtw89: debug: Fix memory leak in __print_txpwr_map()Zilin Guan1-4/+4
[ Upstream commit 6070a44051b1c35714fa130de7726cfe91ca5559 ] In __print_txpwr_map(), memory is allocated to bufp via vzalloc(). If max_valid_addr is 0, the function returns -EOPNOTSUPP immediately without freeing bufp, leading to a memory leak. Since the validation of max_valid_addr does not depend on the allocated memory, fix this by moving the vzalloc() call after the check. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 036042e15770 ("wifi: rtw89: debug: txpwr table supports Wi-Fi 7 chips") Suggested-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Zilin Guan <zilin@seu.edu.cn> Reviewed-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260116130834.1413924-1-zilin@seu.edu.cn Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-27wifi: ath12k: do WoW offloads only on primary linkBaochen Qiang1-0/+16
[ Upstream commit e62102ac9b773bdb08475aa9ca24dea61ae98708 ] In case of multi-link connection, WCN7850 firmware crashes due to WoW offloads enabled on both primary and secondary links. Change to do it only on primary link to fix it. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Fixes: 32f7b19668bd ("wifi: ath12k: support MLO as well if single_chip_mlo_support flag is set") Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20251103-ath12-primary-link-wow-v1-1-3cf523dc09f0@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-27wifi: ath9k: add OF dependency to AHBRosen Penev1-1/+1
[ Upstream commit 125e7b31f041cc0a4ede1e42bef69915f0a63a35 ] The conversion to OF missed adding a Kconfig dependency. Fixes: 2fa490c0d759 ("wifi: ath9k: ahb: replace id_table with of") Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20250802000432.3079550-1-rosenp@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-27wifi: ath9k: fix kernel-doc warnings in common-debug.hRandy Dunlap1-4/+4
[ Upstream commit b9909c19965dc9e5a3a898fef09b437fcc3a9494 ] Modify kernel-doc comments in common-debug.h to avoid warnings: Warning: drivers/net/wireless/ath/ath9k/common-debug.h:21 bad line: may have had errors. Warning: ../drivers/net/wireless/ath/ath9k/common-debug.h:23 bad line: may have had errors. Warning: ../drivers/net/wireless/ath/ath9k/common-debug.h:26 bad line: decryption process completed Warning: ../drivers/net/wireless/ath/ath9k/common-debug.h:28 bad line: encountered an error Fixes: 99c15bf575b1 ("ath9k: Report total tx/rx bytes and packets in debugfs.") Fixes: 1395d3f00a41 ("ath9k: Add debugfs file for RX errors") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20251117020251.447692-1-rdunlap@infradead.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-27wifi: ath9k: debug.h: fix kernel-doc bad lines and struct ath_tx_statsRandy Dunlap1-7/+8
[ Upstream commit c6131765a2c0052b2c5a2310ff92191ff33aec8b ] Repair "bad line" warnings by starting each line with " *". Add or correct kernel-doc entries for missing struct members in struct ath_tx_stats. Warning: ../drivers/net/wireless/ath/ath9k/debug.h:144 bad line: may have had errors. Warning: ../drivers/net/wireless/ath/ath9k/debug.h:146 bad line: may have had errors. Warning: ../drivers/net/wireless/ath/ath9k/debug.h:156 bad line: Valid only for: Warning: ../drivers/net/wireless/ath/ath9k/debug.h:157 bad line: - non-aggregate condition. Warning: ../drivers/net/wireless/ath/ath9k/debug.h:158 bad line: - first packet of aggregate. Warning: drivers/net/wireless/ath/ath9k/debug.h:191 struct member 'xretries' not described in 'ath_tx_stats' Warning: drivers/net/wireless/ath/ath9k/debug.h:191 struct member 'data_underrun' not described in 'ath_tx_stats' Warning: drivers/net/wireless/ath/ath9k/debug.h:191 struct member 'delim_underrun' not described in 'ath_tx_stats' Fixes: 99c15bf575b1 ("ath9k: Report total tx/rx bytes and packets in debugfs.") Fixes: fec247c0d5bf ("ath9k: Add debug counters for TX") Fixes: 5a6f78afdabe ("ath9k: show excessive-retry MPDUs in debugfs") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20251117020304.448687-1-rdunlap@infradead.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-27wifi: rtw89: correct use sequence of driver_data in skb->infoPing-Ke Shih2-2/+6
[ Upstream commit d3a9e132a4c6273a5254e743da14887502e928c8 ] As ieee80211_tx_info is used to assist filling TX descriptor, and layout of IEEE80211_SKB_CB(skb)->driver_data (accessing by RTW89_TX_SKB_CB()) is union, so driver_data must be used by/after rtw89_hci_tx_write() or just before calling rtw89_hci_tx_write(). Otherwise, ieee80211_tx_info::control data is overwritten. Found this by using injected packets which uses ieee80211_tx_info::control, but always sending incorrect data rate. Cc: Fedor Pchelkin <pchelkin@ispras.ru> Fixes: d5da3d9fb05f ("wifi: rtw89: process TX wait skbs for USB via C2H handler") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Fedor Pchelkin <pchelkin@ispras.ru> Link: https://patch.msgid.link/20251217072646.43209-1-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-16wifi: rtl8xxxu: fix slab-out-of-bounds in rtl8xxxu_sta_addAli Tariq1-0/+1
commit 86c946bcc00f6390ef65e9614ae60a9377e454f8 upstream. The driver does not set hw->sta_data_size, which causes mac80211 to allocate insufficient space for driver private station data in __sta_info_alloc(). When rtl8xxxu_sta_add() accesses members of struct rtl8xxxu_sta_info through sta->drv_priv, this results in a slab-out-of-bounds write. KASAN report on RISC-V (VisionFive 2) with RTL8192EU adapter: BUG: KASAN: slab-out-of-bounds in rtl8xxxu_sta_add+0x31c/0x346 Write of size 8 at addr ffffffd6d3e9ae88 by task kworker/u16:0/12 Set hw->sta_data_size to sizeof(struct rtl8xxxu_sta_info) during probe, similar to how hw->vif_data_size is configured. This ensures mac80211 allocates sufficient space for the driver's per-station private data. Tested on StarFive VisionFive 2 v1.2A board. Fixes: eef55f1545c9 ("wifi: rtl8xxxu: support multiple interfaces in {add,remove}_interface()") Cc: stable@vger.kernel.org Signed-off-by: Ali Tariq <alitariq45892@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251225115430.13011-1-alitariq45892@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-04-28 17:17:51 +0300