- 05 Oct, 2021 9 commits
-
-
Linus Lüssing authored
In tests with two Lima boards from 8devices (QCA4531 based) on OpenWrt 19.07 we could force a silent restart of a device with no serial output when we were sending a high amount of UDP traffic (iperf3 at 80 MBit/s in both directions from external hosts, saturating the wifi and causing a load of about 4.5 to 6) and were then triggering an ath9k_queue_reset(). Further debugging showed that the restart was caused by the ath79 watchdog. With disabled watchdog we could observe that the device was constantly going into ath_isr() interrupt handler and was returning early after the ATH_OP_HW_RESET flag test, without clearing any interrupts. Even though ath9k_queue_reset() calls ath9k_hw_kill_interrupts(). With JTAG we could observe the following race condition: 1) ath9k_queue_reset() ... -> ath9k_hw_kill_interrupts() -> set_bit(ATH_OP_HW_RESET, &common->op_flags); ... <- returns 2) ath9k_tasklet() ... -> ath9k_hw_resume_interrupts() ... <- returns 3) loops around: ... handle_int() -> ath_isr() ... -> if (test_bit(ATH_OP_HW_RESET, &common->op_flags)) return IRQ_HANDLED; x) ath_reset_internal(): => never reached <= And in ath_isr() we would typically see the following interrupts / interrupt causes: * status: 0x00111030 or 0x00110030 * async_cause: 2 (AR_INTR_MAC_IPQ) * sync_cause: 0 So the ath9k_tasklet() reenables the ath9k interrupts through ath9k_hw_resume_interrupts() which ath9k_queue_reset() had just disabled. And ath_isr() then keeps firing because it returns IRQ_HANDLED without actually clearing the interrupt. To fix this IRQ storm also clear/disable the interrupts again when we are in reset state. Cc: Sven Eckelmann <sven@narfation.org> Cc: Simon Wunderlich <sw@simonwunderlich.de> Cc: Linus Lüssing <linus.luessing@c0d3.blue> Fixes: 872b5d81 ("ath9k: do not access hardware on IRQs during reset") Signed-off-by:Linus Lüssing <ll@simonwunderlich.de> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914192515.9273-3-linus.luessing@c0d3.blue
-
Linus Lüssing authored
Sometimes, in yet unknown cases the wifi chip stops working. To allow a watchdog in userspace to easily and quickly reset the wifi chip, add the according functionality to userspace. A reset can then be triggered via: $ echo 1 > /sys/kernel/debug/ieee80211/phy0/ath9k/reset The number of user resets can further be tracked in the row "User reset" in the same file. So far people usually used "iw scan" to fix ath9k chip hangs from userspace. Which triggers the ath9k_queue_reset(), too. The reset file however has the advantage of less overhead, which makes debugging bugs within ath9k_queue_reset() easier. Signed-off-by:
-
Stephen Boyd authored
When rebooting on sc7180 Trogdor devices I see the following crash from the wifi driver. ath10k_snoc 18800000.wifi: firmware crashed! (guid 83493570-29a2-4e98-a83e-70048c47669c) This is because a modem stop event looks just like a firmware crash to the driver, the qmi connection is closed in both cases. Use the qcom ssr notifier block to stop treating the qmi connection close event as a firmware crash signal when the modem hasn't actually crashed. See ath10k_qmi_event_server_exit() for more details. This silences the crash message seen during every reboot. Fixes: 3f14b73c ("ath10k: Enable MSA region dump support for WCN3990") Cc: Youghandhar Chintala <youghand@codeaurora.org> Cc: Abhishek Kumar <kuabhs@chromium.org> Cc: Steev Klimaszewski <steev@kali.org> Cc: Matthias Kaehlcke <mka@chromium.org> Cc: Rakesh Pillai <pillair@codeaurora.org> Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
Rakesh Pillai <pillair@codeaurora.org> Tested-By:
Youghandhar Chintala <youghand@codeaurora.org> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo authored
ath.git patches for v5.16. Major changes: ath9k * load calibration data and pci init values via nvmem subsystem ath11k * include channel rx and tx time in survey dump statistics * support for setting fixed Wi-Fi 6 rates from user space * support for 80P80 and 160 MHz bandwidths * spectral scan support for QCN9074 * support for calibration data files per radio * support for calibration data via eeprom * support for rx decapsulation offload (data frames in 802.3 format) * support channel 2 in 6 GHz band ath10k * include frame time stamp in beacon and probe response frames wcn36xx * enable Idle Mode Power Save (IMPS) to reduce power consumption during idle
-
Chris Chiu authored
According to the Realtek propritary driver and the rtw88 driver, the tx rates of the ack (includes block ack) are initialized with lower tx rates (no HT rates) which is set by the RRSR register value. In real cases, ack rate higher than current tx rate could lead to difficulty for the receiving end to receive management/control frames. The retransmission rate would be higher then expected when the driver is acting as receiver and the RSSI is not good. Cross out higer rates for ack packet before implementing dynamic rrsr configuration like the commit 48308726 ("rtw88: add dynamic rrsr configuration"). Signed-off-by:
Chris Chiu <chris.chiu@canonical.com> Acked-by:
Jes Sorensen <Jes.Sorensen@gmail.com> Signed-off-by:
-
Sohaib Mohamed authored
Do not initialise statics to 0 ERROR found by checkpatch.pl Signed-off-by:
Sohaib Mohamed <sohaib.amhmd@gmail.com> Signed-off-by:
-
Hans de Goede authored
The Cyberbook T116 tablet contains quite generic names in the sys_vendor and product_name DMI strings, without this patch brcmfmac will try to load: "brcmfmac43455-sdio.Default string-Default string.txt" as nvram file which is way too generic. The nvram file shipped on the factory Android image contains the exact same settings as those used on the AcePC T8 mini PC, so point the new DMI nvram filename quirk to the acepc-t8 nvram file. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Zong-Zhe Yang authored
The usage of fw_crash debugfs is to write 1 to it to trigger fw crash simulation and to read from it to check the state. When zero is read, it is supposed to mean fw crash/restart process is done. Then, some test plans can be designed for crash/restart. e.g. step 1. trigger fw crash simulation step 2. poll the state until zero is read step 3. check connection by ping test However, in certain connection cases, triggering fw crash simulation will take a while. If the state is queried too early before restart begins processing, it may mistakenly think restart process has been done. If some tests are started at this time, something unexpected might happen due to the follow-up restart process. To avoid that, let fw_crash also show non-zero when a simulation is still triggering. Signed-off-by:
Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
-
Zong-Zhe Yang authored
When fw fifo dumps, RX clock gating should be disabled to avoid something unexpected. However, the register operation ran into a mistake. So, we fix it. Signed-off-by:
-
- 28 Sep, 2021 31 commits
-
-
Fabio Estevam authored
On a i.MX-based board with a QCA9377 Wifi chip, the following errors are seen after launching the 'hostapd' application: hostapd /etc/wifi.conf Configuration file: /etc/wifi.conf wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! Using interface wlan0 with hwaddr 00:1f:7b:31:04:a0 and ssid "thessid" IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready wlan0: interface state COUNTRY_UPDATE->ENABLED wlan0: AP-ENABLED NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! ... Fix this problem by adding the BH locking around napi-schedule(), in the same way it was done in commit e63052a5 ("mlx5e: add add missing BH locking around napi_schdule()"). Its commit log provides the following explanation: "It's not correct to call napi_schedule() in pure process context. Because we use __raise_softirq_irqoff() we require callers to be in a context which will eventually lead to softirq handling (hardirq, bh disabled, etc.). With code as is users will see: NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! " Fixes: cfee8793 ("ath10k: enable napi on RX path for sdio") Signed-off-by:
Fabio Estevam <festevam@denx.de> Signed-off-by:
-
Loic Poulain authored
When receiving a beacon or probe response, we should update the boottime_ns field which is the timestamp the frame was received at. (cf mac80211.h) This fixes a scanning issue with Android since it relies on this timestamp to determine when the AP has been seen for the last time (via the nl80211 BSS_LAST_SEEN_BOOTTIME parameter). Fixes: 5e3dd157 ("ath10k: mac80211 driver for Qualcomm Atheros 802.11ac CQA98xx devices") Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Signed-off-by:
-
Alagu Sankar authored
Beacon buffer for high latency devices does not use DMA. other similar buffer allocation methods in the driver have already been modified for high latency path. Fix the beacon buffer allocation left out in the earlier high latency changes. Signed-off-by:
Alagu Sankar <alagusankar@silex-india.com> Signed-off-by:
Erik Stromdahl <erik.stromdahl@gmail.com> [fabio: adapt it to use ar->bus_param.dev_type ] Signed-off-by:
-
Baochen Qiang authored
For fragmented packets, ath11k reassembles each fragment as a normal packet and then reinjects it into HW ring. In this case, the DMA direction should be DMA_TO_DEVICE, not DMA_FROM_DEVICE, otherwise invalid payload will be reinjected to HW and then delivered to host. What is more, since arbitrary memory could be allocated to the frame, we don't know what kind of data is contained in the buffer reinjected. Thus, as a bad result, private info may be leaked. Note that this issue is only found on Intel platform. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by:
Baochen Qiang <bqiang@codeaurora.org> Signed-off-by:
-
Pradeep Kumar Chitrapu authored
Parse SMPS configuration from IEs and configure. Without this, SMPS is not enabled for 6 GHz band. 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:
Jouni Malinen <jouni@codeaurora.org> Signed-off-by:
-
Pradeep Kumar Chitrapu authored
Currently A-MPDU aggregation parameters are not being configured during peer association for 6 GHz band. Hence, extract these parameters from station's capabilities received in association request and send to firmware. Without this, A-MPDU aggregation is not happening in 6 GHz band. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01386-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Pradeep Kumar Chitrapu authored
Add IEEE80211_HE_6GHZ_MAX_AMPDU_FACTOR as per IEEE Std 802.11ax-2021, 9.4.2.263 to use for peer max A-MPDU factor in 6 GHz band. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Wen Gong authored
Scan failure can not be recovered from when running a loop of the following steps: 1. run scan: "iw wlan scan". 2. run command: echo assert > /sys/kernel/debug/ath11k/qca6490\ hw2.0/simulate_fw_crash immediately after step 1. result: scan failed and can not recover even when wlan recovery succeeds: command failed: Device or resource busy (-16) reason: When scan arrives, WMI_START_SCAN_CMDID is sent to the firmware and function ath11k_mac_op_hw_scan() returns, then simulate_fw_crash arrives and the scan started event does not arrive, and then it starts to do recovery of wlan. __ath11k_mac_scan_finish() which is called from ath11k_core_halt() is one step of recovery, it will not call ieee80211_scan_completed() by logic currently because the scan state is ATH11K_SCAN_STARTING. Thus it leads the scan not being completed in mac80211, and leads all consecutive scans failing with -EBUSY in nl80211_trigger_scan even after wlan recovery success. Indicate scan complete with aborted flag to mac80211 for ATH11K_SCAN_STARTING to allow recovery from scan failed with "Device or resource busy (-16)" after wlan recovery. 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
ath11k prints "Received scan event for unknown vdev" when doing the following test: 1. trigger scan 2. wait 0.2 second 3. iw reg set or 11d scan complete from firmware Reason: When iw reg set or 11d scan complete, the new country code will be set to the firmware, and the new regdomain info indicated to ath11k, then the new channel list will be sent to the firmware. The firmware will cancel the current scan after receiving WMI_SCAN_CHAN_LIST_CMDID which is used for the new channel list, and the state of ath11k is ATH11K_SCAN_RUNNING, then ath11k_get_ar_on_scan_abort() returns NULL and ath11k_scan_event() returns at this point and does not indicate scan completion to mac80211. Indicate scan completion to mac80211 and get rid of the "Received scan event for unknown vdev" print for the above case. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by:
-
Wen Gong authored
When wlan interface is up, 11d scan is sent to the firmware, and the firmware needs to spend couple of seconds to complete the 11d scan. If immediately a normal scan from user space arrives to ath11k, then the normal scan request is also sent to the firmware, but the scan started event will be reported to ath11k until the 11d scan complete. When timed out for the scan started in ath11k, ath11k stops the normal scan and the firmware reports WMI_SCAN_EVENT_DEQUEUED to ath11k for the normal scan. ath11k has no handler for the event and then timed out for the scan completed in ath11k_scan_stop(), and ath11k prints the following error message. [ 1491.604750] ath11k_pci 0000:02:00.0: failed to receive scan abort comple: timed out [ 1491.604756] ath11k_pci 0000:02:00.0: failed to stop scan: -110 [ 1491.604758] ath11k_pci 0000:02:00.0: failed to start hw scan: -110 Add a handler for WMI_SCAN_EVENT_DEQUEUED and then complete the scan to get rid of the above error message. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by:
-
Venkateswara Naralasetty authored
Add HTT stats support for, 29-ATH11K_DBG_HTT_EXT_STATS_PEER_CTRL_PATH_TXRX_STATS: Used to dump the control path txrx stats for each connected peer. Usage: echo 29 > /sys/kernel/debug/ieee80211/phyx/ath11k/htt_stats_type cat /sys/kernel/debug/ieee80211/phyx/netdev\:wlan0/stations/ <sta mac>/htt_peer_stats. 31-ATH11K_DBG_HTT_EXT_STATS_PDEV_TX_RATE_TXBF_STATS: Used to dump the per pdev tx rate txbf stats. Usage: echo 31 > /sys/kernel/debug/ieee80211/phyx/ath11k/htt_stats_type cat /sys/kernel/debug/ieee80211/phyx/ath11k/htt_stats 32-ATH11k_DBG_HTT_EXT_STATS_TXBF_OFDMA: Used to dump the TXBF ofdma stats for all ofdma users. Usage: echo 32 > /sys/kernel/debug/ieee80211/phyx/ath11k/htt_stats_type cat /sys/kernel/debug/ieee80211/phyx/ath11k/htt_stats 37-ATH11K_DBG_HTT_EXT_PHY_COUNTERS_AND_PHY_STATS: Used to dump the mac and phy txrx counts and phy stats like per chain rssi and ANI level. Usage: echo 37 > /sys/kernel/debug/ieee80211/phyx/ath11k/htt_stats_type cat /sys/kernel/debug/ieee80211/phyx/ath11k/htt_stats Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-00486-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Venkateswara Naralasetty <vnaralas@codeaurora.org> Signed-off-by:
-
Seevalamuthu Mariappan authored
In debugfs_htt_stats.c, masking and shifting is done to get stats values. Instead use GENMASK and FIELD_GET to improve code readability and maintenance. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01105-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Seevalamuthu Mariappan <seevalam@codeaurora.org> Signed-off-by:
-
Seevalamuthu Mariappan authored
To support the HTT Stats DebugFS interface a single large buffer that contains the stats must be provided to the DebugFS infrastructure. In the current code, for each class of stats, the stats are first formatted in a local on-stack buffer, and then the local buffer is copied to the large DebugFS buffer. This logic has a problem when, for a given class, the formatted stats exceed the size of the on-stack buffer. When this occurs the stats for this class is truncated. In addition, this logic is inefficient since it introduces an unnecessary memory copy. To address these issues, update the logic to no longer use a local on-stack buffer, and instead write the formatted data directly into the large DebugFS buffer. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01105-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Seevalamuthu Mariappan authored
Get rid of macro HTT_DBG_OUT and replace it with scnprintf(). The macro does not do anything else. Added required new line characters to scnprintf() for proper display. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01105-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
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:
-
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 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 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 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:
-
