- 23 Oct, 2023 40 commits
-
-
Stanislaw Gruszka authored
Helmut hasn't been responding to rt2x00 related emails since 2016, remove him from rt2x00 mainterner list. Signed-off-by:
Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231019202651.518136-1-stf_xl@wp.pl
-
Justin Stitt authored
strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. We expect fw_version strings to be NUL-terminated based on other similar assignments: wireless/broadcom/brcm80211/brcmsmac/main.c 7867: snprintf(wlc->wiphy->fw_version, 7868: sizeof(wlc->wiphy->fw_version), "%u.%u", rev, patch); wireless/broadcom/b43legacy/main.c 1765: snprintf(wiphy->fw_version, sizeof(wiphy->fw_version), "%u.%u", wireless/broadcom/b43/main.c 2730: snprintf(wiphy->fw_version, sizeof(wiphy->fw_version), "%u.%u", wireless/intel/iwlwifi/dvm/main.c 1465: snprintf(priv->hw->wiphy->fw_version, 1466: sizeof(priv->hw->wiphy->fw_version), wireless/intel/ipw2x00/ipw2100.c 5905: snprintf(info->fw_version, sizeof(info->fw_version), "%s:%d:%s", Based on this, NUL-padding is not required. A suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by:
Justin Stitt <justinstitt@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Justin Stitt authored
strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. We expect wl->chip.fw_ver_str to be NUL-terminated based on its usage with DRIVER_STATE_PRINT_STR() in debugfs.c: 491 | DRIVER_STATE_PRINT_STR(chip.fw_ver_str); ... which uses DRIVER_STATE_PRINT(): 444 | #define DRIVER_STATE_PRINT_STR(x) DRIVER_STATE_PRINT(x, "%s") ... which relies on scnprintf: 434 | #define DRIVER_STATE_PRINT(x, fmt) \ 435 | (res += scnprintf(buf + res, DRIVER_STATE_BUF_LEN - res,\ 436 | #x " = " fmt "\n", wl->x)) Moreover, NUL-padding is not required. Considering the above, a suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Similar-to: https://lore.kernel.org/all/20231018-strncpy-drivers-net-wireless-ti-wl18xx-main-c-v2-1-ab828a491ce5@google.com/Signed-off-by:
-
Justin Stitt authored
strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. wl->chip.phy_fw_ver_str is obviously intended to be NUL-terminated by the deliberate comment telling us as much. Furthermore, its only use is drivers/net/wireless/ti/wlcore/debugfs.c shows us it should be NUL-terminated since its used in scnprintf: 492 | DRIVER_STATE_PRINT_STR(chip.phy_fw_ver_str); which is defined as: | #define DRIVER_STATE_PRINT_STR(x) DRIVER_STATE_PRINT(x, "%s") ... | #define DRIVER_STATE_PRINT(x, fmt) \ | (res += scnprintf(buf + res, DRIVER_STATE_BUF_LEN - res,\ | #x " = " fmt "\n", wl->x)) We can also see that NUL-padding is not required. Considering the above, a suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. The very fact that a plain-english comment had to be made alongside a manual NUL-byte assignment for such a simple purpose shows why strncpy is faulty. It has non-obvious behavior that has to be clarified every time it is used (and if it isn't then the reader suffers). Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by:
-
Justin Stitt authored
strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. Based on other assignments of similar fw_version fields we can see that NUL-termination is required but not NUL-padding: ethernet/intel/ixgbe/ixgbe_ethtool.c 1111: strscpy(drvinfo->fw_version, adapter->eeprom_id, 1112: sizeof(drvinfo->fw_version)); ethernet/intel/igc/igc_ethtool.c 147: scnprintf(adapter->fw_version, 148: sizeof(adapter->fw_version), 153: strscpy(drvinfo->fw_version, adapter->fw_version, 154: sizeof(drvinfo->fw_version)); wireless/broadcom/brcm80211/brcmfmac/core.c 569: strscpy(info->fw_version, drvr->fwver, sizeof(info->fw_version)); wireless/broadcom/brcm80211/brcmsmac/main.c 7867: snprintf(wlc->wiphy->fw_version, 7868: sizeof(wlc->wiphy->fw_version), "%u.%u", rev, patch); wireless/broadcom/b43legacy/main.c 1765: snprintf(wiphy->fw_version, sizeof(wiphy->fw_version), "%u.%u", wireless/broadcom/b43/main.c 2730: snprintf(wiphy->fw_version, sizeof(wiphy->fw_version), "%u.%u", wireless/intel/iwlwifi/dvm/main.c 1465: snprintf(priv->hw->wiphy->fw_version, 1466: sizeof(priv->hw->wiphy->fw_version), wireless/intel/ipw2x00/ipw2100.c 5905: snprintf(info->fw_version, sizeof(info->fw_version), "%s:%d:%s", A suitable replacement is `strscpy` due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by:
-
Ming Yen Hsieh authored
When the chip not support 6GHz capability, the channels of 6GHz information should not be updated. This caused a crash: [ 19.442078] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000014 [ 19.457535] Mem abort info: [ 19.465329] ESR = 0x0000000096000004 [ 19.473295] EC = 0x25: DABT (current EL), IL = 32 bits [ 19.482354] SET = 0, FnV = 0 [ 19.489143] EA = 0, S1PTW = 0 [ 19.495991] FSC = 0x04: level 0 translation fault [ 19.504554] Data abort info: [ 19.511111] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 19.520269] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 19.528988] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 19.537960] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001027a9000 [ 19.548014] [0000000000000014] pgd=0000000000000000, p4d=000000000000 [ 19.558429] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 19.568270] Modules linked in: mt7921e mt7921_common mt792x_lib mt76_connac_lib mt76 mac80211 btusb btintel cfg80211 btmtk snd_sof_ipc_msg_ btrtl snd_sof_ipc_flood_test btbcm bluetooth snd_sof_mt8195 uvcvideo mtk_adsp_common snd_sof_xtensa_dsp uvc snd_sof_of snd_sof videobuf2_vmalloc ecdh_generic ecc snd_sof_utils cros_ec_lid_angle cros_ec_sensors crct10dif_ cros_ec_sensors_core cros_usbpd_logger crypto_user fuse ip_tables ipv6 [ 19.614237] CPU: 1 PID: 105 Comm: kworker/1:1 Not tainted 6.6.0-rc6-next-20231017+ #324 [ 19.625957] Hardware name: Acer Tomato (rev2) board (DT) [ 19.634970] Workqueue: events mt7921_init_work [mt7921_common] [ 19.644522] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTY [ 19.655182] pc : mt7921_regd_notifier+0x180/0x290 [mt7921_common] [ 19.664983] lr : mt7921_regd_notifier+0xd4/0x290 [mt7921_common] [ 19.674679] sp : ffff800080acba80 [ 19.681649] x29: ffff800080acba80 x28: 0000000000000000 x27: ffff4faf [ 19.692483] x26: 0000000000000000 x25: 0000000000000000 x24: ffff4faf [ 19.703294] x23: 00000000ffffe926 x22: ffff4faf16031fa0 x21: 00000000 [ 19.714108] x20: 000000000000001c x19: ffff4faf16ba6f40 x18: 00000000 [ 19.724928] x17: 0000000000000000 x16: ffffac6b891c2750 x15: ffff8000 [ 19.735722] x14: 0000000000000180 x13: 0000000000000000 x12: 00000000 [ 19.746478] x11: 0000000000000002 x10: ffff4faf01c21780 x9 : ffffac6b [ 19.757214] x8 : 00000000006c0000 x7 : ffffac6b6b020cf0 x6 : ffffac6b [ 19.767945] x5 : ffffac6b6b020d00 x4 : ffffac6b6b020cf8 x3 : ffff4faf [ 19.778648] x2 : 0000000000000000 x1 : 000000000000001c x0 : 00000000 [ 19.789366] Call trace: [ 19.795381] mt7921_regd_notifier+0x180/0x290 [mt7921_common] [ 19.804675] wiphy_update_regulatory+0x2bc/0xa08 [cfg80211] [ 19.813864] wiphy_regulatory_register+0x4c/0x88 [cfg80211] [ 19.823029] wiphy_register+0x75c/0x8d0 [cfg80211] [ 19.831446] ieee80211_register_hw+0x70c/0xc10 [mac80211] [ 19.840479] mt76_register_device+0x168/0x2e8 [mt76] [ 19.849008] mt7921_init_work+0xdc/0x250 [mt7921_common] [ 19.857817] process_one_work+0x148/0x3c0 [ 19.865292] worker_thread+0x32c/0x450 [ 19.872489] kthread+0x11c/0x128 [ 19.879173] ret_from_fork+0x10/0x20 [ 19.886153] Code: f0000041 9100a021 94000aef aa0003f9 (b9401780) [ 19.895634] ---[ end trace 0000000000000000 ]--- Reported-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Closes: https://lore.kernel.org/all/927e7d50-826d-4c92-9931-3c59b18c6945@collabora.com/ Fixes: 09382d8f ("wifi: mt76: mt7921: update the channel usage when the regd domain changed") Signed-off-by:
Ming Yen Hsieh <mingyen.hsieh@mediatek.com> Signed-off-by:
Deren Wu <deren.wu@mediatek.com> Tested-by:
-
Justin Stitt authored
strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. `extra` is intended to be NUL-terminated which is evident by the manual assignment of a NUL-byte as well as its immediate usage with strlen(). Moreover, many of these getters and setters are NUL-padding buffers with memset(): 2439 | memset(&tx_power, 0, sizeof(tx_power)); 9998 | memset(sys_config, 0, sizeof(struct ipw_sys_config)); 10084 | memset(tfd, 0, sizeof(*tfd)); 10261 | memset(&dummystats, 0, sizeof(dummystats)); ... let's maintain this behavior and NUL-pad our destination buffer. Considering the above, a suitable replacement is `strscpy_pad` due to the fact that it guarantees both NUL-termination and NUL-padding on the destination buffer. To be clear, there is no bug in the current implementation as MAX_WX_STRING is much larger than the size of the string literals being copied from. Also, strncpy() does NUL-pad the destination buffer and using strscpy_pad() simply matches that behavior. All in all, there should be no functional change but we are one step closer to eliminating usage of strncpy(). Do note that we cannot use the more idiomatic strscpy invocation of (dest, src, sizeof(dest)) as the destination buffer cannot have its size determined at compile time. So, let's stick with (dest, src, LEN). Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by:
-
Shiji Yang authored
The watchdog function is broken on rt2800 series SoCs. This patch fixes the incorrect watchdog logic to make it work again. 1. Update current wdt queue index if it's not equal to the previous index. Watchdog compares the current and previous queue index to judge if the queue hung. 2. Make sure hung_{rx,tx} 'true' status won't be override by the normal queue. Any queue hangs should trigger a reset action. 3. Clear the watchdog counter of all queues before resetting the hardware. This change may help to avoid the reset loop. 4. Change hang check function return type to bool as we only need to return two status, yes or no. Signed-off-by:Shiji Yang <yangshiji66@outlook.com> Acked-by:
-
Kalle Valo authored
On v6.6-rc4 with GCC 13.2 I see: drivers/net/wireless/ath/ath9k/hif_usb.c:1223:42: warning: '.0.fw' directive output may be truncated writing 5 bytes into a region of size between 4 and 11 [-Wformat-truncation=] drivers/net/wireless/ath/ath9k/hif_usb.c:1222:17: note: 'snprintf' output between 27 and 34 bytes into a destination of size 32 Fix it by increasing the size of the fw_name field to 64 bytes. Compile tested only. Signed-off-by:
-
Kalle Valo authored
On v6.6-rc4 with GCC 13.2 I see: drivers/net/wireless/intel/ipw2x00/ipw2100.c:5905:63: warning: '%s' directive output may be truncated writing up to 63 bytes into a region of size 32 [-Wformat-truncation=] drivers/net/wireless/intel/ipw2x00/ipw2100.c:5905:9: note: 'snprintf' output between 4 and 140 bytes into a destination of size 32 drivers/net/wireless/intel/ipw2x00/ipw2200.c:10392:63: warning: '%s' directive output may be truncated writing up to 63 bytes into a region of size 32 [-Wformat-truncation=] drivers/net/wireless/intel/ipw2x00/ipw2200.c:10392:9: note: 'snprintf' output between 4 and 98 bytes into a destination of size 32 Fix this by copying only the firmware version and not providing any extra information via ethtool. This is an ancient driver anyway and most likely removed soon so it doesn't really matter. Compile tested only. Signed-off-by:
-
Kalle Valo authored
On v6.6-rc4 with GCC 13.2 I see: drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:262:52: warning: '%d' directive output may be truncated writing between 1 and 5 bytes into a region of size 4 [-Wformat-truncation=] drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:262:46: note: directive argument in the range [0, 65535] drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:262:46: note: directive argument in the range [0, 65535] drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:262:9: note: 'snprintf' output between 9 and 17 bytes into a destination of size 9 drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:265:55: warning: '%d' directive output may be truncated writing between 1 and 5 bytes into a region of size 4 [-Wformat-truncation=] drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:265:48: note: directive argument in the range [0, 65535] drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:265:48: note: directive argument in the range [0, 65535] drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:265:9: note: 'snprintf' output between 10 and 18 bytes into a destination of size 10 drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:342:50: warning: '/' directive output may be truncated writing 1 byte into a region of size between 0 and 4 [-Wformat-truncation=] drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:342:42: note: directive argument in the range [0, 65535] drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:342:9: note: 'snprintf' output between 10 and 18 bytes into a destination of size 10 Fix these by increasing the buffer sizes to 20 bytes to make sure there's enough space. Compile tested only. Signed-off-by:
-
Johannes Berg authored
To be able to more easily understand the code, drop robust action frames before being associated, even if there's no MFP in the end, as they are Class 3 Frames and shouldn't be transmitted in the first place. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231001125722.b2fd37083371.Ie9f4906e2f6c698989bce6681956ed2f9454f27c@changeidSigned-off-by:
-
Vinayak Yadawad authored
In 4way handshake offload, cfg80211_port_authorized enables driver to indicate successful 4way handshake to cfg80211 layer. Currently this path of port authorization is restricted to interface type NL80211_IFTYPE_STATION and NL80211_IFTYPE_P2P_CLIENT. This patch extends the support for NL80211_IFTYPE_AP and NL80211_IFTYPE_P2P_GO interfaces to authorize peer STA/P2P_CLIENT, whenever authentication is offloaded on the AP/P2P_GO interface. Signed-off-by:
Vinayak Yadawad <vinayak.yadawad@broadcom.com> Link: https://lore.kernel.org/r/dee3b0a2b4f617e932c90bff4504a89389273632.1695721435.git.vinayak.yadawad@broadcom.comSigned-off-by:
-
Dmitry Antipov authored
Since 'tz_device' is an in-place member of 'struct iwl_mvm', it can't be NULL and so relevant check may be dropped. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by:
Dmitry Antipov <dmantipov@yandex.ru> Acked-by:
-
Gregory Greenman authored
Start supporting API version 86 for new devices. Signed-off-by:
-
Daniel Gabay authored
By definition, this DSM func is valid only for HR/JF RF types. Until now firmware ignored this bit (if set) on other than the above types, but in future firmware versions sending this bit will lead to firmware 0x3426 assert. Avoid that by verifying the HW in driver first. Signed-off-by:
Daniel Gabay <daniel.gabay@intel.com> Signed-off-by:
-
Johannes Berg authored
Worst case it's extra (garbage) data, best case we see why things failed ... Seems the trade-off is better if we print it. Signed-off-by:
-
Johannes Berg authored
When the vif is in MLD mode, we'll get a vif links change from non-zero to zero on disassociation, which removes all links in the firmware and adds the 'deflink' the driver/mac80211 has. This causes the firmware to clear some internal state. However, in non-MLD mode, this doesn't happen, and causes some state to be left around in firmware, which can particularly cause trouble with the ref-BSSID in multi-BSSID, leading to an assert later if immediately making a new multi-BSSID connection with a different ref-BSSID. Fix this by removing/re-adding the link in the non-MLD case when the channel is removed from the vif. This way, all of the state will get cleared out, even if we need the deflink, which is more for software architecture purposes than otherwise. Signed-off-by:
-
Johannes Berg authored
If upper layers requested a TX status, then the frames are more important, so trace frames in that case. Signed-off-by:
-
Miri Korenblit authored
If a TX queue has no space for new TX frames, the driver will keep these frames in the overflow queue, and during reclaim flow it will retry to send the frames from that queue. But if the reclaim flow was invoked from TX queue flush, we will also TX these frames, which is wrong as we don't want to TX anything after flush. This might also cause assert 0x125F when removing the queue, saying that the driver removes a non-empty queue Fix this by TXing the overflow queue's frames only if we are not in flush queue flow. Fixes: a4450980 ("iwlwifi: move reclaim flows to the queue file") Signed-off-by:
Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by:
-
Mukesh Sisodiya authored
Driver need to provide details of VLP, AFC AP type supported for the specific MCC to firmware. Driver will read the UATS (UHB AP type support) table from BIOS and sent to firmware using UATS_TABLE_CMD. Add the support for the same in the driver. Signed-off-by:
Mukesh Sisodiya <mukesh.sisodiya@intel.com> Signed-off-by:
-
Miri Korenblit authored
Expand RLC logging to simplify the debug. Signed-off-by:
-
Anjaneyulu authored
Add debgufs handler for fw system statistics command. Signed-off-by:
Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by:
-
Anjaneyulu authored
The new firmware API uses a new command and notification, the command configures in which statistics types driver is interested and the notification is sent periodically. An additional change in the API is that most of the statistics data is accumulated and reported by the firmware per MLO link. Implement new command and notification handlers and adjust to per-link statistics. Signed-off-by:
-
Gregory Greenman authored
In order to get regulatory domain, driver sends MCC_UPDATE_CMD to the FW. One of the parameters in the response is the status which can tell if the regdomain has changed or not. When iwl_mvm_init_mcc() is called during iwl_op_mode_mvm_start(), then sband is still NULL and channel parameters (i.e. chan->flags) cannot be initialized. When, further in the flow, iwl_mvm_update_mcc() is called during iwl_mvm_up(), it first checks if the regdomain has changed and then skips the update if it remains the same. But, since channel parameters weren't initialized yet, the update should be forced in this codepath. Fix that by adding a corresponding parameter to iwl_mvm_init_fw_regd(). Signed-off-by:
-
Yedidya Benshimol authored
During the D3 resume flow, all new rekeys are passed from the FW. Because the FW supports only one IGTK at a time, every IGTK rekey update should be done by removing the last IGTK. The mvmvif holds a pointer to the last IGTK for that reason and thus should be updated when a new IGTK is passed upon resume. Fixes: 04f78e24 ("wifi: iwlwifi: mvm: Add support for IGTK in D3 resume flow") Signed-off-by:
Yedidya Benshimol <yedidya.ben.shimol@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
The firmware / hardware of devices supporting RSS is able to report duplicates and packets that time out inside the reoder buffer. We can now remove all the complex logic that was implemented to keep all the Rx queues more the less synchronized: we used to send a message to all the queues through the firmware to teach the different queues about what is the current SSN every 2048 packets. Now that we rely on the firmware / hardware to detect duplicates, we can completely remove the code that did that in the driver and it has been reported that this code was spuriously dropping legit packets. Suggested-by:
Sultan Alsawaf <sultan@kerneltoast.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
Multi rx queue allows to spread the load of the Rx streams on different CPUs. 9000 series required complex synchronization mechanisms from the driver side since the hardware / firmware is not able to provide information about duplicate packets and timeouts inside the reordering buffer. Users have complained that for newer devices, all those synchronization mechanisms have caused spurious packet drops. Those packet drops disappeared if we simplify the code, but unfortunately, we can't have RSS enabled on 9000 series without this complex code. Remove support for RSS on 9000 so that we can make the code much simpler for newer devices and fix the bugs for them. The down side of this patch is a that all the Rx path will be routed to a single CPU, but this has never been an issue, the modern CPUs are just fast enough to cope with all the traffic. Signed-off-by:
-
Benjamin Berg authored
iwl_mvm_remove_link would return an error if the link could not be removed. However, doing so prevents recovery if a link was not uploaded to the FW in the first place and the link_info was not allocated or fw_link_id is not set. Returning success means that we can still try to continue with adding new links in change_vif_links. Signed-off-by:
Benjamin Berg <benjamin.berg@intel.com> Signed-off-by:
-
Gregory Greenman authored
Check that fw_link_id does not exceed the size of link_id_to_link_conf array. There's no any codepath that can cause that, but it's still safer to verify in case fw_link_id gets corrupted. Signed-off-by:
-
Johannes Berg authored
When we want to synchronize the NAPI, which was added in commit 5af2bb31 ("wifi: iwlwifi: call napi_synchronize() before freeing rx/tx queues"), we also need to make sure we can't actually reschedule the NAPI. Yes, this happens while interrupts are disabled, but interrupts may still be running or pending. Also call iwl_pcie_synchronize_irqs() to ensure we won't reschedule the NAPI. Fixes: 4cf2f590 ("iwlwifi: queue: avoid memory leak in reset flow") Signed-off-by:
-
Daniel Gabay authored
Add the required logic for parsing and dumping this new region. Signed-off-by:
-
Johannes Berg authored
We shouldn't advertise arbitrary checksum flags since we had to remove support for it due to broken hardware. Fixes: ec18e7d4 ("wifi: iwlwifi: mvm: use old checksum for Bz A-step") Signed-off-by:
-
Johannes Berg authored
In new firmware, we don't need this any more and it won't be called any more by mac80211, since powersave handling is all done by firmware. Remove it from the MLD ops. Signed-off-by:
-
Johannes Berg authored
Somehow I managed to put the EHT line in the wrong place and also didn't indent the center_freq label correctly. Fix it. Signed-off-by:
-
Miri Korenblit authored
FW is introducing an API change in which link ID will be used for session protection notif. Add support for it. Signed-off-by:
-
Miri Korenblit authored
FW is introducing an API change in which link ID will be used for session protection cmd. Add support for it. Signed-off-by:
-
Miri Korenblit authored
As session protection API is moving to be per link instead of per mac, move the time events to be per link too. Since there is only one concurrent time event per mac, it feels unnecessary to have the time_event as a member of iwl_mvm_link_info. (That way we will have to iterate over all links each time we want to clear a time event, and also we will need mac80211 to tell us the link id when mgd_tx_complete() is called.) So leave this as a member of iwl_mvm_vif, but add the link id to the time_event structure. The link id in time_event will only be maintained and used for: 1. When SESSION_PROTECTION_CMD is supported (before it, we don't have MLO) 2. For time_events of types SESSION_PROTECT_CONF_ASSOC, SESSION_PROTECT_CONF_P2P_DEVICE_DISCOV, and SESSION_PROTECT_CONF_P2P_GO_NEGOTIATION (not for aux roc/ Hot Spot time_events). For P2P, non-MLO connections, and pre-MLD API, deflink id, meaning 0, will be used Signed-off-by:
-
Johannes Berg authored
Due to overlapping changes and merges, another error path ended up broken. Fix this one as well. Reported-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Kalle Valo authored
make htmldocs warns: Documentation/driver-api/80211/cfg80211:48: ./include/net/cfg80211.h:7290: WARNING: Duplicate C declaration, also defined at cfg80211:7251. Declaration is '.. c:function:: void cfg80211_rx_assoc_resp (struct net_device *dev, struct cfg80211_rx_assoc_resp *data)'. This is because there's a function named cfg80211_rx_assoc_resp() and a struct named cfg80211_rx_assoc_resp, see previous patch for more info. To workaround this rename the struct to cfg80211_rx_assoc_resp_data. The parameter for the function is named 'data' anyway so the naming here is consistent. Compile tested only. Signed-off-by:
Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20231012114229.2931808-3-kvalo@kernel.orgSigned-off-by:
-
