summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/ath
AgeCommit message (Collapse)AuthorFilesLines
2022-01-16ath11k: Fix buffer overflow when scanning with extraieSven Eckelmann1-3/+3
commit a658c929ded7ea3aee324c8c2a9635a5e5a38e7f upstream. If cfg80211 is providing extraie's for a scanning process then ath11k will copy that over to the firmware. The extraie.len is a 32 bit value in struct element_info and describes the amount of bytes for the vendor information elements. The WMI_TLV packet is having a special WMI_TAG_ARRAY_BYTE section. This section can have a (payload) length up to 65535 bytes because the WMI_TLV_LEN can store up to 16 bits. The code was missing such a check and could have created a scan request which cannot be parsed correctly by the firmware. But the bigger problem was the allocation of the buffer. It has to align the TLV sections by 4 bytes. But the code was using an u8 to store the newly calculated length of this section (with alignment). And the new calculated length was then used to allocate the skbuff. But the actual code to copy in the data is using the extraie.len and not the calculated "aligned" length. The length of extraie with IEEE80211_HW_SINGLE_SCAN_ON_ALL_BANDS enabled was 264 bytes during tests with a QCA Milan card. But it only allocated 8 bytes (264 bytes % 256) for it. As consequence, the code to memcpy the extraie into the skb was then just overwriting data after skb->end. Things like shinfo were therefore corrupted. This could usually be seen by a crash in skb_zcopy_clear which tried to call a ubuf_info callback (using a bogus address). Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-02892.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Cc: stable@vger.kernel.org Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211207142913.1734635-1-sven@narfation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18ath10k: fix invalid dma_addr_t token assignmentArnd Bergmann1-1/+9
commit 937e79c67740d1d84736730d679f3cb2552f990e upstream. Using a kernel pointer in place of a dma_addr_t token can lead to undefined behavior if that makes it into cache management functions. The compiler caught one such attempt in a cast: drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_add_interface': drivers/net/wireless/ath/ath10k/mac.c:5586:47: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] 5586 | arvif->beacon_paddr = (dma_addr_t)arvif->beacon_buf; | ^ Looking through how this gets used down the way, I'm fairly sure that beacon_paddr is never accessed again for ATH10K_DEV_TYPE_HL devices, and if it was accessed, that would be a bug. Change the assignment to use a known-invalid address token instead, which avoids the warning and makes it easier to catch bugs if it does end up getting used. Fixes: e263bdab9c0e ("ath10k: high latency fixes for beacon buffer") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211014075153.3655910-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18wcn36xx: Fix discarded frames due to wrong sequence numberLoic Poulain1-2/+7
[ Upstream commit 113f304dbc1627c6ec9d5329d839964095768980 ] The firmware is offering features such as ARP offload, for which firmware crafts its own (QoS)packets without waking up the host. Point is that the sequence numbers generated by the firmware are not in sync with the host mac80211 layer and can cause packets such as firmware ARP reponses to be dropped by the AP (too old SN). To fix this we need to let the firmware manages the sequence numbers by its own (except for QoS null frames). There is a SN counter for each QoS queue and one global/baseline counter for Non-QoS. Fixes: 84aff52e4f57 ("wcn36xx: Use sequence number allocated by mac80211") Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1635150336-18736-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18wcn36xx: add proper DMA memory barriers in rx pathBenjamin Li1-1/+11
[ Upstream commit 9bfe38e064af5decba2ffce66a2958ab8b10eaa4 ] This is essentially exactly following the dma_wmb()/dma_rmb() usage instructions in Documentation/memory-barriers.txt. The theoretical races here are: 1. DXE (the DMA Transfer Engine in the Wi-Fi subsystem) seeing the dxe->ctrl & WCN36xx_DXE_CTRL_VLD write before the dxe->dst_addr_l write, thus performing DMA into the wrong address. 2. CPU reading dxe->dst_addr_l before DXE unsets dxe->ctrl & WCN36xx_DXE_CTRL_VLD. This should generally be harmless since DXE doesn't write dxe->dst_addr_l (no risk of freeing the wrong skb). Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Benjamin Li <benl@squareup.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211023001528.3077822-1-benl@squareup.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ath10k: fix max antenna gain unitSven Eckelmann2-3/+6
[ Upstream commit 0a491167fe0cf9f26062462de2a8688b96125d48 ] Most of the txpower for the ath10k firmware is stored as twicepower (0.5 dB steps). This isn't the case for max_antenna_gain - which is still expected by the firmware as dB. The firmware is converting it from dB to the internal (twicepower) representation when it calculates the limits of a channel. This can be seen in tpc_stats when configuring "12" as max_antenna_gain. Instead of the expected 12 (6 dB), the tpc_stats shows 24 (12 dB). Tested on QCA9888 and IPQ4019 with firmware 10.4-3.5.3-00057. Fixes: 02256930d9b8 ("ath10k: use proper tx power unit") Signed-off-by: Sven Eckelmann <seckelmann@datto.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20190611172131.6064-1-sven@narfation.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ath9k: Fix potential interrupt storm on queue resetLinus Lüssing1-1/+3
[ Upstream commit 4925642d541278575ad1948c5924d71ffd57ef14 ] 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: 872b5d814f99 ("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 Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ath10k: sdio: Add missing BH locking around napi_schdule()Fabio Estevam1-1/+4
[ Upstream commit 019edd01d174ce4bb2e517dd332922514d176601 ] 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 e63052a5dd3c ("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: cfee8793a74d ("ath10k: enable napi on RX path for sdio") Signed-off-by: Fabio Estevam <festevam@denx.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210824144339.2796122-1-festevam@denx.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ath10k: Fix missing frame timestamp for beacon/probe-respLoic Poulain1-0/+4
[ Upstream commit e6dfbc3ba90cc2b619229be56b485f085a0a8e1c ] 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: 5e3dd157d7e7 ("ath10k: mac80211 driver for Qualcomm Atheros 802.11ac CQA98xx devices") Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1629811733-7927-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ath11k: Fix memory leak in ath11k_qmi_driver_event_workBaochen Qiang1-1/+3
[ Upstream commit 72de799aa9e3e064b35238ef053d2f0a49db055a ] 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: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Baochen Qiang <bqiang@codeaurora.org> Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210913180246.193388-4-jouni@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ath11k: fix packet drops due to incorrect 6 GHz freq value in rx statusPradeep Kumar Chitrapu2-6/+13
[ Upstream commit 9d6ae1f5cf733c0e8d7f904c501fd015c4b9f0f4 ] 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: 5dcf42f8b79d ("ath11k: Use freq instead of channel number in rx path") Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210722102054.43419-2-jouni@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ath11k: Avoid race during regd updatesSriram R4-17/+14
[ Upstream commit 1db2b0d0a39102238fcbf9092cefa65a710642e9 ] 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: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Sriram R <srirrama@codeaurora.org> Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210721212029.142388-4-jouni@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ath11k: fix some sleeping in atomic bugsDan Carpenter1-9/+7
[ Upstream commit aadf7c81a0771b8f1c97dabca6a48bae1b387779 ] 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: bd6478559e27 ("ath11k: Add direct buffer ring support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210812070434.GE31863@kili Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18wcn36xx: Fix Antenna Diversity SwitchingBryan O'Donoghue1-1/+3
[ Upstream commit 701668d3bfa03dabc5095fc383d5315544ee5b31 ] 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: 3e977c5c523d ("wcn36xx: Define wcn3680 specific firmware parameters") Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Benjamin Li <benl@squareup.com> Reviewed-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210909144428.2564650-2-bryan.odonoghue@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18wcn36xx: Correct band/freq reporting on RXLoic Poulain2-1/+25
[ Upstream commit 8a27ca39478270e07baf9c09aa0c99709769ba03 ] For packets originating from hardware scan, the channel and band is included in the buffer descriptor (bd->rf_band & bd->rx_ch). For 2Ghz band the channel value is directly reported in the 4-bit rx_ch field. For 5Ghz band, the rx_ch field contains a mapping index (given the 4-bit limitation). The reserved0 value field is also used to extend 4-bit mapping to 5-bit mapping to support more than 16 5Ghz channels. This change adds correct reporting of the frequency/band, that is used in scan mechanism. And is required for 5Ghz hardware scan support. Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1634554678-7993-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ath: dfs_pattern_detector: Fix possible null-pointer dereference in ↵Tuo Li1-4/+6
channel_detector_create() [ Upstream commit 4b6012a7830b813799a7faf40daa02a837e0fd5b ] kzalloc() is used to allocate memory for cd->detectors, and if it fails, channel_detector_exit() behind the label fail will be called: channel_detector_exit(dpd, cd); In channel_detector_exit(), cd->detectors is dereferenced through: struct pri_detector *de = cd->detectors[i]; To fix this possible null-pointer dereference, check cd->detectors before the for loop to dereference cd->detectors. Reported-by: TOTE Robot <oslab@tsinghua.edu.cn> Signed-off-by: Tuo Li <islituo@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210805153854.154066-1-islituo@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ath10k: high latency fixes for beacon bufferAlagu Sankar1-8/+23
[ Upstream commit e263bdab9c0e8025fb7f41f153709a9cda51f6b6 ] 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: Fabio Estevam <festevam@denx.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210818232627.2040121-1-festevam@denx.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ath11k: Change DMA_FROM_DEVICE to DMA_TO_DEVICE when map reinjected packetsBaochen Qiang1-2/+2
[ Upstream commit 86a03dad0f5ad8182ed5fcf7bf3eec71cd96577c ] 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: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210916064617.20006-1-bqiang@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ath11k: add handler for scan event WMI_SCAN_EVENT_DEQUEUEDWen Gong1-0/+2
[ Upstream commit 441b3b5911f8ead7f2fe2336587b340a33044d58 ] 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: Wen Gong <wgong@codeaurora.org> Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914164226.38843-1-jouni@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ath11k: Avoid reg rules update during firmware recoverySriram R1-0/+11
[ Upstream commit 69a0fcf8a9f2273040d03e5ee77c9689c09e9d3a ] 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 <srirrama@codeaurora.org> Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210721212029.142388-3-jouni@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ath11k: Align bss_chan_info structure with firmwareSeevalamuthu Mariappan2-1/+3
[ Upstream commit feab5bb8f1d4621025dceae7eef62d5f92de34ac ] pdev_id in structure 'wmi_pdev_bss_chan_info_event' is wrongly placed at the beginning. This causes invalid values in survey dump. Hence, align the structure with the firmware. Note: The firmware releases follow this order since the feature was implemented. Also, it is not changing across the branches including QCA6390. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.1.0.1-01228-QCAHKSWPL_SILICONZ-1 Signed-off-by: Ritesh Singh <ritesi@codeaurora.org> 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/20210720214922.118078-3-jouni@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18wcn36xx: handle connection loss indicationBenjamin Li1-11/+33
commit d6dbce453b19c64b96f3e927b10230f9a704b504 upstream. Firmware sends delete_sta_context_ind when it detects the AP has gone away in STA mode. Right now the handler for that indication only handles AP mode; fix it to also handle STA mode. Cc: stable@vger.kernel.org Signed-off-by: Benjamin Li <benl@squareup.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210901180606.11686-1-benl@squareup.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18wcn36xx: Fix (QoS) null data frame bitrate/modulationLoic Poulain1-0/+1
commit d3fd2c95c1c13ec217d43ebef3c61cfa00a6cd37 upstream. We observe unexpected connection drops with some APs due to non-acked mac80211 generated null data frames (keep-alive). After debugging and capture, we noticed that null frames are submitted at standard data bitrate and that the given APs are in trouble with that. After setting the null frame bitrate to control bitrate, all null frames are acked as expected and connection is maintained. Not sure if it's a requirement of the specification, but it seems the right thing to do anyway, null frames are mostly used for control purpose (power-saving, keep-alive...), and submitting them with a slower/simpler bitrate/modulation is more robust. Cc: stable@vger.kernel.org Fixes: 512b191d9652 ("wcn36xx: Fix TX data path") Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1634560399-15290-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18wcn36xx: Fix tx_status mechanismLoic Poulain2-47/+21
commit a9e79b116cc4d0057e912be8f40b2c2e5bdc7c43 upstream. This change fix the TX ack mechanism in various ways: - For NO_ACK tagged packets, we don't need to wait for TX_ACK indication and so are not subject to the single packet ack limitation. So we don't have to stop the tx queue, and can call the tx status callback as soon as DMA transfer has completed. - Fix skb ownership/reference. Only start status indication timeout once the DMA transfer has been completed. This avoids the skb to be both referenced in the DMA tx ring and by the tx_ack_skb pointer, preventing any use-after-free or double-free. - This adds a sanity (paranoia?) check on the skb tx ack pointer. - Resume TX queue if TX status tagged packet TX fails. Cc: stable@vger.kernel.org Fixes: fdf21cc37149 ("wcn36xx: Add TX ack support") Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1634567281-28997-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18wcn36xx: Fix HT40 capability for 2Ghz bandLoic Poulain1-1/+3
commit 960ae77f25631bbe4e3aafefe209b52e044baf31 upstream. All wcn36xx controllers are supposed to support HT40 (and SGI40), This doubles the maximum bitrate/throughput with compatible APs. Tested with wcn3620 & wcn3680B. Cc: stable@vger.kernel.org Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1634737133-22336-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18ath10k: fix division by zero in send pathJohan Hovold1-0/+5
commit a006acb931317aad3a8dd41333ebb0453caf49b8 upstream. Add the missing endpoint max-packet sanity check to probe() to avoid division by zero in ath10k_usb_hif_tx_sg() in case a malicious device has broken descriptors (or when doing descriptor fuzz testing). Note that USB core will reject URBs submitted for endpoints with zero wMaxPacketSize but that drivers doing packet-size calculations still need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip endpoint descriptors with maxpacket=0")). Fixes: 4db66499df91 ("ath10k: add initial USB support") Cc: stable@vger.kernel.org # 4.14 Cc: Erik Stromdahl <erik.stromdahl@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211027080819.6675-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18ath10k: fix control-message timeoutJohan Hovold1-1/+1
commit 5286132324230168d3fab6ffc16bfd7de85bdfb4 upstream. USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 4db66499df91 ("ath10k: add initial USB support") Cc: stable@vger.kernel.org # 4.14 Cc: Erik Stromdahl <erik.stromdahl@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211025120522.6045-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18ath6kl: fix control-message timeoutJohan Hovold1-1/+1
commit a066d28a7e729f808a3e6eff22e70c003091544e upstream. USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 241b128b6b69 ("ath6kl: add back beginnings of USB support") Cc: stable@vger.kernel.org # 3.4 Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211025120522.6045-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18ath6kl: fix division by zero in send pathJohan Hovold1-0/+5
commit c1b9ca365deae667192be9fe24db244919971234 upstream. Add the missing endpoint max-packet sanity check to probe() to avoid division by zero in ath10k_usb_hif_tx_sg() in case a malicious device has broken descriptors (or when doing descriptor fuzz testing). Note that USB core will reject URBs submitted for endpoints with zero wMaxPacketSize but that drivers doing packet-size calculations still need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip endpoint descriptors with maxpacket=0")). Fixes: 9cbee358687e ("ath6kl: add full USB support") Cc: stable@vger.kernel.org # 3.5 Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211027080819.6675-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-06Revert "wcn36xx: Disable bmps when encryption is disabled"Bryan O'Donoghue3-15/+1
commit 285bb1738e196507bf985574d0bc1e9dd72d46b1 upstream. This reverts commit c6522a5076e1a65877c51cfee313a74ef61cabf8. Testing on tip-of-tree shows that this is working now. Revert this and re-enable BMPS for Open APs. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211022140447.2846248-3-bryan.odonoghue@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-13ath5k: fix building with LEDS=mArnd Bergmann2-7/+7
[ Upstream commit fb8c3a3c52400512fc8b3b61150057b888c30b0d ] Randconfig builds still show a failure for the ath5k driver, similar to the one that was fixed for ath9k earlier: WARNING: unmet direct dependencies detected for MAC80211_LEDS Depends on [n]: NET [=y] && WIRELESS [=y] && MAC80211 [=y] && (LEDS_CLASS [=m]=y || LEDS_CLASS [=m]=MAC80211 [=y]) Selected by [m]: - ATH5K [=m] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_ATH [=y] && (PCI [=y] || ATH25) && MAC80211 [=y] net/mac80211/led.c: In function 'ieee80211_alloc_led_names': net/mac80211/led.c:34:22: error: 'struct led_trigger' has no member named 'name' 34 | local->rx_led.name = kasprintf(GFP_KERNEL, "%srx", | ^ Copying the same logic from my ath9k patch makes this one work as well, stubbing out the calls to the LED subsystem. Fixes: b64acb28da83 ("ath9k: fix build error with LEDS_CLASS=m") Fixes: 72cdab808714 ("ath9k: Do not select MAC80211_LEDS by default") Fixes: 3a078876caee ("ath5k: convert LED code to use mac80211 triggers") Link: https://lore.kernel.org/all/20210722105501.1000781-1-arnd@kernel.org/ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210920122359.353810-1-arnd@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-18ath9k: fix sleeping in atomic contextMiaoqing Pan1-5/+7
[ Upstream commit 7c48662b9d56666219f526a71ace8c15e6e12f1f ] The problem is that gpio_free() can sleep and the cfg_soc() can be called with spinlocks held. One problematic call tree is: --> ath_reset_internal() takes &sc->sc_pcu_lock spin lock --> ath9k_hw_reset() --> ath9k_hw_gpio_request_in() --> ath9k_hw_gpio_request() --> ath9k_hw_gpio_cfg_soc() Remove gpio_free(), use error message instead, so we should make sure there is no GPIO conflict. Also remove ath9k_hw_gpio_free() from ath9k_hw_apply_gpio_override(), as gpio_mask will never be set for SOC chips. Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1628481916-15030-1-git-send-email-miaoqing@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-18ath9k: fix OOB read ar9300_eeprom_restore_internalZekun Shen1-1/+2
[ Upstream commit 23151b9ae79e3bc4f6a0c4cd3a7f355f68dad128 ] Bad header can have large length field which can cause OOB. cptr is the last bytes for read, and the eeprom is parsed from high to low address. The OOB, triggered by the condition length > cptr could cause memory error with a read on negative index. There are some sanity check around length, but it is not compared with cptr (the remaining bytes). Here, the corrupted/bad EEPROM can cause panic. I was able to reproduce the crash, but I cannot find the log and the reproducer now. After I applied the patch, the bug is no longer reproducible. Signed-off-by: Zekun Shen <bruceshenzk@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/YM3xKsQJ0Hw2hjrc@Zekuns-MBP-16.fios-router.home Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-18wcn36xx: Fix missing frame timestamp for beacon/probe-respLoic Poulain1-0/+4
[ Upstream commit 8678fd31f2d3eb14f2b8b39c9bc266f16fa24b22 ] 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). Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1629992768-23785-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-18wcn36xx: Ensure finish scan is not requested before start scanJoseph Gates2-1/+5
commit d195d7aac09bddabc2c8326fb02fcec2b0a2de02 upstream. If the operating channel is the first in the scan list, it was seen that a finish scan request would be sent before a start scan request was sent, causing the firmware to fail all future scans. Track the current channel being scanned to avoid requesting the scan finish before it starts. Cc: <stable@vger.kernel.org> Fixes: 5973a2947430 ("wcn36xx: Fix software-driven scan") Signed-off-by: Joseph Gates <jgates@squareup.com> Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1629286303-13179-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-15ath6kl: wmi: fix an error code in ath6kl_wmi_sync_point()Dan Carpenter1-1/+3
[ Upstream commit fd6729ec534cffbbeb3917761e6d1fe6a412d3fe ] This error path is unlikely because of it checked for NULL and returned -ENOMEM earlier in the function. But it should return an error code here as well if we ever do hit it because of a race condition or something. Fixes: bdcd81707973 ("Add ath6kl cleaned up driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210813113438.GB30697@kili Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-08-26ath9k: Postpone key cache entry deletion for TXQ frames reference itJouni Malinen2-1/+87
commit ca2848022c12789685d3fab3227df02b863f9696 upstream. Do not delete a key cache entry that is still being referenced by pending frames in TXQs. This avoids reuse of the key cache entry while a frame might still be transmitted using it. To avoid having to do any additional operations during the main TX path operations, track pending key cache entries in a new bitmap and check whether any pending entries can be deleted before every new key add/remove operation. Also clear any remaining entries when stopping the interface. Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201214172118.18100-6-jouni@codeaurora.org Cc: Pali Rohár <pali@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26ath: Modify ath_key_delete() to not need full key entryJouni Malinen5-23/+22
commit 144cd24dbc36650a51f7fe3bf1424a1432f1f480 upstream. tkip_keymap can be used internally to avoid the reference to key->cipher and with this, only the key index value itself is needed. This allows ath_key_delete() call to be postponed to be handled after the upper layer STA and key entry have already been removed. This is needed to make ath9k key cache management safer. Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201214172118.18100-5-jouni@codeaurora.org Cc: Pali Rohár <pali@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26ath: Export ath_hw_keysetmac()Jouni Malinen2-2/+3
commit d2d3e36498dd8e0c83ea99861fac5cf9e8671226 upstream. ath9k is going to use this for safer management of key cache entries. Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201214172118.18100-4-jouni@codeaurora.org Cc: Pali Rohár <pali@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26ath9k: Clear key cache explicitly on disabling hardwareJouni Malinen1-0/+5
commit 73488cb2fa3bb1ef9f6cf0d757f76958bd4deaca upstream. Now that ath/key.c may not be explicitly clearing keys from the key cache, clear all key cache entries when disabling hardware to make sure no keys are left behind beyond this point. Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201214172118.18100-3-jouni@codeaurora.org Cc: Pali Rohár <pali@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26ath: Use safer key clearing with key cache entriesJouni Malinen1-1/+10
commit 56c5485c9e444c2e85e11694b6c44f1338fc20fd upstream. It is possible for there to be pending frames in TXQs with a reference to the key cache entry that is being deleted. If such a key cache entry is cleared, those pending frame in TXQ might get transmitted without proper encryption. It is safer to leave the previously used key into the key cache in such cases. Instead, only clear the MAC address to prevent RX processing from using this key cache entry. This is needed in particularly in AP mode where the TXQs cannot be flushed on station disconnection. This change alone may not be able to address all cases where the key cache entry might get reused for other purposes immediately (the key cache entry should be released for reuse only once the TXQs do not have any remaining references to them), but this makes it less likely to get unprotected frames and the more complete changes may end up being significantly more complex. Signed-off-by: Jouni Malinen <jouni@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201214172118.18100-2-jouni@codeaurora.org Cc: Pali Rohár <pali@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-19ath11k: unlock on error path in ath11k_mac_op_add_interface()Dan Carpenter1-2/+2
commit 59ec8e2fa5aaed6afd18d5362dc131aab92406e7 upstream. These error paths need to drop the &ar->conf_mutex before returning. Fixes: 690ace20ff79 ("ath11k: peer delete synchronization with firmware") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/X85sVGVP/0XvlrEJ@mwanda Signed-off-by: Nobuhiro Iwamatsu (CIP) <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-14ath11k: send beacon template after vdev_start/restart during csaSeevalamuthu Mariappan1-5/+5
[ Upstream commit 979ebc54cf13bd1e3eb6e21766d208d5de984fb8 ] Firmware has added assert if beacon template is received after vdev_down. Firmware expects beacon template after vdev_start and before vdev_up. This change is needed to support MBSSID EMA cases in firmware. Hence, Change the sequence in ath11k as expected from firmware. This new change is not causing any issues with older firmware. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1.r3-00011-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1.r4-00008-QCAHKSWPL_SILICONZ-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Seevalamuthu Mariappan <seevalam@codeaurora.org> [sven@narfation.org: added tested-on/fixes information] Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210525133028.2805615-1-sven@narfation.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14ath10k: Fix an error code in ath10k_add_interface()Yang Li1-0/+1
[ Upstream commit e9ca70c735ce66fc6a0e02c8b6958434f74ef8de ] When the code execute this if statement, the value of ret is 0. However, we can see from the ath10k_warn() log that the value of ret should be -EINVAL. Clean up smatch warning: drivers/net/wireless/ath/ath10k/mac.c:5596 ath10k_add_interface() warn: missing error code 'ret' Reported-by: Abaci Robot <abaci@linux.alibaba.com> Fixes: ccec9038c721 ("ath10k: enable raw encap mode and software crypto engine") Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1621939577-62218-1-git-send-email-yang.lee@linux.alibaba.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14ath11k: Fix an error handling path in ath11k_core_fetch_board_data_api_n()Christophe JAILLET1-1/+2
[ Upstream commit 515bda1d1e51c64edf2a384a58801f85a80a3f2d ] All error paths but this one 'goto err' in order to release some resources. Fix this. Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/e959eb544f3cb04258507d8e25a6f12eab126bde.1621676864.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14wcn36xx: Move hal_buf allocation to devm_kmalloc in probeBryan O'Donoghue1-13/+8
[ Upstream commit ef48667557c53d4b51a1ee3090eab7699324c9de ] Right now wcn->hal_buf is allocated in wcn36xx_start(). This is a problem since we should have setup all of the buffers we required by the time ieee80211_register_hw() is called. struct ieee80211_ops callbacks may run prior to mac_start() and therefore wcn->hal_buf must be initialized. This is easily remediated by moving the allocation to probe() taking the opportunity to tidy up freeing memory by using devm_kmalloc(). Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210605173347.2266003-1-bryan.odonoghue@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14wireless: carl9170: fix LEDS build errors & warningsRandy Dunlap1-5/+3
[ Upstream commit 272fdc0c4542fad173b44965be02a16d6db95499 ] kernel test robot reports over 200 build errors and warnings that are due to this Kconfig problem when CARL9170=m, MAC80211=y, and LEDS_CLASS=m. WARNING: unmet direct dependencies detected for MAC80211_LEDS Depends on [n]: NET [=y] && WIRELESS [=y] && MAC80211 [=y] && (LEDS_CLASS [=m]=y || LEDS_CLASS [=m]=MAC80211 [=y]) Selected by [m]: - CARL9170_LEDS [=y] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_ATH [=y] && CARL9170 [=m] CARL9170_LEDS selects MAC80211_LEDS even though its kconfig dependencies are not met. This happens because 'select' does not follow any Kconfig dependency chains. Fix this by making CARL9170_LEDS depend on MAC80211_LEDS, where the latter supplies any needed dependencies on LEDS_CLASS. Fixes: 1d7e1e6b1b8ed ("carl9170: Makefile, Kconfig files and MAINTAINERS") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: Christian Lamparter <chunkeey@googlemail.com> Cc: linux-wireless@vger.kernel.org Cc: Arnd Bergmann <arnd@arndb.de> Suggested-by: Christian Lamparter <chunkeey@googlemail.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210530031134.23274-1-rdunlap@infradead.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14ath10k: add missing error return code in ath10k_pci_probe()Yang Yingliang1-3/+9
[ Upstream commit e2783e2f39ba99178dedfc1646d5cc0979d1bab3 ] When chip_id is not supported, the resources will be freed on path err_unsupported, these resources will also be freed when calling ath10k_pci_remove(), it will cause double free, so return -ENODEV when it doesn't support the device with wrong chip_id. Fixes: c0c378f9907c ("ath10k: remove target soc ps code") Fixes: 7505f7c3ec1d ("ath10k: create a chip revision whitelist") Fixes: f8914a14623a ("ath10k: restore QCA9880-AR1A (v1) detection") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210522105822.1091848-3-yangyingliang@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14ath10k: go to path err_unsupported when chip id is not supportedYang Yingliang1-1/+1
[ Upstream commit 9e88dd431d2345acdb7a549f3e88aaf4c2a307a1 ] When chip id is not supported, it go to path err_unsupported to print the error message. Fixes: f8914a14623a ("ath10k: restore QCA9880-AR1A (v1) detection") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210522105822.1091848-2-yangyingliang@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14ath9k: Fix kernel NULL pointer dereference during ath_reset_internal()Pali Rohár1-0/+5
commit fb312ac5ccb007e843f982b38d4d6886ba4b32f2 upstream. I got this crash more times during debugging of PCIe controller and crash happens somehow at the time when PCIe kernel code started link retraining (as part of ASPM code) when at the same time PCIe link went down and ath9k probably executed hw reset procedure. Currently I'm not able to reproduce this issue as it looks like to be some race condition between link training, ASPM, link down and reset path. And as always, race conditions which depends on more input parameters are hard to reproduce as it depends on precise timings. But it is clear that pointers are zero in this case and should be properly filled as same code pattern is used in ath9k_stop() function. Anyway I was able to reproduce this crash by manually triggering ath reset worker prior putting card up. I created simple patch to export reset functionality via debugfs and use it to "simulate" of triggering reset. s proved that NULL-pointer dereference issue is there. Function ath9k_hw_reset() is dereferencing chan structure pointer, so it needs to be non-NULL pointer. Function ath9k_stop() already contains code which sets ah->curchan to valid non-NULL pointer prior calling ath9k_hw_reset() function. Add same code pattern also into ath_reset_internal() function to prevent kernel NULL pointer dereference in ath9k_hw_reset() function. This change fixes kernel NULL pointer dereference in ath9k_hw_reset() which is caused by calling ath9k_hw_reset() from ath_reset_internal() with NULL chan structure. [ 45.334305] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 [ 45.344417] Mem abort info: [ 45.347301] ESR = 0x96000005 [ 45.350448] EC = 0x25: DABT (current EL), IL = 32 bits [ 45.356166] SET = 0, FnV = 0 [ 45.359350] EA = 0, S1PTW = 0 [ 45.362596] Data abort info: [ 45.365756] ISV = 0, ISS = 0x00000005 [ 45.369735] CM = 0, WnR = 0 [ 45.372814] user pgtable: 4k pages, 39-bit VAs, pgdp=000000000685d000 [ 45.379663] [0000000000000008] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 45.388856] Internal error: Oops: 96000005 [#1] SMP [ 45.393897] Modules linked in: ath9k ath9k_common ath9k_hw [ 45.399574] CPU: 1 PID: 309 Comm: kworker/u4:2 Not tainted 5.12.0-rc2-dirty #785 [ 45.414746] Workqueue: phy0 ath_reset_work [ath9k] [ 45.419713] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--) [ 45.425910] pc : ath9k_hw_reset+0xc4/0x1c48 [ath9k_hw] [ 45.431234] lr : ath9k_hw_reset+0xc0/0x1c48 [ath9k_hw] [ 45.436548] sp : ffffffc0118dbca0 [ 45.439961] x29: ffffffc0118dbca0 x28: 0000000000000000 [ 45.445442] x27: ffffff800dee4080 x26: 0000000000000000 [ 45.450923] x25: ffffff800df9b9d8 x24: 0000000000000000 [ 45.456404] x23: ffffffc0115f6000 x22: ffffffc008d0d408 [ 45.461885] x21: ffffff800dee5080 x20: ffffff800df9b9d8 [ 45.467366] x19: 0000000000000000 x18: 0000000000000000 [ 45.472846] x17: 0000000000000000 x16: 0000000000000000 [ 45.478326] x15: 0000000000000010 x14: ffffffffffffffff [ 45.483807] x13: ffffffc0918db94f x12: ffffffc011498720 [ 45.489289] x11: 0000000000000003 x10: ffffffc0114806e0 [ 45.494770] x9 : ffffffc01014b2ec x8 : 0000000000017fe8 [ 45.500251] x7 : c0000000ffffefff x6 : 0000000000000001 [ 45.505733] x5 : 0000000000000000 x4 : 0000000000000000 [ 45.511213] x3 : 0000000000000000 x2 : ffffff801fece870 [ 45.516693] x1 : ffffffc00eded000 x0 : 000000000000003f [ 45.522174] Call trace: [ 45.524695] ath9k_hw_reset+0xc4/0x1c48 [ath9k_hw] [ 45.529653] ath_reset_internal+0x1a8/0x2b8 [ath9k] [ 45.534696] ath_reset_work+0x2c/0x40 [ath9k] [ 45.539198] process_one_work+0x210/0x480 [ 45.543339] worker_thread+0x5c/0x510 [ 45.547115] kthread+0x12c/0x130 [ 45.550445] ret_from_fork+0x10/0x1c [ 45.554138] Code: 910922c2 9117e021 95ff0398 b4000294 (b9400a61) [ 45.560430] ---[ end trace 566410ba90b50e8b ]--- [ 45.565193] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 45.572282] SMP: stopping secondary CPUs [ 45.576331] Kernel Offset: disabled [ 45.579924] CPU features: 0x00040002,0000200c [ 45.584416] Memory Limit: none [ 45.587564] Rebooting in 3 seconds.. Signed-off-by: Pali Rohár <pali@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210402122653.24014-1-pali@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-03ath6kl: return error code in ath6kl_wmi_set_roam_lrssi_cmd()Anirudh Rayabharam2-4/+5
[ Upstream commit 54433367840b46a1555c8ed36c4c0cfc5dbf1358 ] Propagate error code from failure of ath6kl_wmi_cmd_send() to the caller. Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com> Cc: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210503115736.2104747-44-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>