aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)AuthorFilesLines
2024-02-21wifi: iwlwifi: load b0 version of ucode for HR1/HR2Mukesh Sisodiya1-1/+2
load b0 version of ucode for both a0 and b0 step of HR RF. Signed-off-by: Mukesh Sisodiya <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240218194912.0166f5d2d5d2.I34c1d46aefd70b34c1c75cea67792bc5ec8bc285@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-02-21wifi: iwlwifi: handle per-phy statistics from fwMiri Korenblit2-1/+17
In the operational statistics notifications (both old and new API) the driver receives the statistics per phy. currently this statistics wasn't handled because they wasn't needed. Now the channel_load_by_us parameter in these statistics will be used for the link grading calculation (implemented in another patch), so store its value in phy_ctxt. Signed-off-by: Miri Korenblit <[email protected]> Reviewed-by: Johannes Berg <[email protected]> Link: https://msgid.link/20240218194912.e84f975b69ee.Ibbc7817135827e45adaaa47b796be165f9f1ca48@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-02-21wifi: iwlwifi: iwl-fh.h: fix kernel-doc issuesJohannes Berg1-16/+20
Clean up kernel-doc in iwl-fh.h. In one case, rename the (otherwise unused) struct member to have the correct name. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240218194912.4a342ac06f0b.I604ea964a094b43df0ab29b06231c2f42d6bd79b@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-02-21wifi: iwlwifi: api: fix kernel-doc referenceJohannes Berg1-2/+2
This is for iwl_tas_config_cmd_v4, not iwl_tas_config_cmd_v3. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240218194912.5475d49bce86.I640a12bc799612e82c3e7a4d628bbb7760511297@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-02-21wifi: iwlwifi: mvm: unlock mvm if there is no primary linkBenjamin Berg1-2/+4
At that point in the code mvm->mutex has already been taken, so jump to out_noreset in order to unlock before returning the error. Fixes: 8c9bef26e98b ("wifi: iwlwifi: mvm: d3: implement suspend with MLO") Signed-off-by: Benjamin Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240218194912.21de6e68d9e5.I3c0ebe577dec6b26ab6b4eac48035d6f35a8b0f8@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-02-21wifi: iwlwifi: bump FW API to 90 for BZ/SC devicesMiri Korenblit2-2/+2
Start supporting API version 90 for new devices. Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240218194912.21cf0b641f12.I2f9196191f1ea78e96e92f9db8ecb3cc9bbfd9b3@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-02-21wifi: iwlwifi: mvm: support PHY context version 6Johannes Berg2-2/+6
Fill the new puncture mask in the PHY context command if supported. In this case, also don't send it in the link context command. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240218194912.16d9f5fc41df.I9eeb55787d8483f820f5790e8874761f598da314@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-02-21wifi: iwlwifi: mvm: partially support PHY context version 6Johannes Berg3-13/+12
The version 6 command adds the puncture mask to the PHY context and is otherwise the same. Support that in the API definitions, but don't fill it yet. While at it, also mark the field as removed from the link context command since it moved from there to PHY context. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240218194912.2156fca5b1a5.I57f47f26ec0d96ecfb1192039f72b1c6d4e8a357@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-02-21wifi: iwlwifi: mvm: support wider-bandwidth OFDMAJohannes Berg6-12/+30
To support wider-bandwidth OFDMA we need to configure the PHY context in the firmware, which will in turn configure the DSP accordingly. Pass the relevant information down. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240218194912.ca666ede5dd6.I357972823d20e9045e2c97dbb7ac24fe9f5a6e41@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-02-21wifi: mac80211_hwsim: add support for switch_vif_chanctx callbackAditya Kumar Singh1-1/+43
Currently switch_vif_chanctx mac80211 callback is not supported for MLO. Add it. Signed-off-by: Aditya Kumar Singh <[email protected]> Link: https://msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2024-02-21wifi: mac80211: check beacon countdown is complete on per link basisAditya Kumar Singh10-11/+11
Currently, function to check if beacon countdown is complete uses deflink to fetch the beacon and check the counter. However, with MLO, there is a need to check the counter for the beacon in a particular link. Add support to use link_id in order to fetch the beacon from a particular link data. Signed-off-by: Aditya Kumar Singh <[email protected]> Link: https://msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2024-02-21wifi: iwlwifi: mvm: fix the TXF mapping for BZ devicesEmmanuel Grumbach3-3/+28
Those devices' fifos are numbered differently. Because of that, we were looking at the size of the VO fifo size to determine the size of the A-MSDU which led to a lower throughput. Note that for those devices the only user of the AC -> fifo mapping is the size limitation of A-MSDU. Signed-off-by: Emmanuel Grumbach <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240218194912.da336ca2fa0a.I73e44d5fc474ebb6f275b9008950e59c012f33b2@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-02-21wifi: iwlwifi: mvm: ensure offloading TID queue existsBenjamin Berg3-2/+38
The resume code path assumes that the TX queue for the offloading TID has been configured. At resume time it then tries to sync the write pointer as it may have been updated by the firmware. In the unusual event that no packets have been send on TID 0, the queue will not have been allocated and this causes a crash. Fix this by ensuring the queue exist at suspend time. Signed-off-by: Benjamin Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240218194912.6632e6dc7b35.Ie6e6a7488c9c7d4529f13d48f752b5439d8ac3c4@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-02-19wifi: wilc1000: add missing read critical sections around vif list traversalAjay Singh2-25/+35
Some code manipulating the vif list is still missing some srcu_read_lock / srcu_read_unlock, and so can trigger RCU warnings: ============================= WARNING: suspicious RCU usage 6.8.0-rc1+ #37 Not tainted ----------------------------- drivers/net/wireless/microchip/wilc1000/hif.c:110 RCU-list traversed without holding the required lock!! [...] stack backtrace: CPU: 0 PID: 6 Comm: kworker/0:0 Not tainted 6.8.0-rc1+ #37 Hardware name: Atmel SAMA5 Workqueue: events sdio_irq_work unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x58 dump_stack_lvl from wilc_get_vif_from_idx+0x158/0x180 wilc_get_vif_from_idx from wilc_network_info_received+0x80/0x48c wilc_network_info_received from wilc_handle_isr+0xa10/0xd30 wilc_handle_isr from wilc_sdio_interrupt+0x44/0x58 wilc_sdio_interrupt from process_sdio_pending_irqs+0x1c8/0x60c process_sdio_pending_irqs from sdio_irq_work+0x6c/0x14c sdio_irq_work from process_one_work+0x8d4/0x169c process_one_work from worker_thread+0x8cc/0x1340 worker_thread from kthread+0x448/0x510 kthread from ret_from_fork+0x14/0x28 Fix those warnings by adding the needed lock around the corresponding critical sections Signed-off-by: Ajay Singh <[email protected]> Co-developed-by: Alexis Lothoré <[email protected]> Signed-off-by: Alexis Lothoré <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-19wifi: wilc1000: fix declarations orderingAlexis Lothoré2-11/+11
Fix reverse-christmas tree order in some functions before adding more variables Signed-off-by: Alexis Lothoré <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-19wifi: wilc1000: use SRCU instead of RCU for vif list traversalAlexis Lothoré5-10/+16
Enabling CONFIG_PROVE_RCU_LIST raises many warnings in wilc driver, even on some places already protected by a read critical section. An example of such case is in wilc_get_available_idx: ============================= WARNING: suspicious RCU usage 6.8.0-rc1+ #32 Not tainted ----------------------------- drivers/net/wireless/microchip/wilc1000/netdev.c:944 RCU-list traversed in non-reader section!! [...] stack backtrace: CPU: 0 PID: 26 Comm: kworker/0:3 Not tainted 6.8.0-rc1+ #32 Hardware name: Atmel SAMA5 Workqueue: events_freezable mmc_rescan unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x58 dump_stack_lvl from wilc_netdev_ifc_init+0x788/0x8ec wilc_netdev_ifc_init from wilc_cfg80211_init+0x690/0x910 wilc_cfg80211_init from wilc_sdio_probe+0x168/0x490 wilc_sdio_probe from sdio_bus_probe+0x230/0x3f4 sdio_bus_probe from really_probe+0x270/0xdf4 really_probe from __driver_probe_device+0x1dc/0x580 __driver_probe_device from driver_probe_device+0x60/0x140 driver_probe_device from __device_attach_driver+0x268/0x364 __device_attach_driver from bus_for_each_drv+0x15c/0x1cc bus_for_each_drv from __device_attach+0x1ec/0x3e8 __device_attach from bus_probe_device+0x190/0x1c0 bus_probe_device from device_add+0x10dc/0x18e4 device_add from sdio_add_func+0x1c0/0x2c0 sdio_add_func from mmc_attach_sdio+0xa08/0xe1c mmc_attach_sdio from mmc_rescan+0xa00/0xfe0 mmc_rescan from process_one_work+0x8d4/0x169c process_one_work from worker_thread+0x8cc/0x1340 worker_thread from kthread+0x448/0x510 kthread from ret_from_fork+0x14/0x28 This warning is due to the section being protected by a srcu critical read section, but the list traversal being done with classic RCU API. Fix the warning by using corresponding SRCU read lock/unlock APIs. While doing so, since we always manipulate the same list (managed through a pointer embedded in struct_wilc), add a macro to reduce the corresponding boilerplate in each call site. Signed-off-by: Alexis Lothoré <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-19wifi: wilc1000: split deeply nested RCU list traversal in dedicated helperAlexis Lothoré1-11/+14
Move netif_wake_queue and its surrounding RCU operations in a dedicated function to clarify wilc_txq_task and ease refactoring Signed-off-by: Alexis Lothoré <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-19wifi: rtw89: 8922a: add helper of set_channelPing-Ke Shih3-0/+76
Reset hardware state to prevent hardware stays at abnormal state during setting channel. Besides, add preparation for MLO/DBCC before setting channel, and reconfigure registers after that. Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-19wifi: rtw89: 8922a: add set_channel RF partPing-Ke Shih6-0/+208
Configure RF registers according to band, channel, bandwidth. Since this chip will support MLO, it needs check the operating mode to decide paths we are going to configure. Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-19wifi: rtw89: 8922a: add set_channel BB partPing-Ke Shih2-0/+427
In additional to configure band, channel and bandwidth registers, it also configure CCK support on 2GHZ band, spur elimination, and RX gain. Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-19wifi: rtw89: 8922a: add set_channel MAC partPing-Ke Shih4-1/+173
To set channel, add a function to get TXSB (TX subband) that is hardware index to indicate primary channel. Then, configure band, channel, bandwidth and TXSB via registers. Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-16wifi: brcmsmac: avoid function pointer castsArnd Bergmann3-5/+5
An old cleanup went a little too far and causes a warning with clang-16 and higher as it breaks control flow integrity (KCFI) rules: drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy_shim.c:64:34: error: cast from 'void (*)(struct brcms_phy *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict] 64 | brcms_init_timer(physhim->wl, (void (*)(void *))fn, | ^~~~~~~~~~~~~~~~~~~~ Change this one instance back to passing a void pointer so it can be used with the timer callback interface. Fixes: d89a4c80601d ("staging: brcm80211: removed void * from softmac phy") Signed-off-by: Arnd Bergmann <[email protected]> Acked-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-15wifi: ath11k: remove unused scan_events from struct scan_req_paramsNicolas Escande1-18/+13
As discussed lets remove the unused scan_events field from struct scan_req_params. Also, as it is not needed anymore, remove the underlying union wrapping too. No functionnal changes. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Nicolas Escande <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-15wifi: ath11k: add support for QCA2066Baochen Qiang5-1/+115
QCA2066 is a PCI based DBS device. It is very similar to WCN6855 overall: they share the same PCI device ID, the same major and minor version numbers, the same register address, and same HAL descriptors etc. The most significant difference is that QCA2066 supports 3-antenna configuration while WCN6855 does not. To differentiate them, subversion numbers are used. Currently four numbers are used by QCA2066: 0x1019A0E1, 0x1019B0E1, 0x1019C0E1 and 0x1019D0E1. Tested-on: QCA2066 hw2.1 PCI WLAN.HSP.1.1-03737-QCAHSPSWPL_V2_SILICONZ_CE-1 Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3 Signed-off-by: Baochen Qiang <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-15wifi: ath11k: move pci.ops registration aheadBaochen Qiang1-10/+16
In ath11k_pci_probe() there is a switch statement that, based upon the PCI device ID, assigns pci_ops. After the switch, ath11k_pcic_register_pci_ops() is called to register the pci_ops. Unfortunately, this registration is too late if any of the cases in the switch need to perform operations that require the pci_ops to already be registered. In particular, an upcoming patch for QCA2066 needs to call ath11k_pcic_read32(). To address this issue, call ath11k_pcic_register_pci_ops() from each case instead of doing so after the switch. That way the ops will be registered if any subsequent operations within the case processing require the ops to be present. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3 Signed-off-by: Baochen Qiang <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-15wifi: ath11k: provide address list if chip supports 2 stationsCarl Huang1-0/+30
Provide address list to mac80211 so user doesn't need to specify addresses when a second interface is added because the address can be allocated from the list by mac80211. The derived addresses have LAA (Local Administered Address) bit set, and only the first byte is changed. Take the 00:03:7f:xx:xx:xx as example to derive: addresses[0] is unchanged, it's still 00:03:7f:xx:xx:xx, addresses[1] is 02:03:7f:xx:xx:xx, addresses[2] is 12:03:7f:xx:xx:xx, addresses[3] is 22:03:7f:xx:xx:xx, addresses[4] is 32:03:7f:xx:xx:xx. However as only 3 addresses are reported now, so addresses[3] and addresses[4] aren't actually derived. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3 Signed-off-by: Carl Huang <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-15wifi: ath11k: support 2 station interfacesCarl Huang4-26/+53
Add hardware parameter support_dual_stations to indicate whether 2 station interfaces are supported. For chips which support this feature, limit total number of AP interface and mesh point to 1. The max interfaces are 3 for such chips. The chips affected are: QCA6390 hw2.0 WCN6855 hw2.0 WCN6855 hw2.1 Other chips are not affected. For affected chips, remove radar_detect_widths because now num_different_channels is set to 2. radar_detect_widths can be set only when num_different_channels is 1, see mac80211 function wiphy_verify_combinations for details. This means that in affectected chips DFS cannot be enabled in AP mode. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3 Signed-off-by: Carl Huang <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-15wifi: rtlwifi: rtl_usb: Store the endpoint addressesBitterblue Smith6-45/+68
And use the stored addresses in rtl8192cu instead of hardcoding them. This is what the vendor drivers do. Perhaps this is not strictly necessary for RTL8192CU devices. However, the dual mac version of RTL8192DU has two USB interfaces, each with its own set of endpoints. Hardcoding their addresses in the upcoming rtl8192du driver would require making some assumptions which I'm not qualified to make. Signed-off-by: Bitterblue Smith <[email protected]> Acked-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-15wifi: rtlwifi: rtl8192cu: Fix 2T2R chip type detectionBitterblue Smith2-2/+3
rtl8192cu handles 1T1R devices (RTL8188CUS), 1T2R devices (RTL8191CU), and 2T2R devices (RTL8192CU). The 2T2R devices were incorrectly detected as 1T2R because of a mistake in the IS_92C_1T2R macro. The visible effect of this is that the firmware was allowed to use TX rates only up to MCS7. Fix the IS_92C_1T2R macro. Now my 2T2R device has much better upload speed. Before: 46 Mbps. After: 82 Mbps. Also fix a debug message which was printing "RF_1T1R" even for 1T2R chips. Signed-off-by: Bitterblue Smith <[email protected]> Acked-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-15wifi: rtw89: fw: remove unnecessary rcu_read_unlock() for puncturedPing-Ke Shih1-1/+0
The rcu_read_unlock() is accidentally added, and sparse warn: drivers/net/wireless/realtek/rtw89/fw.c:2807:17: warning: context imbalance in 'rtw89_fw_h2c_assoc_cmac_tbl_g7' - unexpected unlock Fixes: b82730bf57b5 ("wifi: cfg80211/mac80211: move puncturing into chandef") Cc: Johannes Berg <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-15wifi: rtw89: 8922a: declare to support two chanctxZong-Zhe Yang1-1/+1
We are going to allow MCC (multi-channel concurrency) on RTL8922A. So, increase 8922a::support_chanctx_num up to 2 first. Signed-off-by: Zong-Zhe Yang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-15wifi: rtw89: chan: support MCC on Wi-Fi 7 chipsZong-Zhe Yang2-27/+420
On Wi-Fi 7 chips, concurrent stuffs are supported by FW MRC series (multi-role concurrent) functions. And, driver has implemented the corresponding SW handling in patches in front of this one. Now, we extend SW MCC (multi-channel concurrent) flow to work on Wi-Fi 7 chips. In SW point of view, things look as below. | SW | | FW func | | | | H2C/C2H | -------------------------------------------- | | ax | | | /----| FW MCC func | | MCC | -- chip --+ | | | \----| FW MRC func | | | be | Signed-off-by: Zong-Zhe Yang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-15wifi: rtw89: fw: implement MRC H2C command functionsZong-Zhe Yang2-0/+460
Implement MRC (multiple role concurrent) H2C commands. Mainly deal with H2C format, LE type built from CPU value, default setting on some fields, and then sending the command to FW. Besides, MRC start, MRC delete, and MRC request TSF need to wait for a report from C2H events. Signed-off-by: Zong-Zhe Yang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-15wifi: rtw89: mac: implement MRC C2H event handlingZong-Zhe Yang4-1/+112
Add handling of MRC (multiple role concurrent) C2H events including TSF report and status report. Parse report data and then complete the corresponding H2C commands, which will be implemented in the following. Signed-off-by: Zong-Zhe Yang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-15wifi: rtw89: fw: add definition of H2C command and C2H event for MRC seriesZong-Zhe Yang2-6/+190
For Wi-Fi 7 chips, FW supports MRC (multi-role concurrent) functions including H2C commands and C2H events. We can consider FW MRC functions as a superset of FW MCC (multi-channel concurrent) functions. And, MRC functions can take MLO things into account. Basically before MLO, SW can also manipulate FW MRC to work original SW MCC flow. So, we add them first and implement the handling in the following. And then, SW MCC will call different series of FW functions according to chip later. Signed-off-by: Zong-Zhe Yang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-15wifi: wilc1000: validate chip id during bus probeDavid Mosberger-Tang3-20/+59
Previously, the driver created a net device (typically wlan0) as soon as the module was loaded. This commit changes the driver to follow normal Linux convention of creating the net device only when bus probing detects a supported chip. Signed-off-by: David Mosberger-Tang <[email protected]> Tested-By: Alexis Lothoré <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-15wifi: wilc1000: prevent use-after-free on vif when cleaning up all interfacesAlexis Lothoré1-21/+7
wilc_netdev_cleanup currently triggers a KASAN warning, which can be observed on interface registration error path, or simply by removing the module/unbinding device from driver: echo spi0.1 > /sys/bus/spi/drivers/wilc1000_spi/unbind ================================================================== BUG: KASAN: slab-use-after-free in wilc_netdev_cleanup+0x508/0x5cc Read of size 4 at addr c54d1ce8 by task sh/86 CPU: 0 PID: 86 Comm: sh Not tainted 6.8.0-rc1+ #117 Hardware name: Atmel SAMA5 unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x58 dump_stack_lvl from print_report+0x154/0x500 print_report from kasan_report+0xac/0xd8 kasan_report from wilc_netdev_cleanup+0x508/0x5cc wilc_netdev_cleanup from wilc_bus_remove+0xc8/0xec wilc_bus_remove from spi_remove+0x8c/0xac spi_remove from device_release_driver_internal+0x434/0x5f8 device_release_driver_internal from unbind_store+0xbc/0x108 unbind_store from kernfs_fop_write_iter+0x398/0x584 kernfs_fop_write_iter from vfs_write+0x728/0xf88 vfs_write from ksys_write+0x110/0x1e4 ksys_write from ret_fast_syscall+0x0/0x1c [...] Allocated by task 1: kasan_save_track+0x30/0x5c __kasan_kmalloc+0x8c/0x94 __kmalloc_node+0x1cc/0x3e4 kvmalloc_node+0x48/0x180 alloc_netdev_mqs+0x68/0x11dc alloc_etherdev_mqs+0x28/0x34 wilc_netdev_ifc_init+0x34/0x8ec wilc_cfg80211_init+0x690/0x910 wilc_bus_probe+0xe0/0x4a0 spi_probe+0x158/0x1b0 really_probe+0x270/0xdf4 __driver_probe_device+0x1dc/0x580 driver_probe_device+0x60/0x140 __driver_attach+0x228/0x5d4 bus_for_each_dev+0x13c/0x1a8 bus_add_driver+0x2a0/0x608 driver_register+0x24c/0x578 do_one_initcall+0x180/0x310 kernel_init_freeable+0x424/0x484 kernel_init+0x20/0x148 ret_from_fork+0x14/0x28 Freed by task 86: kasan_save_track+0x30/0x5c kasan_save_free_info+0x38/0x58 __kasan_slab_free+0xe4/0x140 kfree+0xb0/0x238 device_release+0xc0/0x2a8 kobject_put+0x1d4/0x46c netdev_run_todo+0x8fc/0x11d0 wilc_netdev_cleanup+0x1e4/0x5cc wilc_bus_remove+0xc8/0xec spi_remove+0x8c/0xac device_release_driver_internal+0x434/0x5f8 unbind_store+0xbc/0x108 kernfs_fop_write_iter+0x398/0x584 vfs_write+0x728/0xf88 ksys_write+0x110/0x1e4 ret_fast_syscall+0x0/0x1c [...] David Mosberger-Tan initial investigation [1] showed that this use-after-free is due to netdevice unregistration during vif list traversal. When unregistering a net device, since the needs_free_netdev has been set to true during registration, the netdevice object is also freed, and as a consequence, the corresponding vif object too, since it is attached to it as private netdevice data. The next occurrence of the loop then tries to access freed vif pointer to the list to move forward in the list. Fix this use-after-free thanks to two mechanisms: - navigate in the list with list_for_each_entry_safe, which allows to safely modify the list as we go through each element. For each element, remove it from the list with list_del_rcu - make sure to wait for RCU grace period end after each vif removal to make sure it is safe to free the corresponding vif too (through unregister_netdev) Since we are in a RCU "modifier" path (not a "reader" path), and because such path is expected not to be concurrent to any other modifier (we are using the vif_mutex lock), we do not need to use RCU list API, that's why we can benefit from list_for_each_entry_safe. [1] https://lore.kernel.org/linux-wireless/[email protected]/ Fixes: 8399918f3056 ("staging: wilc1000: use RCU list to maintain vif interfaces list") Signed-off-by: Alexis Lothoré <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-15wifi: iwlwifi: cancel session protection only if there is oneMiri Korenblit1-4/+12
mac80211 might (due to an unavoidable race) cancel a ROC that has already expired. In that case the driver should not send the session protection cmd to cancel the ROC. When session protection is supported, the te_data::id field is reused to save the configuration id. Check it before sending the cmd. Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240205211151.30176bf869d9.Id811c20d3746b870cbe0c946bbfe1c0ab0a290cb@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-02-15wifi: iwlwifi: mvm: remove IWL_MVM_STATUS_NEED_FLUSH_P2PMiri Korenblit2-55/+38
This is set when a P2P ROC ends, and uses as an indication inside iwl_mvm_roc_done_wk that the resources used for this ROC (sta/link) needs to be flushed/deactivated (respectively). But we also have IWL_MVM_STATUS_ROC_RUNNING, which is set whenever P2P ROC starts, and is not even used in iwl_mvm_roc_done_wk. Use IWL_MVM_STATUS_ROC_RUNNING as an indicator, and remove the redundant bit. While at it, add a call to synchronize_net also for the AUX ROC case, which is missing in the existing code. Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240205211151.0494f75de311.Ic4aacacf7581a5c9046c4f1df87cbb67470853e7@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-02-15Merge wireless into wireless-nextJohannes Berg5-17/+77
There's a conflict already and some upcoming changes also depend on changes in wireless for being conflict- free, so pull wireless in to make all that easier. Signed-off-by: Johannes Berg <[email protected]>
2024-02-14wifi: ath12k: remove the unused scan_events from ath12k_wmi_scan_req_argNicolas Escande1-18/+13
As done for ath11k, lets keep on cleaning up struct ath12k_wmi_scan_req_arg by removing the unused scan_events. Also remove the underlying union & struct construct as it isn't needed anymore. No functionnal changes. Signed-off-by: Nicolas Escande <[email protected]> Acked-by: Jeff Johnson <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-14wifi: ath12k: Remove unused scan_flags from struct ath12k_wmi_scan_req_argNicolas Escande1-30/+25
As we did for ath11k lets remove the unused scan_flags from struct ath12k_wmi_scan_req_arg. This will prevent us from using out of sync values between WMI_SCAN_XXX & scan_f_xxx bitfield. While at it remove the underlying wrapping struct/union construct as it serves no purpose anymore. Signed-off-by: Nicolas Escande <[email protected]> Acked-by: Jeff Johnson <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-14wifi: ath12k: Do not use scan_flags from struct ath12k_wmi_scan_req_argNicolas Escande2-3/+3
As discussed in [1] to fix the mismatch between the WMI_SCAN_XXX macros & their corresponding scan_f_xxx bitfield equivalent, lets stop using the scan_flags in the union altogether. [1] https://lore.kernel.org/all/[email protected]/ Tested-on: QCN9274 hw2.0 PCI CI_WLAN.WBE.1.3-02907.1-QCAHKSWPL_SILICONZ-10 Signed-off-by: Nicolas Escande <[email protected]> Acked-by: Jeff Johnson <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-14wifi: carl9170: Remove redundant assignment to pointer superColin Ian King1-1/+1
The pointer super is being assigned a value that is not being read, it is being re-assigned later. The assignment is redundant and can be removed. Cleans up clang scan warning: drivers/net/wireless/ath/carl9170/tx.c:192:34: warning: Value stored to 'super' during its initialization is never read [deadcode.DeadStores] Signed-off-by: Colin Ian King <[email protected]> Acked-by: Christian Lamparter <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-14wifi: ath11k: Remove scan_flags union from struct scan_req_paramsNicolas Escande1-30/+25
Now that we do not use scan_flags directly with WMI_SCAN_XXX macros anymore but only the bitfield scan_f_xxx, lets remove the scan_flags & the underlying union. This will prevent further problems as some entries in the scan_f_xxx bitfield don't match their corresponding WMI_SCAN_XXX flags as seen in [1] [1] https://lore.kernel.org/all/[email protected]/ Signed-off-by: Nicolas Escande <[email protected]> Acked-by: Jeff Johnson <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-14wifi: ath11k: Do not directly use scan_flags in struct scan_req_paramsNicolas Escande2-4/+4
As discussed in [1] lets not use WMI_SCAN_XXX defines in combination with scan_flags directly when setting scan params in struct scan_req_params but use the underlying bitfield. This bitfield is then converted to WMI_SCAN_XXX when filling the WMI command to send to the firmware. [1] https://lore.kernel.org/all/[email protected]/ Tested-on: QCN9074 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 Signed-off-by: Nicolas Escande <[email protected]> Acked-by: Jeff Johnson <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-02-12wifi: iwlwifi: mvm: check own capabilities for EMLSRJohannes Berg1-0/+7
There may be different hardware or configurations supported, so check for our own EMLSR capability before allowing it to be used, in addition to checking the AP's. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240208185302.036443611696.If33caabd7cf372834287863b40b2d6d1ef1ca3f7@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-02-12wifi: iwlwifi: bump FW API to 89 for AX/BZ/SC devicesMiri Korenblit3-5/+5
Start supporting API version 89 for new devices. Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240208185302.b5d0c18c3dad.I55d5bd15638970d27b30b38e9ef47cddf6ba715e@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-02-12wifi: iwlwifi: iwl-trans.h: clean up kernel-docJohannes Berg1-13/+51
Add missing kernel-doc, fix annotations, etc. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240208185302.a66b5cad363b.I3ee4522ac34c3e5984fce5c1cb677fb3db7a965b@changeid Signed-off-by: Johannes Berg <[email protected]>
2024-02-12wifi: iwlwifi: fw: file: clean up kernel-docJohannes Berg1-3/+13
Add missing kernel-doc and otherwise fix things. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20240208185302.c41fddd32c18.I1978ed9aa0484b37504f2bd4614ae0f620821f81@changeid Signed-off-by: Johannes Berg <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.