- 28 Sep, 2021 34 commits
-
-
Seevalamuthu Mariappan authored
Renaming of macro is done to describe the macro functionality better as the macro functionality is modified in next patch-sets. No functional changes are done. Signed-off-by:
Seevalamuthu Mariappan <seevalam@codeaurora.org> Signed-off-by:
Jouni Malinen <jouni@codeaurora.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210913223148.208026-2-jouni@codeaurora.org
-
Baochen Qiang authored
The buffer pointed to by event is not freed in case ATH11K_FLAG_UNREGISTERING bit is set, resulting in memory leak, so fix it. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Fixes: d5c65159 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by:
Baochen Qiang <bqiang@codeaurora.org> Signed-off-by:
-
Baochen Qiang authored
Current code clears debug registers after SOC global reset performed in ath11k_pci_sw_reset. However at that time those registers are not accessible due to reset, thus they are actually not cleared at all. For WCN6855, it may cause target fail to initialize. This issue can be fixed by moving clear action ahead. In addition, on some specific platforms, need to add delay to wait those registers to become accessible. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by:
-
Baochen Qiang authored
There are MSDUs whose length are invalid. For example, attackers may inject on purpose truncated A-MSDUs with invalid MSDU length. Such MSDUs are marked with an err bit set in rx attention tlvs, so we can check and drop them. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by:
-
Wen Gong authored
WCN6855 has 2 phys, one is 2G, another is 5G/6G, so it should copy the cap info of 6G band under the check of WMI_HOST_WLAN_5G_CAP as well as for the 5G band. Some chips like QCN9074 only have 6G, not have 2G and 5G, and this 6G capability is also under WMI_HOST_WLAN_5G_CAP, so this change will not disturb it. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by:
Wen Gong <wgong@codeaurora.org> Signed-off-by:
-
Wen Gong authored
For some chips such as WCN6855, single_pdev_only is set in struct ath11k_hw_params which means ath11k calls ieee80211_register_hw() only once and create only one device interface, and that device interface supports all 2G/5G/6G channels. ath11k_mac_setup_channels_rates() sets up the channels and it is called for each device interface. It is called only once for single_pdev_only, and then set up all channels for 2G/5G/6G. The logic of ath11k_mac_setup_channels_rates() is not suitable for single_pdev_only, it leads to all 6G channels being disabled for the device interface which is single_pdev_only such as WCN6855. Add channel frequency checks for the 6G band and enable the 6G channels properly based on what is supported by the chip. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by:
-
Wen Gong authored
WCN6855 uses single_pdev_only, so it supports both the 5G and 6G bands in the same ath11k/pdev and it needs to enable ht_cap/vht_cap for the 5G band, otherwise it will downgrade to non-HT mode for the 5G band. Some chips like QCN9074 only support the 6G band, not the 5G band, and use the flag ar->supports_6ghz which is true to discard ht_cap/vht_cap. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by:
-
Pradeep Kumar Chitrapu authored
When ath11k receives survey request, choose the 6 GHz band when enabled. Without this, survey request does not include any 6 GHz band results, thereby causing auto channel selection to fail. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01386-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> Signed-off-by:
-
Pradeep Kumar Chitrapu authored
Frequency in rx status is being filled incorrectly in the 6 GHz band as channel number received is invalid in this case which is causing packet drops. So fix that. Fixes: 5dcf42f8 ("ath11k: Use freq instead of channel number in rx path") Signed-off-by:
-
Pradeep Kumar Chitrapu authored
Add support for the 6 GHz channel 2 with center frequency 5935 MHz and operating class 136 per IEEE Std 802.11ax-2021, Table E-4. Signed-off-by:
-
P Praneesh authored
When the driver sends a peer create cmd, the firmware responds with WMI_PEER_CREATE_CONF_EVENTID to confirm the firmware received WMI_PEER_CREATE_CMDID. Since the peer create conf event is not handled in ath11k_wmi_tlv_op_rx, we are getting unknown event id warning prints during peer creation. Add WMI_PEER_CREATE_CONF_EVENTID in wmi_tlv_event_id and handle the same as unsupported event id under wmi logs. warning prints: [ 4382.230817] ath11k_pci 0000:01:00.0: Unknown eventid: 0x601a Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01695-QCAHKSWPL_SILICONZ-1 Signed-off-by:
P Praneesh <ppranees@codeaurora.org> Signed-off-by:
-
Karthikeyan Periyasamy authored
Facing below warning prints when we do wifi down in multiple VAPs scenario. warning print: ath11k c000000.wifi: No VIF found for vdev 2 ... ath11k c000000.wifi: No VIF found for vdev 0 In ath11k_mac_get_arvif_by_vdev_id(), we iterate all the radio to get the arvif for the requested vdev_id through ath11k_mac_get_arvif(). ath11k_mac_get_arvif() throws a warning message if the given vdev_id is not found in the given radio. So to avoid the warning message, add the allocated_vdev_map cross check against the given vdev_id before using ath11k_mac_get_arvif() to ensure that vdev_id is allocated in the given radio. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01492-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ6018 hw1.0 AHB WLAN.HK.2.4.0.1-00330-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Karthikeyan Periyasamy <periyasa@codeaurora.org> Signed-off-by:
-
Sriram R authored
In scenario when a peer is disassociating, there could be multiple places where a reo cmd ring is accessed, such as during aggregation teardown, tid queue cleanup, etc. When this happens during firmware recovery where accessing of FW/HW resources/registers is not recommended, accessing reo cmd ring in this case could lead to crash or undefined behaviour. Hence avoid this by checking for corresponding flag to avoid accessing reo cmd ring during firmware recovery. Sample crash: [ 3936.456050] Unhandled fault: imprecise external abort (0x1c06) at 0x54bb842a [ 3936.456411] WARN: Access Violation!!!, Run "cat /sys/kernel/debug/qcom_debug_logs/tz_log" for more details [ 3936.467997] pgd = b4474000 [ 3936.477440] [54bb842a] *pgd=6fa61831, *pte=7f95d59f, *ppte=7f95de7e <snip> [ 3937.177436] [<8030ab10>] (_raw_spin_unlock_bh) from [<7f5e9eb8>] (ath11k_hal_reo_cmd_send+0x440/0x458 [ath11k]) [ 3937.185730] [<7f5e9eb8>] (ath11k_hal_reo_cmd_send [ath11k]) from [<7f601c4c>] (ath11k_dp_tx_send_reo_cmd+0x2c/0xcc [ath11k]) [ 3937.195524] [<7f601c4c>] (ath11k_dp_tx_send_reo_cmd [ath11k]) from [<7f602f10>] (ath11k_peer_rx_tid_reo_update+0x84/0xbc [ath11k]) [ 3937.206984] [<7f602f10>] (ath11k_peer_rx_tid_reo_update [ath11k]) from [<7f605a9c>] (ath11k_dp_rx_ampdu_stop+0xa8/0x130 [ath11k]) [ 3937.218532] [<7f605a9c>] (ath11k_dp_rx_ampdu_stop [ath11k]) from [<7f5f6730>] (ath11k_mac_op_ampdu_action+0x6c/0x98 [ath11k]) [ 3937.230250] [<7f5f6730>] (ath11k_mac_op_ampdu_action [ath11k]) from [<c7b6e890>] (___ieee80211_stop_rx_ba_session+0x98/0x144 [mac80211]) [ 3937.241499] [<c7b6e890>] (___ieee80211_stop_rx_ba_session [mac80211]) from [<c7b6cdd8>] (ieee80211_sta_tear_down_BA_sessions+0x4c/0xf4 [) [ 3937.253833] [<c7b6cdd8>] (ieee80211_sta_tear_down_BA_sessions [mac80211]) from [<c7b63460>] (ieee80211_sta_eosp+0x5b8/0x960 [mac80211]) [ 3937.266764] [<c7b63460>] (ieee80211_sta_eosp [mac80211]) from [<c7b66da8>] (__sta_info_flush+0x9c/0x134 [mac80211]) [ 3937.278826] [<c7b66da8>] (__sta_info_flush [mac80211]) from [<c7b7bd00>] (ieee80211_stop_ap+0x14c/0x28c [mac80211]) [ 3937.289240] [<c7b7bd00>] (ieee80211_stop_ap [mac80211]) from [<7f509cf0>] (__cfg80211_stop_ap+0x4c/0xd8 [cfg80211]) [ 3937.299629] [<7f509cf0>] (__cfg80211_stop_ap [cfg80211]) from [<7f4dddec>] (cfg80211_leave+0x24/0x30 [cfg80211]) [ 3937.310041] [<7f4dddec>] (cfg80211_leave [cfg80211]) from [<7f4de03c>] (cfg80211_netdev_notifier_call+0x174/0x48c [cfg80211]) [ 3937.320457] [<7f4de03c>] (cfg80211_netdev_notifier_call [cfg80211]) from [<80339928>] (notifier_call_chain+0x40/0x68) [ 3937.331636] [<80339928>] (notifier_call_chain) from [<803399a8>] (raw_notifier_call_chain+0x14/0x1c) [ 3937.342221] [<803399a8>] (raw_notifier_call_chain) from [<8073bb00>] (call_netdevice_notifiers+0xc/0x14) Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.1.0.1-01240-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Sriram R <srirrama@codeaurora.org> Signed-off-by:
-
Seevalamuthu Mariappan authored
Firmware crash is seen randomly, because of sending wrong vdev_id in vdev_create command. This is due to free_vdev_map value being 0. free_vdev_map is getting assigned after ieee80211_register_hw. In some race conditions, add_interface api is getting called before assigning value to free_vdev_map. Fix this by assigning free_vdev_map before ieee80211_register_hw. Also, moved ar->cc_freq_hz and ar->txmgmt_idr initialization before ieee80211_register_hw to avoid such race conditions. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-00948-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01734-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Seevalamuthu Mariappan authored
Firmware blocks all data traffic until the key is plumbed. But, with software encryption mode, key is never plumbed to firmware. Due to this, a traffic failure in software encryption mode has been observed. Hence, firmware has introduced a flag to differentiate software encryption mode. This flag can be passed during vdev_start command. Enable WMI_VDEV_START_HW_ENCRYPTION_DISABLED flag in vdev_start command to notify firmware to disable hardware encryption for a vdev. This is set if raw mode software encryption is enabled. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01421-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Sriram R authored
Whenever ath11k is bootup with a user country already set, cfg80211 notifies this country info to ath11k soon after registration, where the notification is sent to the firmware for fetching the rules of this user country input. Multiple race conditions could be seen in this scenario where a new request is either lost as pointed in [1] or a new regd overwrites the default regd provided by the firmware during bootup. Note that, the default regd is used for intersection purpose and hence it should not be overwritten. The main reason as pointed by [1] is the usage of ATH11K_FLAG_REGISTERED flag which is updated after completion of core registration, whereas the reg notification from cfg80211 and wmi events for the corresponding request can happen much before that. Since the ATH11K_FLAG_REGISTERED is currently used to determine if the event containing reg rules belong to default regd or for user request, there is a possibility of the default regd getting overwritten. Since the default reg rules will be received only once per pdev on firmware load, the above flag based check can be replaced with a check to see if default_regd is already set, so that we can now always update the new_regd. Also if the new_regd is set, this will be always used to update the reg rules for the registered phy. [1] https://patchwork.kernel.org/project/linux-wireless/patch/1829665.1PRlr7bOQj@ripper/ Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01460-QCAHKSWPL_SILICONZ-1 Fixes: d5c65159 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by:
-
Sriram R authored
During firmware recovery, the default reg rules which are received via WMI_REG_CHAN_LIST_CC_EVENT can overwrite the currently configured user regd. See below snap for example, root@OpenWrt:/# iw reg get | grep country country FR: DFS-ETSI country FR: DFS-ETSI country FR: DFS-ETSI country FR: DFS-ETSI root@OpenWrt:/# echo assert > /sys/kernel/debug/ath11k/ipq8074\ hw2.0/simulate_f w_crash <snip> [ 5290.471696] ath11k c000000.wifi1: pdev 1 successfully recovered root@OpenWrt:/# iw reg get | grep country country FR: DFS-ETSI country US: DFS-FCC country US: DFS-FCC country US: DFS-FCC In the above, the user configured country 'FR' is overwritten when the rules of default country 'US' are received and updated during recovery. Hence avoid processing of these rules in general during firmware recovery as they have been already applied during driver registration or after last set user country is configured. This scenario applies for both AP and STA devices basically because cfg80211 is not aware of the recovery and only the driver recovers, but changing or resetting of the reg domain during recovery is not needed so as to continue with the configured regdomain currently in use. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01460-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Sriram R authored
Update the fields of pdev tx and tx firmware stats structure. Missing fields resulted in wrong fw stats to be displayed as below. root@OpenWrt:/# cat /sys/kernel/debug/ath11k/ ipq8074\ hw2.0/mac0/fw_stats/pdev_stats | grep Illegal Illegal rate phy errors 36839112 Note that this struct was missing its members from initial driver support and this change doesn't introduce/modify the structure for firmware changes. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01734-QCAHKSWPL_SILICONZ-1 v2 Signed-off-by:
-
Anilkumar Kolli authored
Fix sending rx_buf_sz to ath11k_dp_tx_htt_rx_filter_setup() to enable pktlog full or lite mode. Depending on mode update the trace buffer with log type full/lite. Pktlog lite is a lighter version of pktlog. This can be used to capture PPDU stats. These are useful for firmware performance debugging. pktlog lite dumps are enabled using, echo "0x0 1" > ath11k/IPQ8074 hw2.0/mac0/pktlog_filter Tested On: IPQ8074 hw2.0 AHB WLAN.HK.2.1.0.1-01233-QCAHKSWPL_SILICONZ-1 v2 Signed-off-by:
Anilkumar Kolli <akolli@codeaurora.org> Signed-off-by:
-
Sriram R authored
Add support for rx decapsulation offload by advertising the support to mac80211 during registration. Also ensure the frames have the RX_FLAG_8023 flag set in decap offload frames before passing to mac80211. Since the packets delivered to the driver are in 802.3 format, these can be sent to the network core with minimal processing in mac80211. This helps in releasing some CPU cycles in the host processor and thereby improving the performance. Two exceptions are made before passing decap frames, one is for EAPOL packets since mac80211 8023 fast rx for the sta is set only after authorization, other case is for multicast packets to validate PN in mac80211. In both the cases the decap frames are converted to 80211 frame and sent to mac80211. Ethernet decap can be enabled by using frame_mode modparam: insmod ath11k frame_mode=2 Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-00844-QCAHKSWPL_SILICONZ-1 v2 Co-developed-by:
Manikanta Pubbisetty <mpubbise@codeaurora.org> Signed-off-by:
-
Dan Carpenter authored
The ath11k_dbring_bufs_replenish() and ath11k_dbring_fill_bufs() take a "gfp" parameter but they since they take spinlocks, the allocations they do have to be atomic. This causes a bug because ath11k_dbring_buf_setup passes GFP_KERNEL for the gfp flags. The fix is to use GFP_ATOMIC and remove the unused parameters. Fixes: bd647855 ("ath11k: Add direct buffer ring support") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Aaron Ma authored
qmi tries to allocate a large contiguous dma memory at first, on the AMD Ryzen platform it fails, then retries with small slices. So set flag GFP_NOWARN to avoid flooding dmesg. Signed-off-by:
Aaron Ma <aaron.ma@canonical.com> Signed-off-by:
-
Gustavo A. R. Silva authored
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use "flexible array members"[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code a bit according to the use of a flexible-array member in struct scan_chan_list_params instead of a one-element array, and use the struct_size() helper. Also, save 25 (too many) bytes that were being allocated: $ pahole -C channel_param drivers/net/wireless/ath/ath11k/reg.o struct channel_param { u8 chan_id; /* 0 1 */ u8 pwr; /* 1 1 */ u32 mhz; /* 2 4 */ /* Bitfield combined with next fields */ u32 half_rate:1; /* 4:16 4 */ u32 quarter_rate:1; /* 4:17 4 */ u32 dfs_set:1; /* 4:18 4 */ u32 dfs_set_cfreq2:1; /* 4:19 4 */ u32 is_chan_passive:1; /* 4:20 4 */ u32 allow_ht:1; /* 4:21 4 */ u32 allow_vht:1; /* 4:22 4 */ u32 allow_he:1; /* 4:23 4 */ u32 set_agile:1; /* 4:24 4 */ u32 psc_channel:1; /* 4:25 4 */ /* XXX 6 bits hole, try to pack */ u32 phy_mode; /* 8 4 */ u32 cfreq1; /* 12 4 */ u32 cfreq2; /* 16 4 */ char maxpower; /* 20 1 */ char minpower; /* 21 1 */ char maxregpower; /* 22 1 */ u8 antennamax; /* 23 1 */ u8 reg_class_id; /* 24 1 */ /* size: 25, cachelines: 1, members: 21 */ /* sum members: 23 */ /* sum bitfield members: 10 bits, bit holes: 1, sum bit holes: 6 bits */ /* last cacheline: 25 bytes */ } __attribute__((__packed__)); as previously, sizeof(struct scan_chan_list_params) was 32 bytes: $ pahole -C scan_chan_list_params drivers/net/wireless/ath/ath11k/reg.o struct scan_chan_list_params { u32 pdev_id; /* 0 4 */ u16 nallchans; /* 4 2 */ struct channel_param ch_param[1]; /* 6 25 */ /* size: 32, cachelines: 1, members: 3 */ /* padding: 1 */ /* last cacheline: 32 bytes */ }; and now with the flexible array transformation it is just 8 bytes: $ pahole -C scan_chan_list_params drivers/net/wireless/ath/ath11k/reg.o struct scan_chan_list_params { u32 pdev_id; /* 0 4 */ u16 nallchans; /* 4 2 */ struct channel_param ch_param[]; /* 6 0 */ /* size: 8, cachelines: 1, members: 3 */ /* padding: 2 */ /* last cacheline: 8 bytes */ }; This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). This issue was found with the help of Coccinelle and audited and fixed, manually. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.10/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/109Signed-off-by:Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Anilkumar Kolli authored
Firmware updates EEPROM support capability in QMI FW caps, send QMI BDF download request message with file type EEPROM, to get caldata download from EEPROM. Firmware takes more time to update cal data from EEPROM, so increase QMI timeout. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01838-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Anilkumar Kolli authored
If multiple PCI cards are attached, each needs its own caldata file. Added new Caldata file name, PCI Bus: cal-pci-0001:01:00.0.bin cal-pci-0000:01:00.0.bin AHB Bus: cal-ahb-c000000.wifi1.bin Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00009-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01838-QCAHKSWPL_SILICONZ-1 Signed-off-by: -
Anilkumar Kolli authored
In current code, AHB/PCI uses two separate functions to download BDF file. Refactor code and make a common function to send QMI BDF download request for both AHB and PCI devices. This patch has no functional change. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00009-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01838-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Anilkumar Kolli authored
Reuse board_size from hw_params, add cal_offset to hw params. This patch is clean up only, there is no change in functionality. cal_size was unused, so remove that. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00009-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01838-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Arnd Bergmann authored
gcc-11 with the kernel address sanitizer prints a warning for this driver: In function 'ath11k_peer_assoc_h_vht', inlined from 'ath11k_peer_assoc_prepare' at drivers/net/wireless/ath/ath11k/mac.c:1632:2: drivers/net/wireless/ath/ath11k/mac.c:1164:13: error: 'ath11k_peer_assoc_h_vht_masked' reading 16 bytes from a region of size 4 [-Werror=stringop-overread] 1164 | if (ath11k_peer_assoc_h_vht_masked(vht_mcs_mask)) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/ath/ath11k/mac.c: In function 'ath11k_peer_assoc_prepare': drivers/net/wireless/ath/ath11k/mac.c:1164:13: note: referencing argument 1 of type 'const u16 *' {aka 'const short unsigned int *'} drivers/net/wireless/ath/ath11k/mac.c:969:1: note: in a call to function 'ath11k_peer_assoc_h_vht_masked' 969 | ath11k_peer_assoc_h_vht_masked(const u16 vht_mcs_mask[NL80211_VHT_NSS_MAX]) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ According to analysis from gcc developers, this is a glitch in the way gcc tracks the size of struct members. This should really get fixed in gcc, but it's also easy to work around this instance by changing the function prototype to no include the length of the array. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99673Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Karthikeyan Periyasamy authored
Populate the below hw parameters as per the QCN9074 support 1. FFT bin size as two bytes 2. Maximum FFT bin count as 1024 3. Summary report pad size as 16 4. FFT report header length as 24 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01492-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Karthikeyan Periyasamy authored
User was not able to configure the spectral with the FFT bin count 32. In all supported platforms, the expected minimum FFT bin count is 32 but it was wrongly defined as 64. This restrict the user to not configure down to the actually supported minimum FFT bin count. So update the minimum FFT bin count as 32. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01492-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ6018 hw1.0 AHB WLAN.HK.2.4.0.1-00330-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Karthikeyan Periyasamy authored
Below parameters have been identified as configurable across the platforms. So to scale the spectral across the platforms, move these parameter into hw param. 1. Maximum FFT bins 2. Summary report pad size 3. FFT report header length Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01492-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ6018 hw1.0 AHB WLAN.HK.2.4.0.1-00330-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Karthikeyan Periyasamy authored
In IPQ8074, actual FFT bin size is two bytes but hardware reports it with extra pad size of two bytes for each FFT bin. So finally each FFT bin advertise as four bytes size in the collected data. This FFT pad is not advertised in IPQ6018 platform. To accommodate this different behavior across the platforms, introduce the hw param fft_pad_sz and use it in spectral process. Also group all the spectral params under the new structure in hw param structure for scalable in future. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01492-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ6018 hw1.0 AHB WLAN.HK.2.4.0.1-00330-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
P Praneesh authored
For 160 MHz, nss_ratio_enabled flag is added to indicate firmware supports sending NSS ratio information from firmware as a part of service ready ext event. Extract this NSS ratio info from service ready ext event and save this information in ath11k_pdev_cap to calculate NSS ratio. Current firmware configurations support two types of NSS ratio which is WMI_NSS_RATIO_1_NSS for QCN9074 and WMI_NSS_RATIO_1BY2_NSS for IPQ8074. Based on this two configuration, max supported NSS getting calculated. Move ath11k_peer_assoc_h_phymode() before ath11k_peer_assoc_h_vht() to get arg->peer_phymode updated. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-00097-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01467-QCAHKSWPL_SILICONZ-1 Co-developed-by:
Ganesh Sesetti <gseset@codeaurora.org> Signed-off-by:
Sathishkumar Muruganandam <murugana@codeaurora.org> Signed-off-by:
-
Miles Hu authored
Support setting fixed HE rate/gi/ltf values that we are now able to send to the kernel using nl80211. The added code is reusing parts of the existing code path already used for HT/VHT. The new helpers are symmetric to how we do it for HT/VHT. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-00235-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Miles Hu <milehu@codeaurora.org> Co-developed-by:
Aloka Dixit <alokad@codeaurora.org> Signed-off-by:
Lavanya Suresh <lavaks@codeaurora.org> Signed-off-by:
Venkateswara Naralasetty <vnaralas@codeaurora.org> Signed-off-by:
-
- 24 Sep, 2021 3 commits
-
-
Seevalamuthu Mariappan authored
If monitor interface is enabled in co-exist mode, only local traffic are captured. It's caused by missing monitor vdev in co-exist mode. So, monitor mode clean up is done with separate Monitor APIs. For this, introduce flags monitor_started and monitor_vdev_created. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01725-QCAHKSWPL_SILICONZ-1 Co-developed-by:
Vasanthakumar Thiagarajan <vthiagar@codeaurora.org> Signed-off-by:
-
Seevalamuthu Mariappan authored
Add separate APIs for monitor_vdev_create/monitor_vdev_delete and monitor_vdev_start/monitor_vdev_stop. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01725-QCAHKSWPL_SILICONZ-1 Co-developed-by:
-
Seevalamuthu Mariappan authored
This is to prepare for monitor mode clean up. No functional changes are done. Co-developed-by:
-
- 21 Sep, 2021 3 commits
-
-
Bryan O'Donoghue authored
Idle Mode Power Save (IMPS) is a power saving mechanism which when called by wcn36xx will cause the radio hardware to enter power collapse. This particular call maps nicely to a simple conjunction/disjunction around IEEE80211_CONF_CHANGE_IDLE and IEEE80211_CONF_IDLE. Here we enter idle when we are not associated with an AP. The kernel will incrementally toggle idle on/off in the process of trying to establish a connection, thus saving power until we are connected to the AP again, at which point we give way to BMPS if power_save is on. We've validated that with IMPS an apq8039 device which has the wcn36xx module loaded but, has not authenticated with an AP will get to VMIN on suspend and will not without IMPS. Signed-off-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by:
Benjamin Li <benl@squareup.com> Signed-off-by:
-
Bryan O'Donoghue authored
Qcom documents suggest passing of negative values to the dump command, however currently we convert from string to u32 not s32, so we cannot pass a two's complement value to the firmware in this way. There is in fact only one parameter which takes a two's complement value <tigger threshold> in the antenna diversity switch command. Downstream: iwpriv wlan0 dump 71 3 <schedule period> <trigger threshold> <hysteresis value> Upstream: echo "71 3 <schedule period> <trigger threshold> <hysteresis value>" > /sys/kernel/debug/ieee80211/phy0/wcn36xx/dump Fixes: 8e84c258 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Signed-off-by:
-
Bryan O'Donoghue authored
We have been tracking a strange bug with Antenna Diversity Switching (ADS) on wcn3680b for a while. ADS is configured like this: A. Via a firmware configuration table baked into the NV area. 1. Defines if ADS is enabled. 2. Defines which GPIOs are connected to which antenna enable pin. 3. Defines which antenna/GPIO is primary and which is secondary. B. WCN36XX_CFG_VAL(ANTENNA_DIVERSITY, N) N is a bitmask of available antenna. Setting N to 3 indicates a bitmask of enabled antenna (1 | 2). Obviously then we can set N to 1 or N to 2 to fix to a particular antenna and disable antenna diversity. C. WCN36XX_CFG_VAL(ASD_PROBE_INTERVAL, XX) XX is the number of beacons between each antenna RSSI check. Setting this value to 50 means, every 50 received beacons, run the ADS algorithm. D. WCN36XX_CFG_VAL(ASD_TRIGGER_THRESHOLD, YY) YY is a two's complement integer which specifies the RSSI decibel threshold below which ADS will run. We default to -60db here, meaning a measured RSSI <= -60db will trigger an ADS probe. E. WCN36XX_CFG_VAL(ASD_RTT_RSSI_HYST_THRESHOLD, Z) Z is a hysteresis value, indicating a delta which the RSSI must exceed for the antenna switch to be valid. For example if HYST_THRESHOLD == 3 AntennaId1-RSSI == -60db and AntennaId-2-RSSI == -58db then firmware will not switch antenna. The threshold needs to be -57db or better to satisfy the criteria. F. A firmware feature bit also exists ANTENNA_DIVERSITY_SELECTION. This feature bit is used by the firmware to report if ANTENNA_DIVERSITY_SELECTION is supported. The host is not required to toggle this bit to enable or disable ADS. ADS works like this: A. Every XX beacons the firmware switches to or remains on the primary antenna. B. The firmware then sends a Request-To-Send (RTS) packet to the AP. C. The firmware waits for a Clear-To-Send (CTS) response from the AP. D. The firmware then notes the received RSSI on the CTS packet. E. The firmware then repeats steps A-D on the secondary antenna. F. Subsequently if the RSSI on the measured antenna is better than ASD_TRIGGER_THRESHOLD + the active antenna's RSSI then the measured antenna becomes the active antenna. G. If RSSI rises past ASD_TRIGGER_THRESHOLD then ADS doesn't run at all even if there is a substantially better RSSI on the alternative antenna. What we have been observing is that the RTS packet is being sent but the MAC address is a byte-swapped version of the target MAC. The ADS/RTS MAC is corrupted only when the link is encrypted, if the AP is open the RTS MAC is correct. Similarly if we configure the firmware to an RTS/CTS sequence for regular data - the transmitted RTS MAC is correctly formatted. Internally the wcn36xx firmware uses the indexes in the SMD commands to populate and extract data from specific entries in an STA lookup table. The AP's MAC appears a number of times in different indexes within this lookup table, so the MAC address extracted for the data-transmit RTS and the MAC address extracted for the ADS/RTS packet are not the same STA table index. Our analysis indicates the relevant firmware STA table index is "bssSelfStaIdx". There is an STA populate function responsible for formatting the MAC address of the bssSelfStaIdx including byte-swapping the MAC address. Its clear then that the required STA populate command did not run for bssSelfStaIdx. So taking a look at the sequence of SMD commands sent to the firmware we see the following downstream when moving from an unencrypted to encrypted BSS setup. - WLAN_HAL_CONFIG_BSS_REQ - WLAN_HAL_CONFIG_STA_REQ - WLAN_HAL_SET_STAKEY_REQ Upstream in wcn36xx we have - WLAN_HAL_CONFIG_BSS_REQ - WLAN_HAL_SET_STAKEY_REQ The solution then is to add the missing WLAN_HAL_CONFIG_STA_REQ between WLAN_HAL_CONFIG_BSS_REQ and WLAN_HAL_SET_STAKEY_REQ. No surprise WLAN_HAL_CONFIG_STA_REQ is the routine responsible for populating the STA lookup table in the firmware and once done the MAC sent by the ADS routine is in the correct byte-order. This bug is apparent with ADS but it is also the case that any other firmware routine that depends on the "bssSelfStaIdx" would retrieve malformed data on an encrypted link. Fixes: 3e977c5c ("wcn36xx: Define wcn3680 specific firmware parameters") Signed-off-by:
-
