summaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)Author
2025-09-03wifi: mwifiex: add rgpower table loading supportStefan Kerkmann
Marvell/NXP Wi-Fi adapters allow fine-grained adjustment of the transmit power levels and various other internal parameters. This is done by sending command streams to the adapter. One storage format of these command streams are the rgpower tables, which consist of multiple command blocks in the following format: command_block_1 = { XX XX LL LL XX XX .. } command_block_n = { XX XX LL LL XX XX XX .. } XX = raw byte as hex chars LL = total length of the "raw" command block These command blocks are parsed into their binary representation and then send to the adapter. The parsing logic was adapted from NXP's mwifiex driver[1]. The rgpower tables matching the currently set regulatory domain are automatically requested and applied. If not found the existing device tree provided power tables are tried as well. [1]: https://github.com/nxp-imx/mwifiex/blob/7a8beaa1605cb0870dc7ba3312c76df91cb0d6cf/mlan/mlan_cmdevt.c#L812 Signed-off-by: Stefan Kerkmann <s.kerkmann@pengutronix.de> Link: https://patch.msgid.link/20250804-feature-mwifiex-rgpower-table-loading-v1-1-358e70a4d45e@pengutronix.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-03wifi: iwlegacy: Remove unused structs and avoid ↵Gustavo A. R. Silva
-Wflex-array-member-not-at-end warnings Remove unused structures and avoid the following -Wflex-array-member-not-at-end warnings: drivers/net/wireless/intel/iwlegacy/iwl-spectrum.h:68:39: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/intel/iwlegacy/iwl-spectrum.h:60:39: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Link: https://patch.msgid.link/aJl7TxeWgLdEKWhg@kspp Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-03wifi: brcmfmac: avoid assignment in if/else-if conditions in NVRAM load pathDarshan Rathod
The NVRAM selection logic in brcmf_fw_request_nvram_done() used patterns like: if ((data = bcm47xx_nvram_get_contents(&data_len))) free_bcm47xx_nvram = true; else if ((data = brcmf_fw_nvram_from_efi(&data_len))) kfree_nvram = true; This style violates kernel coding style guidelines and triggers checkpatch.pl errors. It also slightly reduces readability. Refactor these cases by separating the assignment and the check, ensuring behavior remains identical while complying with coding standards. Signed-off-by: Darshan Rathod <darshanrathod475@gmail.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20250812123636.2142292-1-darshanrathod475@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-03Merge tag 'ath-current-20250902' of ↵Johannes Berg
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath Jeff Johnson says: ================== ath.git update for v6.17-rc5 Fix a long-standing issue with ath11k dropping group data packets during GTK rekey, and fix an omission in the ath12k multi-link EMLSR support introduced in v6.16. ================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-03wifi: wilc1000: avoid buffer overflow in WID string configurationAjay.Kathat@microchip.com
Fix the following copy overflow warning identified by Smatch checker. drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame() error: '__memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537) This patch introduces size check before accessing the memory buffer. The checks are base on the WID type of received data from the firmware. For WID string configuration, the size limit is determined by individual element size in 'struct wilc_cfg_str_vals' that is maintained in 'len' field of 'struct wilc_cfg_str'. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/linux-wireless/aLFbr9Yu9j_TQTey@stanley.mountain Suggested-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Ajay Singh <ajay.kathat@microchip.com> Link: https://patch.msgid.link/20250829225829.5423-1-ajay.kathat@microchip.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-03wifi: libertas: cap SSID len in lbs_associate()Dan Carpenter
If the ssid_eid[1] length is more that 32 it leads to memory corruption. Fixes: a910e4a94f69 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/2a40f5ec7617144aef412034c12919a4927d90ad.1756456951.git.dan.carpenter@linaro.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-03wifi: cw1200: cap SSID length in cw1200_do_join()Dan Carpenter
If the ssidie[1] length is more that 32 it leads to memory corruption. Fixes: a910e4a94f69 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/e91fb43fcedc4893b604dfb973131661510901a7.1756456951.git.dan.carpenter@linaro.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-02wifi: ath11k: fix group data packet drops during rekeyRameshkumar Sundaram
During GTK rekey, mac80211 issues a clear key (if the old key exists) followed by an install key operation in the same context. This causes ath11k to send two WMI commands in quick succession: one to clear the old key and another to install the new key in the same slot. Under certain conditions—especially under high load or time sensitive scenarios, firmware may process these commands asynchronously in a way that firmware assumes the key is cleared whereas hardware has a valid key. This inconsistency between hardware and firmware leads to group addressed packet drops. Only setting the same key again can restore a valid key in firmware and allow packets to be transmitted. This issue remained latent because the host's clear key commands were not effective in firmware until commit 436a4e886598 ("ath11k: clear the keys properly via DISABLE_KEY"). That commit enabled the host to explicitly clear group keys, which inadvertently exposed the race. To mitigate this, restrict group key clearing across all modes (AP, STA, MESH). During rekey, the new key can simply be set on top of the previous one, avoiding the need for a clear followed by a set. However, in AP mode specifically, permit group key clearing when no stations are associated. This exception supports transitions from secure modes (e.g., WPA2/WPA3) to open mode, during which all associated peers are removed and the group key is cleared as part of the transition. Add a per-BSS station counter to track the presence of stations during set key operations. Also add a reset_group_keys flag to track the key re-installation state and avoid repeated installation of the same key when the number of connected stations transitions to non-zero within a rekey period. Additionally, for AP and Mesh modes, when the first station associates, reinstall the same group key that was last set. This ensures that the firmware recovers from any race that may have occurred during a previous key clear when no stations were associated. This change ensures that key clearing is permitted only when no clients are connected, avoiding packet loss while enabling dynamic security mode transitions. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.9.0.1-02146-QCAHKSWPL_SILICONZ-1 Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Reported-by: Steffen Moser <lists@steffen-moser.de> Closes: https://lore.kernel.org/linux-wireless/c6366409-9928-4dd7-bf7b-ba7fcf20eabf@steffen-moser.de Fixes: 436a4e886598 ("ath11k: clear the keys properly via DISABLE_KEY") Signed-off-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Tested-by: Nicolas Escande <nico.escande@gmail.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250810170018.1124014-1-rameshkumar.sundaram@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-09-02wifi: ath12k: Set EMLSR support flag in MLO flags for EML-capable stationsRamya Gnanasekar
Currently, when updating EMLSR capabilities of a multi-link (ML) station, only the EMLSR parameters (e.g., padding delay, transition delay, and timeout) are sent to firmware. However, firmware also requires the EMLSR support flag to be set in the MLO flags of the peer assoc WMI command to properly handle EML operating mode notification frames. Set the ATH12K_WMI_FLAG_MLO_EMLSR_SUPPORT flag in the peer assoc WMI command when the ML station is EMLSR-capable, so that the firmware can respond to EHT EML action frames from associated stations. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Fixes: 4bcf9525bc49 ("wifi: ath12k: update EMLSR capabilities of ML Station") Signed-off-by: Ramya Gnanasekar <ramya.gnanasekar@oss.qualcomm.com> Signed-off-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250801104920.3326352-1-rameshkumar.sundaram@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-09-01wifi: rtw89: 8852bt: Remove redundant off_reverse variablesLiao Yuanhong
The variable off_reverse and its related code are completely redundant in the function. Remove them to clean the code. Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250828094717.599527-1-liaoyuanhong@vivo.com
2025-09-01wifi: rtw89: use int type to store negative error codesQianfeng Rong
The 'ret' variable stores returns from other functions, which return either zero on success or negative error codes on failure. Storing error codes in u32 (an unsigned type) causes no runtime issues but is stylistically inconsistent and very ugly. Change 'ret' from u32 to int - this has no runtime impact. Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250827150620.550641-1-rongqianfeng@vivo.com
2025-09-01wifi: rtw89: add getting function of DMA channel v1Ping-Ke Shih
The coming RTL8922DE uses new mapping of DMA channel. Add it accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250826085424.28713-1-pkshih@realtek.com
2025-09-01wifi: rtw89: abstract getting function of DMA channelPing-Ke Shih
The mapping function from QSEL (almost equivalent EDCA queue) to PCI DMA channel. Since coming chips change the definition, abstract this function as a chip_ops. Don't change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250826085339.28512-1-pkshih@realtek.com
2025-09-01wifi: rtw89: pci: add RPP parser v1Ping-Ke Shih
The new format contains more information including TX DMA channel, actual TX link and etc. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250826085332.28463-1-pkshih@realtek.com
2025-09-01wifi: rtw89: pci: abstract RPP parserPing-Ke Shih
RPP is short for release report of payload, which carries information assisting TX completion. Since coming chips change the format, abstract the parser ahead. Don't change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250826085324.28414-1-pkshih@realtek.com
2025-09-01wifi: rtw89: pci: add group BD address designPing-Ke Shih
The newly designed group BD address is to use the same starting DMA address with offset as below picture: Original DMA memory Group BD address +--------+ (*1) +---------+ (*2) +--------+ | CH 0 -|-------> | | <-------|- CH 0 | <-+--+--+--+ +--------+ | | | | | | | | | CH 1 -|-------> | | | CH 1 -|---+ | | | +--------+ | | | | | | | | CH 2 -|-------> | | | CH 2 -|------+ | | +--------+ | | | | | | | CH 3 -|-------> | | | CH 3 -|---------+ | +--------+ | | | | | | : -|-------> | | | : -|------------+ +--------+ | | +--------+ (*3; offset from CH 0) | CH 8 -|-------> | | <-------|- CH 8 | <-+ +--------+ | | | | | (offset from CH 8) | : -|-------> | | | : -|---+ +--------+ +---------+ +--------+ Compare (*1) and (*2), for original design, each DMA channel has individual DMA address, so it is not necessary to allocate continual DMA address across channels. For group BD address, only two DMA address are set, and each channel set the offset (*3) from base address. The element number and offset of a channel are encoded rather than a raw number, so add a function to translate numbers into hardware format. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250826085318.28361-1-pkshih@realtek.com
2025-09-01wifi: rtw89: pci: define TX/RX buffer descriptor poolPing-Ke Shih
Buffer descriptor (BD) is a helper of DMA for each ring. The new hardware design expects a continual memory across all rings, so allocate a pool and assign to each ring rather than allocate a buffer for a ring individually. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250826085258.28308-1-pkshih@realtek.com
2025-09-01wifi: rtw89: pci: add struct rtw89_{tx,rx}_rings to put related fieldsPing-Ke Shih
The new hardware design will expect a continual memory region across all rings, so a new field will be added to describe the region. To help the changes, add struct and make changes ahead. Don't change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250826085152.28164-5-pkshih@realtek.com
2025-09-01wifi: rtw89: pci: use RDU status of R_BE_PCIE_DMA_IMR_0_V1 instead for 8922DEPing-Ke Shih
The original RDU status of R_BE_HAXI_HIMR00 needs additional IO to get the status. The new WiFi 7 8922DE add the status to R_BE_PCIE_DMA_IMR_0_V1 which is read already, so we can reduce one reading IO. After the changes, interrupt behavior of RTL8922DE in low power mode is the same as normal mode, so remove the configuration function for low power mode. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250826085152.28164-4-pkshih@realtek.com
2025-09-01wifi: rtw89: pci: prepare interrupt related registers and functions for 8922DEPing-Ke Shih
The 8922DE is very similar to 8922AE except to RDU (RX desc unavailable) registers. The following patch will adjust to read this status from another register to reduce one reading IO, so create a set of functions ahead. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250826085152.28164-3-pkshih@realtek.com
2025-09-01wifi: rtw89: pci: move chip ISR definition out from chip generationPing-Ke Shih
The existing WiFi 6 chips can share the same ISR (interrupt status registers), but the coming WiFi 7 chip 8922DE can't share the same definition with existing WiFi 7 chip, so move the definition to an individual struct. Don't change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250826085152.28164-2-pkshih@realtek.com
2025-09-01wifi: rtl8xxxu: Remove TL-WN722N V2 (0x2357: 0x010c) from untested devicesAleksej Smirnov
This Wi-Fi dongle has been used for many years now and have had no problems with it. The device is quite old and known, dumping its efuse to the log and asking the user to send the results to Jes.Sorensen@gmail.com on every boot makes little sense. Signed-off-by: Aleksej Smirnov <debugger94@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/CAAN7eZ7QKEeQgNHEBuZKy4Gqg3oqpGi6BUdOVBOxPN7dedhVJQ@mail.gmail.com
2025-08-31wifi: iwlwifi: don't support WH a stepMiri Korenblit
This is no longer supported. Fail the probe if such an HW is detected. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250828111032.8d484f21a237.I16a30af0b4b964339bd60c3bed854d1028c1fff8@changeid
2025-08-31wifi: iwlwifi: mld: remove a TODOMiri Korenblit
This was already done. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250828111032.c445b2fc8bce.Ic616d605a4d6f82122466f50022cd046d229de4e@changeid
2025-08-31wifi: iwlwifi: carefully select the PNVM sourceMiri Korenblit
For newer device, and from API 100 (core 97), the PNVM should be taken from the .ucode file, and not from an external .pnvm file. In the current logic, if the PNVM doesn't exist in the .ucode file, we fallback to fetching the .ucode file. This is wrong and hides bugs. This fallback was needed for (a) old devices and (b) for newer devices with an old API. Since we no longer support those old APIs, (b) is not longer relevant. We can, according to the device, select the right PNVM source and fail if we couldn't find the PNVM there. Add clear logic to select the expected PNVM source, and print an error if we couldn't get the PNVM from there. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Daniel Gabay <daniel.gabay@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250828111032.7e75d33e3c28.I87fbcd25bbee733d2612206b76c2d8593d0cbd39@changeid
2025-08-31wifi: iwlwifi: mld: make iwl_mld_rm_vif voidMiri Korenblit
Unlike adding/allocating an object, destroying it should always succeed. In addition, the return value of iwl_mld_rm_vif is not even used. Make it a void function. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250828111032.418e898e908d.I18cc8d6b55a4e468dd155a40089ebea7de70594c@changeid
2025-08-31wifi: iwlwifi: pcie: remember when interrupts are disabledMiri Korenblit
trans_pcie::fh_mask and hw_mask indicates what are the interrupts are currently enabled (unmasked). When we disable all interrupts, those should be set to 0, so if, for some reason, we get an interrupt even though it was disabled, we will know to ignore. Reviewed-by: Yedidya Ben Shimol <yedidya.ben.shimol@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250828111032.e293d6a8385b.I919375e5ad7bd7e4fee4a95ce6ce6978653d6b16@changeid
2025-08-31wifi: iwlwifi: mld: support TLC command version 5Miri Korenblit
A new version of the TLC command was added in order to support the new MCSs intoduced in UHR, and an indication of ELR support. To support the new MCSs, the new version will have MCS bitmaps (ht_rates) of 32 bit and not 16 bit, as in the old version. Change the code to populate the new version of the command, and if the FW requires the old version, copy the content of the new version structure to the old version structure. Note that this doesn't actually set the new MCSs, this will come later. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250828111032.032a450cc279.Iecf6570c9fe11d8fbdc0718341ac92506b02d78c@changeid
2025-08-31wifi: iwlwifi: gen1_2: move gen specific code to a functionMiri Korenblit
The remove function will be called also for gen3 devices, so move out the gen1_2 code to a function that will be called only for gen1/2 devices. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250828111032.a584254bcf83.I69d176b94d23f0f34d28733c48964f277a0a67a1@changeid
2025-08-31wifi: iwlwifi: gen1_2: rename iwl_trans_pcie_op_mode_enterMiri Korenblit
As a new version of this will be added for gen3, rename to iwl_pcie_gen1_2_op_mode_enter to distinguish between the different versions. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250828111032.64b3f290c397.I3ae2ca53330a8543bcbac32880824683f919ac74@changeid
2025-08-31wifi: iwlwifi: really remove hw_wfpm_idMiri Korenblit
This was meant to be removed, but seems it was re-added to the info structure eventually. Anyway, it is not set or used so remove it. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250828111032.78e84f722963.I1bc574a315cd5a587439974ee250887954589321@changeid
2025-08-31wifi: iwlwifi: remove unneeded jacket indicationMiri Korenblit
This is only needed for internal builds. Don't read it. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250828111032.13a01468449c.Iab8255539567a82f0b9e0d1b269fababa2e72e61@changeid
2025-08-31wifi: iwlwifi: don't publish TWT capabilitiesMiri Korenblit
Due to the echosystem readiness this is not supported for now. Don't publish the capability. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250828082601.537908-2-miriam.rachel.korenblit@intel.com
2025-08-31wifi: iwlwifi: trans: move dev_cmd_pool to trans specificMiri Korenblit
This pool has different parameters for different devices, move it to the generation specific transport sub-layer. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250828111032.faf685de7aa2.I83e31e36d3159aa5c7e6f82a773d9981d3aac70d@changeid
2025-08-31wifi: iwlwifi: remove .pnvm files from module infoMiri Korenblit
For BZ/GF and SC/GF, we no longer have a .pnvm file, don't declare those Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250828111032.74f7fdba4ff6.Ia5e2123471df1fdc3688d8687a8e437388412206@changeid
2025-08-31wifi: iwlwifi: acpi: make iwl_guid staticJohannes Berg
This variable is now only used in the same file, so there's no need to expose it. Make it static. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250828111032.83ec118cd1fb.I50c8e86fb786488f97e1ff2e115c4166c6b9bee1@changeid
2025-08-31wifi: iwlwifi: uefi: remove runtime check of constant valuesJohannes Berg
There's no need to check an ARRAY_SIZE() at runtime, it's already determined at build time, so could be a BUILD_BUG_ON. However it's not that useful here since the array is defined using UEFI_MAX_DSM_FUNCS, check DSM_FUNC_NUM_FUNCS instead to ensure the array cannot be accessed out-of-band, i.e. ensure the range check there is always good enough. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250828111032.cc3c17327ea2.I99c7175be1f72f29b154454fc24978daafad476f@changeid
2025-08-28Merge tag 'iwlwifi-fixes-2025-08-28' of ↵Johannes Berg
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Miri Korenblit says: ==================== a few fixes, mainly of the cfg rework. ==================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-08-28wifi: iwlwifi: cfg: add back more lost PCI IDsJohannes Berg
Add back a few more PCI IDs to the config match table that evidently I lost during the cleanups. Fixes: 1fb053d9876f ("wifi: iwlwifi: cfg: remove unnecessary configs") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250828095500.46fee422651e.I8f6c3e9eea9523bb1658f5690b715eb443740e07@changeid
2025-08-28wifi: iwlwifi: fix byte count table for old devicesJohannes Berg
For devices handled by iwldvm, bc_table_dword was never set, but I missed that during the removal thereof. Change the logic to not treat the byte count table as dwords for devices older than 9000 series to fix that. Fixes: 6570ea227826 ("wifi: iwlwifi: remove bc_table_dword transport config") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250828095500.eccd7d3939f1.Ibaffa06d0b3aa5f35a9451d94af34de208b8a2bc@changeid
2025-08-28wifi: iwlwifi: cfg: restore some 1000 series configsJohannes Berg
In the fixed commit, I inadvertently removed two configurations while combining the 0x0083/0x0084 device IDs. Replace the fixed matches for the BG versions by a masked match and add the BGN version back with a similar masked match. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220477 Fixes: 1fb053d9876f ("wifi: iwlwifi: cfg: remove unnecessary configs") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20250828095500.fabb99c2df9e.If0ad87bf9ab360da5f613e879fd416c17c544733@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2025-08-28Merge tag 'mt76-fixes-2025-08-27' of https://github.com/nbd168/wirelessJohannes Berg
Felix Fietkay says: =================== mt76 fixes for 6.17 - fix regressions from mt7996 MLO support rework - fix offchannel handling issues on mt7996 - mt792x fixes - fix multiple wcid linked list corruption issues =================== Change-Id: Ib3e9a3217a40b9da69e122514d47fa46699c864b Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-08-28wifi: mwifiex: Initialize the chan_stats array to zeroQianfeng Rong
The adapter->chan_stats[] array is initialized in mwifiex_init_channel_scan_gap() with vmalloc(), which doesn't zero out memory. The array is filled in mwifiex_update_chan_statistics() and then the user can query the data in mwifiex_cfg80211_dump_survey(). There are two potential issues here. What if the user calls mwifiex_cfg80211_dump_survey() before the data has been filled in. Also the mwifiex_update_chan_statistics() function doesn't necessarily initialize the whole array. Since the array was not initialized at the start that could result in an information leak. Also this array is pretty small. It's a maximum of 900 bytes so it's more appropriate to use kcalloc() instead vmalloc(). Cc: stable@vger.kernel.org Fixes: bf35443314ac ("mwifiex: channel statistics support for mwifiex") Suggested-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/20250815023055.477719-1-rongqianfeng@vivo.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-08-28wifi: iwlwifi: uefi: check DSM item validityJohannes Berg
The first array index is a bitmap indicating which of the other values are valid. Check that bitmap before returning a value. Fixes: fc7214c3c986 ("wifi: iwlwifi: read DSM functions from UEFI") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220085 Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250828095500.59ec52ff865e.I9e11f497a029eb38f481b2c90c43c0935285216d@changeid
2025-08-28wifi: iwlwifi: acpi: check DSM func validityJohannes Berg
The DSM func 0 (DSM_FUNC_QUERY) returns a bitmap of which other functions contain valid data, query and check it before returning other functions data. Fixes: 9db93491f29e ("iwlwifi: acpi: support device specific method (DSM)") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220085 Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250828095500.881e17ff8f6a.Ic6d92997d9d5fad127919d6e1b830cd3fe944468@changeid
2025-08-28wifi: iwlwifi: if scratch is ~0U, consider it a failureEmmanuel Grumbach
We want to see bits being set in the scratch register upon resume, but if all the bits are set, it means that we were kicked out of the PCI bus and that clearly doesn't mean we can assume the firmware is still alive after the suspend / resume cycle. Fixes: cb347bd29d0d ("wifi: iwlwifi: mvm: fix hibernation") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250828095500.0f203e559242.I59eff718cb5fda575db41081a1a389f7af488717@changeid
2025-08-28wifi: iwlwifi: refactor iwl_pnvm_get_from_fsMiri Korenblit
Instead of having an error code or 0 as a return value and passing a pointer to a pointer to be set by this function, change it to return a pointer, and use NULL as an error indication. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250826184046.c752988eb0d1.I7b3a9a4f6a8d23663838a1e232f8bfad57c596ce@changeid
2025-08-28wifi: iwlwifi: iwl-config: include module.hJohannes Berg
This file declares a macro using MODULE_FIRMWARE, so it should include module.h to always guarantee it being available. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250826184046.82a9e8f37c37.I5f4b310784bd49273ac905a79e8e3e0f39e15107@changeid
2025-08-28wifi: iwlwifi: mld: don't modify trans state where not neededMiri Korenblit
In suspend and resume flows, if we had any error we set the transport state to 'FW_ERROR' This was done to avoid sending commands when we shouldn't. In the mentioned flows, we can have a few types of errors: 1. logic errors 2. FW is in error state (can't send commands) 3. FW is misbehaving 4. D3 handshake error In the first, we can still talk to the firmware. In the second - the transport already knows about the FW error, no need to tell it. In the third - we need to treat it as any other FW misbehaviour. There is no reason to have a special handling here. So we only need it for the last type. Change the code to set the tansport state to FW error only in case of a d3 handshake error. While at it, add a comment explaining why the opmode sets the FW error bits. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250826184046.44c74ac0eb2a.Ic7369e622d908684f9b25ffc293d14c167c26414@changeid
2025-08-28wifi: iwlwifi: simplify iwl_trans_pcie_d3_resumeMiri Korenblit
If iwl_trans_d3_resume succeeded but the hw requested a reset, this will be indicated to the opmode via the iwl_d3_status parameter while the return value will be 0. But the opmode doesn't really care if the resume failed or if a restart is required. It acts the same in both cases (beside different logs, but this can be done in iwl_trans_pcie_d3_resume) This complicates the code for no good reason. Change the iwl_trans_pcie_d3_resume to return an error value also in the case that everything went successfully but a restart is required, and add more logs so we can differentiate between the cases. This makes iwl_d3_status redundant. Remove it as well. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250826184046.5fa2d909c75d.Ida19d8d8d73eddf12b30f1d473ea675f415778b2@changeid
generated by cgit v1.2.3 (git 2.0.4) at 2026-02-19 09:35:50 +0000