aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/wireless/ath/ath10k/mac.c
AgeCommit message (Collapse)Author
2022-10-26wifi: ath10k: add peer map clean up for peer delete in ath10k_sta_state()Wen Gong
[ Upstream commit f020d9570a04df0762a2ac5c50cf1d8c511c9164 ] When peer delete failed in a disconnect operation, use-after-free detected by KFENCE in below log. It is because for each vdev_id and address, it has only one struct ath10k_peer, it is allocated in ath10k_peer_map_event(). When connected to an AP, it has more than one HTT_T2H_MSG_TYPE_PEER_MAP reported from firmware, then the array peer_map of struct ath10k will be set muti-elements to the same ath10k_peer in ath10k_peer_map_event(). When peer delete failed in ath10k_sta_state(), the ath10k_peer will be free for the 1st peer id in array peer_map of struct ath10k, and then use-after-free happened for the 2nd peer id because they map to the same ath10k_peer. And clean up all peers in array peer_map for the ath10k_peer, then user-after-free disappeared peer map event log: [ 306.911021] wlan0: authenticate with b0:2a:43:e6:75:0e [ 306.957187] ath10k_pci 0000:01:00.0: mac vdev 0 peer create b0:2a:43:e6:75:0e (new sta) sta 1 / 32 peer 1 / 33 [ 306.957395] ath10k_pci 0000:01:00.0: htt peer map vdev 0 peer b0:2a:43:e6:75:0e id 246 [ 306.957404] ath10k_pci 0000:01:00.0: htt peer map vdev 0 peer b0:2a:43:e6:75:0e id 198 [ 306.986924] ath10k_pci 0000:01:00.0: htt peer map vdev 0 peer b0:2a:43:e6:75:0e id 166 peer unmap event log: [ 435.715691] wlan0: deauthenticating from b0:2a:43:e6:75:0e by local choice (Reason: 3=DEAUTH_LEAVING) [ 435.716802] ath10k_pci 0000:01:00.0: mac vdev 0 peer delete b0:2a:43:e6:75:0e sta ffff990e0e9c2b50 (sta gone) [ 435.717177] ath10k_pci 0000:01:00.0: htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 246 [ 435.717186] ath10k_pci 0000:01:00.0: htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 198 [ 435.717193] ath10k_pci 0000:01:00.0: htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 166 use-after-free log: [21705.888627] wlan0: deauthenticating from d0:76:8f:82:be:75 by local choice (Reason: 3=DEAUTH_LEAVING) [21713.799910] ath10k_pci 0000:01:00.0: failed to delete peer d0:76:8f:82:be:75 for vdev 0: -110 [21713.799925] ath10k_pci 0000:01:00.0: found sta peer d0:76:8f:82:be:75 (ptr 0000000000000000 id 102) entry on vdev 0 after it was supposedly removed [21713.799968] ================================================================== [21713.799991] BUG: KFENCE: use-after-free read in ath10k_sta_state+0x265/0xb8a [ath10k_core] [21713.799991] [21713.799997] Use-after-free read at 0x00000000abe1c75e (in kfence-#69): [21713.800010] ath10k_sta_state+0x265/0xb8a [ath10k_core] [21713.800041] drv_sta_state+0x115/0x677 [mac80211] [21713.800059] __sta_info_destroy_part2+0xb1/0x133 [mac80211] [21713.800076] __sta_info_flush+0x11d/0x162 [mac80211] [21713.800093] ieee80211_set_disassoc+0x12d/0x2f4 [mac80211] [21713.800110] ieee80211_mgd_deauth+0x26c/0x29b [mac80211] [21713.800137] cfg80211_mlme_deauth+0x13f/0x1bb [cfg80211] [21713.800153] nl80211_deauthenticate+0xf8/0x121 [cfg80211] [21713.800161] genl_rcv_msg+0x38e/0x3be [21713.800166] netlink_rcv_skb+0x89/0xf7 [21713.800171] genl_rcv+0x28/0x36 [21713.800176] netlink_unicast+0x179/0x24b [21713.800181] netlink_sendmsg+0x3a0/0x40e [21713.800187] sock_sendmsg+0x72/0x76 [21713.800192] ____sys_sendmsg+0x16d/0x1e3 [21713.800196] ___sys_sendmsg+0x95/0xd1 [21713.800200] __sys_sendmsg+0x85/0xbf [21713.800205] do_syscall_64+0x43/0x55 [21713.800210] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [21713.800213] [21713.800219] kfence-#69: 0x000000009149b0d5-0x000000004c0697fb, size=1064, cache=kmalloc-2k [21713.800219] [21713.800224] allocated by task 13 on cpu 0 at 21705.501373s: [21713.800241] ath10k_peer_map_event+0x7e/0x154 [ath10k_core] [21713.800254] ath10k_htt_t2h_msg_handler+0x586/0x1039 [ath10k_core] [21713.800265] ath10k_htt_htc_t2h_msg_handler+0x12/0x28 [ath10k_core] [21713.800277] ath10k_htc_rx_completion_handler+0x14c/0x1b5 [ath10k_core] [21713.800283] ath10k_pci_process_rx_cb+0x195/0x1df [ath10k_pci] [21713.800294] ath10k_ce_per_engine_service+0x55/0x74 [ath10k_core] [21713.800305] ath10k_ce_per_engine_service_any+0x76/0x84 [ath10k_core] [21713.800310] ath10k_pci_napi_poll+0x49/0x144 [ath10k_pci] [21713.800316] net_rx_action+0xdc/0x361 [21713.800320] __do_softirq+0x163/0x29a [21713.800325] asm_call_irq_on_stack+0x12/0x20 [21713.800331] do_softirq_own_stack+0x3c/0x48 [21713.800337] __irq_exit_rcu+0x9b/0x9d [21713.800342] common_interrupt+0xc9/0x14d [21713.800346] asm_common_interrupt+0x1e/0x40 [21713.800351] ksoftirqd_should_run+0x5/0x16 [21713.800357] smpboot_thread_fn+0x148/0x211 [21713.800362] kthread+0x150/0x15f [21713.800367] ret_from_fork+0x22/0x30 [21713.800370] [21713.800374] freed by task 708 on cpu 1 at 21713.799953s: [21713.800498] ath10k_sta_state+0x2c6/0xb8a [ath10k_core] [21713.800515] drv_sta_state+0x115/0x677 [mac80211] [21713.800532] __sta_info_destroy_part2+0xb1/0x133 [mac80211] [21713.800548] __sta_info_flush+0x11d/0x162 [mac80211] [21713.800565] ieee80211_set_disassoc+0x12d/0x2f4 [mac80211] [21713.800581] ieee80211_mgd_deauth+0x26c/0x29b [mac80211] [21713.800598] cfg80211_mlme_deauth+0x13f/0x1bb [cfg80211] [21713.800614] nl80211_deauthenticate+0xf8/0x121 [cfg80211] [21713.800619] genl_rcv_msg+0x38e/0x3be [21713.800623] netlink_rcv_skb+0x89/0xf7 [21713.800628] genl_rcv+0x28/0x36 [21713.800632] netlink_unicast+0x179/0x24b [21713.800637] netlink_sendmsg+0x3a0/0x40e [21713.800642] sock_sendmsg+0x72/0x76 [21713.800646] ____sys_sendmsg+0x16d/0x1e3 [21713.800651] ___sys_sendmsg+0x95/0xd1 [21713.800655] __sys_sendmsg+0x85/0xbf [21713.800659] do_syscall_64+0x43/0x55 [21713.800663] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1 Fixes: d0eeafad1189 ("ath10k: Clean up peer when sta goes away.") Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220801141930.16794-1-quic_wgong@quicinc.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-26ath10k: fix max antenna gain unitSven Eckelmann
[ 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-07-20ath10k: Fix an error code in ath10k_add_interface()Yang Li
[ 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-03-07ath10k: fix wmi mgmt tx queue full due to race conditionMiaoqing Pan
[ Upstream commit b55379e343a3472c35f4a1245906db5158cab453 ] Failed to transmit wmi management frames: [84977.840894] ath10k_snoc a000000.wifi: wmi mgmt tx queue is full [84977.840913] ath10k_snoc a000000.wifi: failed to transmit packet, dropping: -28 [84977.840924] ath10k_snoc a000000.wifi: failed to submit frame: -28 [84977.840932] ath10k_snoc a000000.wifi: failed to transmit frame: -28 This issue is caused by race condition between skb_dequeue and __skb_queue_tail. The queue of ‘wmi_mgmt_tx_queue’ is protected by a different lock: ar->data_lock vs list->lock, the result is no protection. So when ath10k_mgmt_over_wmi_tx_work() and ath10k_mac_tx_wmi_mgmt() running concurrently on different CPUs, there appear to be a rare corner cases when the queue length is 1, CPUx (skb_deuque) CPUy (__skb_queue_tail) next=list prev=list struct sk_buff *skb = skb_peek(list); WRITE_ONCE(newsk->next, next); WRITE_ONCE(list->qlen, list->qlen - 1);WRITE_ONCE(newsk->prev, prev); next = skb->next; WRITE_ONCE(next->prev, newsk); prev = skb->prev; WRITE_ONCE(prev->next, newsk); skb->next = skb->prev = NULL; list->qlen++; WRITE_ONCE(next->prev, prev); WRITE_ONCE(prev->next, next); If the instruction ‘next = skb->next’ is executed before ‘WRITE_ONCE(prev->next, newsk)’, newsk will be lost, as CPUx get the old ‘next’ pointer, but the length is still added by one. The final result is the length of the queue will reach the maximum value but the queue is empty. So remove ar->data_lock, and use 'skb_queue_tail' instead of '__skb_queue_tail' to prevent the potential race condition. Also switch to use skb_queue_len_lockless, in case we queue a few SKBs simultaneously. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1.c2-00033-QCAHLSWMTPLZ-1 Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1608618887-8857-1-git-send-email-miaoqing@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath10k: provide survey info as accumulated dataVenkateswara Naralasetty
[ Upstream commit 720e5c03e5cb26d33d97f55192b791bb48478aa5 ] It is expected that the returned counters by .get_survey are monotonic increasing. But the data from ath10k gets reset to zero regularly. Channel active/busy time are then showing incorrect values (less than previous or sometimes zero) for the currently active channel during successive survey dump commands. example: $ iw dev wlan0 survey dump Survey data from wlan0 frequency: 5180 MHz [in use] channel active time: 54995 ms channel busy time: 432 ms channel receive time: 0 ms channel transmit time: 59 ms ... $ iw dev wlan0 survey dump Survey data from wlan0 frequency: 5180 MHz [in use] channel active time: 32592 ms channel busy time: 254 ms channel receive time: 0 ms channel transmit time: 0 ms ... The correct way to handle this is to use the non-clearing WMI_BSS_SURVEY_REQ_TYPE_READ wmi_bss_survey_req_type. The firmware will then accumulate the survey data and handle wrap arounds. Tested-on: QCA9984 hw1.0 10.4-3.5.3-00057 Tested-on: QCA988X hw2.0 10.2.4-1.0-00047 Tested-on: QCA9888 hw2.0 10.4-3.9.0.2-00024 Tested-on: QCA4019 hw1.0 10.4-3.6-00140 Fixes: fa7937e3d5c2 ("ath10k: update bss channel survey information") Signed-off-by: Venkateswara Naralasetty <vnaralas@codeaurora.org> Tested-by: Markus Theil <markus.theil@tu-ilmenau.de> Tested-by: John Deere <24601deerej@gmail.com> [sven@narfation.org: adjust commit message] Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1592232686-28712-1-git-send-email-kvalo@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-22ath10k: Remove msdu from idr when management pkt send failsRakesh Pillai
[ Upstream commit c730c477176ad4af86d9aae4d360a7ad840b073a ] Currently when the sending of any management pkt via wmi command fails, the packet is being unmapped freed in the error handling. But the idr entry added, which is used to track these packet is not getting removed. Hence, during unload, in wmi cleanup, all the entries in IDR are removed and the corresponding buffer is attempted to be freed. This can cause a situation where one packet is attempted to be freed twice. Fix this error by rmeoving the msdu from the idr list when the sending of a management packet over wmi fails. Tested HW: WCN3990 Tested FW: WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1 Fixes: 1807da49733e ("ath10k: wmi: add management tx by reference support over wmi") Signed-off-by: Rakesh Pillai <pillair@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1588667015-25490-1-git-send-email-pillair@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-27ath10k: fix dma unmap direction for management framesRakesh Pillai
[ Upstream commit 6e8a8991e2103dcb6a9cff28f460390e8e360848 ] The management frames transmitted are dma mapped with direction TO_DEVICE, but incorrectly mapped with direction FROM_DEVICE during tx complete and error cases. Fix the direction of dma during dma unmap of the transmitted management frames. Tested HW: WCN3990 Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1 Fixes: 38a1390e02b7 ("ath10k: dma unmap mgmt tx buffer if wmi cmd send fails") Signed-off-by: Rakesh Pillai <pillair@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31ath10k: Correct error handling of dma_map_single()Bjorn Andersson
[ Upstream commit d43810b2c1808ac865aa1a2a2c291644bf95345c ] The return value of dma_map_single() should be checked for errors using dma_mapping_error() and the skb has been dequeued so it needs to be freed. This was found when enabling CONFIG_DMA_API_DEBUG and it warned about the missing dma_mapping_error() call. Fixes: 1807da49733e ("ath10k: wmi: add management tx by reference support over wmi") Reported-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31ath10k: fix offchannel tx failure when no ath10k_mac_tx_frm_has_freqBen Greear
[ Upstream commit cc6df017e55764ffef9819dd9554053182535ffd ] Offchannel management frames were failing: [18099.253732] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3780 [18102.293686] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3780 [18105.333653] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3780 [18108.373712] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3780 [18111.413687] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e36c0 [18114.453726] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3f00 [18117.493773] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e36c0 [18120.533631] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3f00 This bug appears to have been added between 4.0 (which works for us), and 4.4, which does not work. I think this is because the tx-offchannel logic gets in a loop when ath10k_mac_tx_frm_has_freq(ar) is false, so pkt is never actually sent to the firmware for transmit. This patch fixes the problem on 4.9 for me, and now HS20 clients can work again with my firmware. Antonio: tested with 10.4-3.5.3-00057 on QCA4019 and QCA9888 Signed-off-by: Ben Greear <greearb@candelatech.com> Tested-by: Antonio Quartulli <antonio.quartulli@kaiwoo.ai> [kvalo@codeaurora.org: improve commit log, remove unneeded parenthesis] Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-01ath10k: set probe request oui during driver startRakesh Pillai
[ Upstream commit f1157695c527d4ee949ac83f743f80107751a70c ] Currently the wmi command for setting probe request oui, needed for mac randomization, is sent during the mac register. At this time, during the driver init the wmi has already been detached. This can cause unexpected behavior since the firmware is already down and the wmi has been detached. Send the wmi command for setting probe request oui during the driver start. This will make sure that the firmware is started and wmi is initialized before we send this command. Tested HW: WCN3990 Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1 Fixes: 60e1d0fb290197fe505dff6e4e3b7e4d258dbf60 Signed-off-by: Rakesh Pillai <pillair@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-24ath10k: fix vdev-start timeout on errorBen Greear
[ Upstream commit 833fd34d743c728afe6d127ef7bee67e7d9199a8 ] The vdev-start-response message should cause the completion to fire, even in the error case. Otherwise, the user still gets no useful information and everything is blocked until the timeout period. Add some warning text to print out the invalid status code to aid debugging, and propagate failure code. Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20ath10k: limit available channels via DT ieee80211-freq-limitSven Eckelmann
[ Upstream commit 34d5629d2ca89d847b7040762b87964c696c14da ] Tri-band devices (1x 2.4GHz + 2x 5GHz) often incorporate special filters in the RX and TX path. These filtered channel can in theory still be used by the hardware but the signal strength is reduced so much that it makes no sense. There is already a DT property to limit the available channels but ath10k has to manually call this functionality to limit the currrently set wiphy channels further. Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-26ath10k: Do not send probe response template for meshSurabhi Vishnoi
[ Upstream commit 97354f2c432788e3163134df6bb144f4b6289d87 ] Currently mac80211 do not support probe response template for mesh point. When WMI_SERVICE_BEACON_OFFLOAD is enabled, host driver tries to configure probe response template for mesh, but it fails because the interface type is not NL80211_IFTYPE_AP but NL80211_IFTYPE_MESH_POINT. To avoid this failure, skip sending probe response template to firmware for mesh point. Tested HW: WCN3990/QCA6174/QCA9984 Signed-off-by: Surabhi Vishnoi <svishnoi@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-05ath10k: Drop WARN_ON()s that always trigger during system resumeRafael J. Wysocki
commit 9e80ad37f6788ed52b89a3cfcd593e0aa69b216d upstream. ath10k_mac_vif_chan() always returns an error for the given vif during system-wide resume which reliably triggers two WARN_ON()s in ath10k_bss_info_changed() and they are not particularly useful in that code path, so drop them. Tested: QCA6174 hw3.2 PCI with WLAN.RM.2.0-00180-QCARMSWPZ-1 Tested: QCA6174 hw3.2 SDIO with WLAN.RMH.4.4.1-00007-QCARMSWP-1 Fixes: cd93b83ad927 ("ath10k: support for multicast rate control") Fixes: f279294e9ee2 ("ath10k: add support for configuring management packet rate") Cc: stable@vger.kernel.org Reviewed-by: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org> Tested-by: Claire Chang <tientzu@chromium.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-07-31ath10k: prevent active scans on potential unusable channelsSven Eckelmann
The QCA4019 hw1.0 firmware 10.4-3.2.1-00050 and 10.4-3.5.3-00053 (and most likely all other) seem to ignore the WMI_CHAN_FLAG_DFS flag during the scan. This results in transmission (probe requests) on channels which are not "available" for transmissions. Since the firmware is closed source and nothing can be done from our side to fix the problem in it, the driver has to work around this problem. The WMI_CHAN_FLAG_PASSIVE seems to be interpreted by the firmware to not scan actively on a channel unless an AP was detected on it. Simple probe requests will then be transmitted by the STA on the channel. ath10k must therefore also use this flag when it queues a radar channel for scanning. This should reduce the chance of an active scan when the channel might be "unusable" for transmissions. Fixes: e8a50f8ba44b ("ath10k: introduce DFS implementation") Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-07-31ath10k: fix parenthesis alignmentKalle Valo
These were recently introduced and found by checkpatch: drivers/net/wireless/ath/ath10k/mac.c:6118: Alignment should match open parenthesis drivers/net/wireless/ath/ath10k/mac.c:6121: Alignment should match open parenthesis drivers/net/wireless/ath/ath10k/mac.c:6124: Alignment should match open parenthesis Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-07-30ath10k: support for multicast rate controlPradeep Kumar Chitrapu
Issues a wmi command to firmware when multicast rate change is received with the new BSS_CHANGED_MCAST_RATE flag. Also fixes the incorrect fixed_rate setting for CCK rates which got introduced with addition of ath10k_rates_rev2 enum. Tested on QCA9984 with firmware ver 10.4-3.6-00104 Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-07-25Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo
ath.git patches for 4.19. Major changes: wcn36xx * fix WEP in client mode wil6210 * add support for Talyn-MB (Talyn ver 2.0) device * add support for enhanced DMA firmware feature
2018-07-23Merge tag 'wireless-drivers-next-for-davem-2018-07-23' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 4.19 The first set of patches for 4.19. Only smaller features and bug fixes, not really anything major. Also included are changes to include/linux/bitfield.h, we agreed with Johannes that it makes sense to apply them via wireless-drivers-next. Major changes: ath10k * support channel 173 * fix spectral scan for QCA9984 and QCA9888 chipsets ath6kl * add support for Dell Wireless 1537 ti wlcore * add support for runtime PM * enable runtime PM autosuspend support qtnfmac * support changing MAC address * enable source MAC address randomization support libertas * fix suspend and resume for SDIO cards mt76 * add software DFS radar pattern detector for mt76x2 based devices ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2018-06-28ath10k: replace hardcoded constant with defineErik Stromdahl
The hardcoded values used in ath10k_mac_tx_push_pending and ath10k_mac_op_wake_tx_queue set an upper limit of how many packets that can be consumed from the TX queue. HTC_HOST_MAX_MSG_PER_TX_BUNDLE is a proper name for this constant, as the value effectively limits the number of messages that can be consumed in one step. Thus, the value is an upper limit of the number of messages that can be added to a TX message bundle. Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-06-28ath10k: transmit queued frames after processing rx packetsNiklas Cassel
When running iperf on ath10k SDIO, TX can stop working: iperf -c 192.168.1.1 -i 1 -t 20 -w 10K [ 3] 0.0- 1.0 sec 2.00 MBytes 16.8 Mbits/sec [ 3] 1.0- 2.0 sec 3.12 MBytes 26.2 Mbits/sec [ 3] 2.0- 3.0 sec 3.25 MBytes 27.3 Mbits/sec [ 3] 3.0- 4.0 sec 655 KBytes 5.36 Mbits/sec [ 3] 4.0- 5.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 5.0- 6.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 6.0- 7.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 7.0- 8.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 8.0- 9.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 9.0-10.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 0.0-10.3 sec 9.01 MBytes 7.32 Mbits/sec There are frames in the ieee80211_txq and there are frames that have been removed from from this queue, but haven't yet been sent on the wire (num_pending_tx). When num_pending_tx reaches max_num_pending_tx, we will stop the queues by calling ieee80211_stop_queues(). As frames that have previously been sent for transmission (num_pending_tx) are completed, we will decrease num_pending_tx and wake the queues by calling ieee80211_wake_queue(). ieee80211_wake_queue() does not call wake_tx_queue, so we might still have frames in the queue at this point. While the queues were stopped, the socket buffer might have filled up, and in order for user space to write more, we need to free the frames in the queue, since they are accounted to the socket. In order to free them, we first need to transmit them. This problem cannot be reproduced on low-latency devices, e.g. pci, since they call ath10k_mac_tx_push_pending() from ath10k_htt_txrx_compl_task(). ath10k_htt_txrx_compl_task() is not called on high-latency devices. Fix the problem by calling ath10k_mac_tx_push_pending(), after processing rx packets, just like for low-latency devices, also in the SDIO case. Since we are calling ath10k_mac_tx_push_pending() directly, we also need to export it. Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-06-28ath10k: update the phymode along with bandwidth change requestRyan Hsu
In the case of Station connects to AP with narrower bandwidth at beginning. And later the AP changes the bandwidth to winder bandwidth, the AP will beacon with wider bandwidth IE, eg VHT20->VHT40->VHT80 or VHT40->VHT80. Since the supported BANDWIDTH will be limited by the PHYMODE, so while Station receives the bandwidth change request, it will also need to reconfigure the PHYMODE setting to firmware instead of just configuring the BANDWIDTH info, otherwise it'll trigger a firmware crash with non-support bandwidth. The issue was observed in WLAN.RM.4.4.1-00051-QCARMSWP-1, QCA6174 with below scenario: AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0 MHz) disconnect from AP xxx for new auth to yyy RX ReassocResp from xxx (capab=0x1111 status=0 aid=102) associated .... AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0 MHz) AP xxx changed bandwidth, new config is 5200 MHz, width 3 (5210/0 MHz) .... firmware register dump: [00]: 0x05030000 0x000015B3 0x00987291 0x00955B31 [04]: 0x00987291 0x00060730 0x00000004 0x00000001 [08]: 0x004089F0 0x00955A00 0x000A0B00 0x00400000 [12]: 0x00000009 0x00000000 0x00952CD0 0x00952CE6 [16]: 0x00952CC4 0x0098E25F 0x00000000 0x0091080D [20]: 0x40987291 0x0040E7A8 0x00000000 0x0041EE3C [24]: 0x809ABF05 0x0040E808 0x00000000 0xC0987291 [28]: 0x809A650C 0x0040E948 0x0041FE40 0x004345C4 [32]: 0x809A5C63 0x0040E988 0x0040E9AC 0x0042D1A8 [36]: 0x8091D252 0x0040E9A8 0x00000002 0x00000001 [40]: 0x809FDA9D 0x0040EA58 0x0043D554 0x0042D554 [44]: 0x809F8B22 0x0040EA78 0x0043D554 0x00000001 [48]: 0x80911210 0x0040EAC8 0x00000010 0x004041D0 [52]: 0x80911154 0x0040EB28 0x00400000 0x00000000 [56]: 0x8091122D 0x0040EB48 0x00000000 0x00400600 Reported-by: Rouven Czerwinski <rouven@czerwinskis.de> Tested-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Ryan Hsu <ryanhsu@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-06-27wireless-drivers: use BIT_ULL for NL80211_STA_INFO_ attribute typesOmer Efrat
The BIT macro uses unsigned long which some architectures handle as 32 bit and therefore might cause macro's shift to overflow when used on a value equals or larger than 32 (NL80211_STA_INFO_RX_DURATION and afterwards). Since 'filled' member in station_info changed to u64, BIT_ULL macro should be used with all NL80211_STA_INFO_* attribute types instead of BIT to prevent future possible bugs when one will use BIT macro for higher attributes by mistake. This commit cleans up all usages of BIT macro with the above field in wireless-drivers by changing it to BIT_ULL instead. In addition, there are some places which don't use BIT nor BIT_ULL macros so align those as well. Signed-off-by: Omer Efrat <omer.efrat@tandemg.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-06-14ath10k: support use of channel 173Ben Greear
The India regulatory domain allows CH 173, so add that to the available channel list. I verified basic connectivity between a 9880 and 9984 NIC. Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-05-25ath10k: DFS Host ConfirmationSriram R
In the 10.4-3.6 firmware branch there's a new DFS Host confirmation feature which is advertised using WMI_SERVICE_HOST_DFS_CHECK_SUPPORT flag. This new features enables the ath10k host to send information to the firmware on the specifications of detected radar type. This allows the firmware to validate if the host's radar pattern detector unit is operational and check if the radar information shared by host matches the radar pulses sent as phy error events from firmware. If the check fails the firmware won't allow use of DFS channels on AP mode when using FCC regulatory region. Hence this patch is mandatory when using a firmware from 10.4-3.6 branch. Else, DFS channels on FCC regions cannot be used. Supported Chipsets : QCA9984/QCA9888/QCA4019 Firmware Version : 10.4-3.6-00104 Signed-off-by: Sriram R <srirrama@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-05-25ath10k: add support to configure channel dwell timePradeep Kumar Chitrapu
Configure channel dwell time from duration of the scan request received from mac80211 when the duration is non-zero. When the scan request does not have duration value, use the default ones, the current implementation. Corresponding flag NL80211_EXT_FEATURE_SET_SCAN_DWELL is advertized. Supported Chipsets: -QCA988X/QCA9887 PCI -QCA99X0/QCA9984/QCA9888/QCA4019 PCI -QCA6174/QCA9377 PCI/USB/SDIO -WCN3990 SNOC Tested on QCA9984 with firmware ver 10.4-3.6-0010 Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-05-12ath10k: fix return value check in wake_tx_q opErik Stromdahl
ath10k_mac_tx_push_txq returns either a postive integer (length) on success or a negative error code on error. The "if (ret) break;" statement will thus always break out of the loop immediately after ath10k_mac_tx_push_txq has returned (making the loop pointless). A side effect of this fix is that we will iterate the queue until ath10k_mac_tx_push_txq returns -ENOENT. This will make sure the queue is not added back to ar->txqs when it is empty. This could potentially improve performance somewhat (I have seen a small improvement with SDIO devices). Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-24ath10k: enable sta idle power saveGovind Singh
Enable sta power save in fw for the targets that supports idle power save. The idle ps enable command will be ignored by the firmware which does not support this feature. Signed-off-by: Govind Singh <govinds@codeaurora.org> Signed-off-by: Rakesh Pillai <pillair@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-24ath10k: support MAC address randomization in scanCarl Huang
The ath10k reports the random_mac_addr capability to upper layer based on the service bit firmware reported. Driver sets the spoofed flag in scan_ctrl_flag to firmware if upper layer has enabled this feature in scan request. Test with QCA6174 hw3.0 and firmware-6.bin_WLAN.RM.4.4.1-00102-QCARMSWP-1, but QCA9377 is also affected. Signed-off-by: Carl Huang <cjhuang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-19ath10k: add inlined wrappers for htt tx opsErik Stromdahl
These wrappers makes the HTT ops align better with the HIF ops (where similar wrappers are used). It also makes it easier for a target to have unsupported ops (by letting the corresponding function pointer be NULL). Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-03-29ath10k: advertize beacon_int_min_gcdAnilkumar Kolli
This patch fixes regression caused by 0c317a02ca98 ("cfg80211: support virtual interfaces with different beacon intervals"), with this change cfg80211 expects the driver to advertize 'beacon_int_min_gcd' to support different beacon intervals in multivap scenario. This support is added for, QCA988X/QCA99X0/QCA9984/QCA4019. Verifed AP + mesh bring up on QCA9984 with beacon interval 100msec and 1000msec respectively. Frimware: firmware-5.bin_10.4-3.5.3-00053 Fixes: 0c317a02ca98 ("cfg80211: support virtual interfaces with different beacon intervals") Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-03-29ath10k: fix TDLS peer TX data failure issue on encryped APYingying Tang
For WPA encryption, QCA6174 firmware(version: WLAN.RM.4.4) will unblock data when M4 was sent successfully. For other encryption which didn't need 4-way handshake firmware will unblock the data when peer authorized. Since TDLS is 3-way handshake host need send authorize cmd to firmware to unblock data. Signed-off-by: Yingying Tang <yintang@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-03-29ath10k: avoid to set WEP key for TDLS peerYingying Tang
TDLS peer do not need WEP key. Setting WEP key will lead to TDLS setup failure. Add fix to avoid setting WEP key for TDLS peer. Signed-off-by: Yingying Tang <yintang@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-03-29ath10k: enable TDLS peer buffer STA featureYingying Tang
Enable TDLS peer buffer STA feature. QCA6174 firmware(version: WLAN.RM.4.4) support TDLS peer buffer STA, it reports this capability through wmi service map in wmi service ready event. Set related parameter in TDLS WMI command to enable this feature. Signed-off-by: Yingying Tang <yintang@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-03-29Revert "ath10k: send (re)assoc peer command when NSS changed"Karthikeyan Periyasamy
This reverts commit 55884c045d31a29cf69db8332d1064a1b61dd159. When Ath10k is in AP mode and an unassociated STA sends a VHT action frame (Operating Mode Notification for the NSS change) periodically to AP this causes ath10k to call ath10k_station_assoc() which sends WMI_PEER_ASSOC_CMDID during NSS update. Over the time (with a certain client it can happen within 15 mins when there are over 500 of these VHT action frames) continuous calls of WMI_PEER_ASSOC_CMDID cause firmware to assert due to resource exhaust. To my knowledge setting WMI_PEER_NSS peer param itself enough to handle NSS updates and no need to call ath10k_station_assoc(). So revert the original commit from 2014 as it's unclear why the change was really needed. Now the firmware assert doesn't happen anymore. Issue observed in QCA9984 platform with firmware version:10.4-3.5.3-00053. This Change tested in QCA9984 with firmware version: 10.4-3.5.3-00053 and QCA988x platform with firmware version: 10.2.4-1.0-00036. Firmware Assert log: ath10k_pci 0002:01:00.0: firmware crashed! (guid e61f1274-9acd-4c5b-bcca-e032ea6e723c) ath10k_pci 0002:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe ath10k_pci 0002:01:00.0: kconfig debug 1 debugfs 1 tracing 0 dfs 1 testmode 1 ath10k_pci 0002:01:00.0: firmware ver 10.4-3.5.3-00053 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast crc32 4c56a386 ath10k_pci 0002:01:00.0: board_file api 2 bmi_id 0:4 crc32 c2271344 ath10k_pci 0002:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1 ath10k_pci 0002:01:00.0: firmware register dump: ath10k_pci 0002:01:00.0: [00]: 0x0000000A 0x000015B3 0x00981E5F 0x00975B31 ath10k_pci 0002:01:00.0: [04]: 0x00981E5F 0x00060530 0x00000011 0x00446C60 ath10k_pci 0002:01:00.0: [08]: 0x0042F1FC 0x00458080 0x00000017 0x00000000 ath10k_pci 0002:01:00.0: [12]: 0x00000009 0x00000000 0x00973ABC 0x00973AD2 ath10k_pci 0002:01:00.0: [16]: 0x00973AB0 0x00960E62 0x009606CA 0x00000000 ath10k_pci 0002:01:00.0: [20]: 0x40981E5F 0x004066DC 0x00400000 0x00981E34 ath10k_pci 0002:01:00.0: [24]: 0x80983B48 0x0040673C 0x000000C0 0xC0981E5F ath10k_pci 0002:01:00.0: [28]: 0x80993DEB 0x0040676C 0x00431AB8 0x0045D0C4 ath10k_pci 0002:01:00.0: [32]: 0x80993E5C 0x004067AC 0x004303C0 0x0045D0C4 ath10k_pci 0002:01:00.0: [36]: 0x80994AAB 0x004067DC 0x00000000 0x0045D0C4 ath10k_pci 0002:01:00.0: [40]: 0x809971A0 0x0040681C 0x004303C0 0x00441B00 ath10k_pci 0002:01:00.0: [44]: 0x80991904 0x0040688C 0x004303C0 0x0045D0C4 ath10k_pci 0002:01:00.0: [48]: 0x80963AD3 0x00406A7C 0x004303C0 0x009918FC ath10k_pci 0002:01:00.0: [52]: 0x80960E80 0x00406A9C 0x0000001F 0x00400000 ath10k_pci 0002:01:00.0: [56]: 0x80960E51 0x00406ACC 0x00400000 0x00000000 ath10k_pci 0002:01:00.0: Copy Engine register dump: ath10k_pci 0002:01:00.0: index: addr: sr_wr_idx: sr_r_idx: dst_wr_idx: dst_r_idx: ath10k_pci 0002:01:00.0: [00]: 0x0004a000 15 15 3 3 ath10k_pci 0002:01:00.0: [01]: 0x0004a400 17 17 212 213 ath10k_pci 0002:01:00.0: [02]: 0x0004a800 21 21 20 21 ath10k_pci 0002:01:00.0: [03]: 0x0004ac00 25 25 27 25 ath10k_pci 0002:01:00.0: [04]: 0x0004b000 515 515 144 104 ath10k_pci 0002:01:00.0: [05]: 0x0004b400 28 28 155 156 ath10k_pci 0002:01:00.0: [06]: 0x0004b800 12 12 12 12 ath10k_pci 0002:01:00.0: [07]: 0x0004bc00 1 1 1 1 ath10k_pci 0002:01:00.0: [08]: 0x0004c000 0 0 127 0 ath10k_pci 0002:01:00.0: [09]: 0x0004c400 1 1 1 1 ath10k_pci 0002:01:00.0: [10]: 0x0004c800 0 0 0 0 ath10k_pci 0002:01:00.0: [11]: 0x0004cc00 0 0 0 0 ath10k_pci 0002:01:00.0: CE[1] write_index 212 sw_index 213 hw_index 0 nentries_mask 0x000001ff ath10k_pci 0002:01:00.0: CE[2] write_index 20 sw_index 21 hw_index 0 nentries_mask 0x0000007f ath10k_pci 0002:01:00.0: CE[5] write_index 155 sw_index 156 hw_index 0 nentries_mask 0x000001ff ath10k_pci 0002:01:00.0: DMA addr: nbytes: meta data: byte swap: gather: ath10k_pci 0002:01:00.0: [455]: 0x580c0042 0 0 0 0 ath10k_pci 0002:01:00.0: [456]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [457]: 0x580c0042 0 0 0 0 ath10k_pci 0002:01:00.0: [458]: 0x594a0038 0 0 0 1 ath10k_pci 0002:01:00.0: [459]: 0x580c0a42 0 0 0 0 ath10k_pci 0002:01:00.0: [460]: 0x594a0060 0 0 0 1 ath10k_pci 0002:01:00.0: [461]: 0x580c0c42 0 0 0 0 ath10k_pci 0002:01:00.0: [462]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [463]: 0x580c0c42 0 0 0 0 ath10k_pci 0002:01:00.0: [464]: 0x594a0038 0 0 0 1 ath10k_pci 0002:01:00.0: [465]: 0x580c0a42 0 0 0 0 ath10k_pci 0002:01:00.0: [466]: 0x594a0060 0 0 0 1 ath10k_pci 0002:01:00.0: [467]: 0x580c0042 0 0 0 0 ath10k_pci 0002:01:00.0: [468]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [469]: 0x580c1c42 0 0 0 0 ath10k_pci 0002:01:00.0: [470]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [471]: 0x580c1c42 0 0 0 0 ath10k_pci 0002:01:00.0: [472]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [473]: 0x580c1c42 0 0 0 0 ath10k_pci 0002:01:00.0: [474]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [475]: 0x580c0642 0 0 0 0 ath10k_pci 0002:01:00.0: [476]: 0x594a0038 0 0 0 1 ath10k_pci 0002:01:00.0: [477]: 0x580c0842 0 0 0 0 ath10k_pci 0002:01:00.0: [478]: 0x594a0060 0 0 0 1 ath10k_pci 0002:01:00.0: [479]: 0x580c0042 0 0 0 0 ath10k_pci 0002:01:00.0: [480]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [481]: 0x580c0042 0 0 0 0 ath10k_pci 0002:01:00.0: [482]: 0x594a0038 0 0 0 1 ath10k_pci 0002:01:00.0: [483]: 0x580c0842 0 0 0 0 ath10k_pci 0002:01:00.0: [484]: 0x594a0060 0 0 0 1 ath10k_pci 0002:01:00.0: [485]: 0x580c0642 0 0 0 0 ath10k_pci 0002:01:00.0: [486]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [487]: 0x580c0642 0 0 0 0 ath10k_pci 0002:01:00.0: [488]: 0x594a0038 0 0 0 1 ath10k_pci 0002:01:00.0: [489]: 0x580c0842 0 0 0 0 ath10k_pci 0002:01:00.0: [490]: 0x594a0060 0 0 0 1 ath10k_pci 0002:01:00.0: [491]: 0x580c0042 0 0 0 0 ath10k_pci 0002:01:00.0: [492]: 0x58174040 0 1 0 0 ath10k_pci 0002:01:00.0: [493]: 0x5a946040 0 1 0 0 ath10k_pci 0002:01:00.0: [494]: 0x59909040 0 1 0 0 ath10k_pci 0002:01:00.0: [495]: 0x5ae5a040 0 1 0 0 ath10k_pci 0002:01:00.0: [496]: 0x58096040 0 1 0 0 ath10k_pci 0002:01:00.0: [497]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [498]: 0x580c0642 0 0 0 0 ath10k_pci 0002:01:00.0: [499]: 0x5c1e0040 0 1 0 0 ath10k_pci 0002:01:00.0: [500]: 0x58153040 0 1 0 0 ath10k_pci 0002:01:00.0: [501]: 0x58129040 0 1 0 0 ath10k_pci 0002:01:00.0: [502]: 0x5952f040 0 1 0 0 ath10k_pci 0002:01:00.0: [503]: 0x59535040 0 1 0 0 ath10k_pci 0002:01:00.0: [504]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [505]: 0x580c0042 0 0 0 0 ath10k_pci 0002:01:00.0: [506]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [507]: 0x580c0042 0 0 0 0 ath10k_pci 0002:01:00.0: [508]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [509]: 0x580c0042 0 0 0 0 ath10k_pci 0002:01:00.0: [510]: 0x594a0010 0 0 0 1 ath10k_pci 0002:01:00.0: [511]: 0x580c0042 0 0 0 0 ath10k_pci 0002:01:00.0: [512]: 0x5adcc040 0 1 0 0 ath10k_pci 0002:01:00.0: [513]: 0x5cf3d040 0 1 0 0 ath10k_pci 0002:01:00.0: [514]: 0x5c1e9040 64 1 0 0 ath10k_pci 0002:01:00.0: [515]: 0x00000000 0 0 0 0 Signed-off-by: Karthikeyan Periyasamy <periyasa@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-03-26ath10k: Fix kernel panic while using worker (ath10k_sta_rc_update_wk)Karthikeyan Periyasamy
When attempt to run worker (ath10k_sta_rc_update_wk) after the station object (ieee80211_sta) delete will trigger the kernel panic. This problem arise in AP + Mesh configuration, Where the current node AP VAP and neighbor node mesh VAP MAC address are same. When the current mesh node try to establish the mesh link with neighbor node, driver peer creation for the neighbor mesh node fails due to duplication MAC address. Already the AP VAP created with same MAC address. It is caused by the following scenario steps. Steps: 1. In above condition, ath10k driver sta_state callback (ath10k_sta_state) fails to do the state change for a station from IEEE80211_STA_NOTEXIST to IEEE80211_STA_NONE due to peer creation fails. Sta_state callback is called from ieee80211_add_station() to handle the new station (neighbor mesh node) request from the wpa_supplicant. 2. Concurrently ath10k receive the sta_rc_update callback notification from the mesh_neighbour_update() to handle the beacon frames of the above neighbor mesh node. since its atomic callback, ath10k driver queue the work (ath10k_sta_rc_update_wk) to handle rc update. 3. Due to driver sta_state callback fails (step 1), mac80211 free the station object. 4. When the worker (ath10k_sta_rc_update_wk) scheduled to run, it will access the station object which is already deleted. so it will trigger kernel panic. Added the peer exist check in sta_rc_update callback before queue the work. Kernel Panic log: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0204000 [00000000] *pgd=00000000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM CPU: 1 PID: 1833 Comm: kworker/u4:2 Not tainted 3.14.77 #1 task: dcef0000 ti: d72b6000 task.ti: d72b6000 PC is at pwq_activate_delayed_work+0x10/0x40 LR is at pwq_activate_delayed_work+0xc/0x40 pc : [<c023f988>] lr : [<c023f984>] psr: 40000193 sp : d72b7f18 ip : 0000007a fp : d72b6000 r10: 00000000 r9 : dd404414 r8 : d8c31998 r7 : d72b6038 r6 : 00000004 r5 : d4907ec8 r4 : dcee1300 r3 : ffffffe0 r2 : 00000000 r1 : 00000001 r0 : 00000000 Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5787d Table: 595bc06a DAC: 00000015 ... Process kworker/u4:2 (pid: 1833, stack limit = 0xd72b6238) Stack: (0xd72b7f18 to 0xd72b8000) 7f00: 00000001 dcee1300 7f20: 00000001 c02410dc d8c31980 dd404400 dd404400 c0242790 d8c31980 00000089 7f40: 00000000 d93e1340 00000000 d8c31980 c0242568 00000000 00000000 00000000 7f60: 00000000 c02474dc 00000000 00000000 000000f8 d8c31980 00000000 00000000 7f80: d72b7f80 d72b7f80 00000000 00000000 d72b7f90 d72b7f90 d72b7fac d93e1340 7fa0: c0247404 00000000 00000000 c0208d20 00000000 00000000 00000000 00000000 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [<c023f988>] (pwq_activate_delayed_work) from [<c02410dc>] (pwq_dec_nr_in_flight+0x58/0xc4) [<c02410dc>] (pwq_dec_nr_in_flight) from [<c0242790>] (worker_thread+0x228/0x360) [<c0242790>] (worker_thread) from [<c02474dc>] (kthread+0xd8/0xec) [<c02474dc>] (kthread) from [<c0208d20>] (ret_from_fork+0x14/0x34) Code: e92d4038 e1a05000 ebffffbc[69210.619376] SMP: failed to stop secondary CPUs Rebooting in 3 seconds.. Signed-off-by: Karthikeyan Periyasamy <periyasa@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-03-14ath10k: dma unmap mgmt tx buffer if wmi cmd send failsRakesh Pillai
WCN3990 sends mgmt frames by reference via WMI. The host dma maps the mgmt frame and sends the physical address to the firmware in the wmi command. Since the dma mapping is done in the gen_mgmt_tx and if the wmi command send fails, the corresponding mgmt frame is not being dma unmapped. Fix the missing dma unmapping of mgmt tx frame when wmi command sending fails for mgmt tx by reference via WMI. The already exisiting mgmt tx using copy by value does not need such dma unmapping. Add a separate wmi-tlv op for mgmt tx via ref, which takes care of unmapping the dma address, in case of wmi command sending failure. Signed-off-by: Rakesh Pillai <pillair@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-12-27ath10k: update copyright yearKalle Valo
Update year for Qualcomm Atheros, Inc. copyrights. Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-12-27ath10k: advertise TDLS wider bandwidth support for 5GHzBalaji Pothunoori
Enable TDLS wider bandwidth support for 5GHz based on firmware wmi capabilities. This patch is required for chipset QCA9888. Tested with firmware version 10.4-3.5.1-00018. Signed-off-by: Balaji Pothunoori <bpothuno@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-12-27ath10k: Add support for htt_data_tx_desc_64 descriptorGovind Singh
WCN3990 target uses 64 bit frags_paddr in htt tx descriptor, which holds the physical address of SKB fragments in tx data path. In order to support 64 bit bit frags_paddr in htt tx descriptor, define htt_data_tx_desc_64 descriptor and ath10k_htt_tx_64 method for handling tx data path with new descriptor fields. Signed-off-by: Govind Singh <govinds@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-12-14ath10k: wmi: modify svc bitmap parsing for wcn3990Rakesh Pillai
Due to the limitation of wmi tlv parsing logic, if there are two parameters in a wmi event with same tlv tag, we can get only the last value, as it overwrites the prev value of the same tlv tag. The service ready event in wcn3990 contains two parameters of the same tag UINT32, due to which the svc bitmap is overwritten with the DBS support parameter. Refactor the service ready event parsing to allow parsing two tlv of the same tag UINT32 for wcn3990. Signed-off-by: Rakesh Pillai <pillair@qti.qualcomm.com> Signed-off-by: Govind Singh <govinds@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-12-14ath10k: add per peer tx stats support for 10.2.4Anilkumar Kolli
10.2.4 firmware branch (used in QCA988X) does not support HTT_10_4_T2H_MSG_TYPE_PEER_STATS and that's why ath10k does not provide tranmission rate statistics to user space, instead it just shows hardcoded 6 Mbit/s. But pktlog firmware facility provides per peer tx statistics. The firmware sends one pktlog event for every four PPDUs per peer, which include: * successful number of packets and bytes transmitted * number of packets and bytes dropped * retried number of packets and bytes * rate info per ppdu Firmware supports WMI_SERVICE_PEER_STATS, pktlog is enabled through ATH10K_FLAG_PEER_STATS, which is nowadays enabled by default in ath10k. This patch does not impact throughput. Tested on QCA9880 with firmware version 10.2.4.70.48. This should also work with firmware branch 10.2.4-1.0-00029 Parse peer stats from pktlog packets and update the tx rate information per STA. This way user space can query about transmit rate with iw: $iw wlan0 station dump Station 3c:a9:f4:72:bb:a4 (on wlan1) inactive time: 8210 ms rx bytes: 9166 rx packets: 44 tx bytes: 1105 tx packets: 9 tx retries: 0 tx failed: 1 rx drop misc: 3 signal: -75 [-75, -87, -88] dBm signal avg: -75 [-75, -85, -88] dBm tx bitrate: 39.0 MBit/s MCS 10 rx bitrate: 26.0 MBit/s MCS 3 rx duration: 23250 us authorized: yes authenticated: yes associated: yes preamble: short WMM/WME: yes MFP: no TDLS peer: no DTIM period: 2 beacon interval:100 short preamble: yes short slot time:yes connected time: 22 seconds Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-12-14ath10k: remove MAC80211_DEBUGFS dependency on ath10k_sta_statisticsAnilkumar Kolli
Remove CONFIG_MAC80211_DEBUGFS dependency on ath10k_sta_statistics(). ath10k_sta_statistics() has per sta tx/rx stats and this should not be dependent on MAC80211_DEBUGFS. No changes in functionality. Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-12-14ath10k: handling qos at STA side based on AP WMM enable/disableBalaji Pothunoori
Data packets are not sent by STA in case of STA joined to non QOS AP (WMM disabled AP). This is happening because of STA is sending data packets to firmware from host with qos enabled along with non qos queue value(TID = 16). Due to qos enabled, firmware is discarding the packet. This patch fixes this issue by updating the qos based on station WME capability field if WMM is disabled in AP. This patch is required by 10.4 family chipsets like QCA4019/QCA9888/QCA9884/QCA99X0. Firmware Versoin : 10.4-3.5.1-00018. For 10.2.4 family chipsets QCA988X/QCA9887 and QCA6174 this patch has no effect. Signed-off-by: Balaji Pothunoori <bpothuno@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-12-02ath10k: update tdls teardown state to targetManikanta Pubbisetty
It is required to update the teardown state of the peer when a tdls link with that peer is terminated. This information is useful for the target to perform some cleanups wrt the tdls peer. Without proper cleanup, target assumes that the peer is connected and blocks future connection requests, updating the teardown state of the peer addresses the problem. Tested this change on QCA9888 with 10.4-3.5.1-00018 fw version. Signed-off-by: Manikanta Pubbisetty <mpubbise@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-12-02ath10k: re-enable TXQs for all devicesToke Høiland-Jørgensen
Commit 4ca1807815aa ("ath10k: disable wake_tx_queue for older devices") disables the use of the mac80211 TXQs for some devices because of a theoretical throughput regression. The original regression report[1] was related to fq_codel qdisc drop performance, which was fixed in commit 9d18562a2278 ("fq_codel: add batch ability to fq_codel_drop()"). Since then, we have not seen the TXQ-related regression, so it should be safe to re-enable TXQs. [1] http://lists.infradead.org/pipermail/ath10k/2016-April/007266.html Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-10-27ath10k: block offchannel operations if TDLS session is activeAnilkumar Kolli
Do not allow off channel operations like scans/roc when there are active TDLS sessions. The Current firmware 10.4-3.5.1-00035 on QCA9888 does not supports any offchannel operations on active TDLS sessions, either driver needs to block the offchannel operation requests or should teardown the TDLS connection. Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-10-27ath10k: move ath10k_mac_tdls_vif*() functionsAnilkumar Kolli
To be able to use ath10k_mac_tdls_vif_stations_count() in ath10k_hw_scan() in the following patch, move the functions earlier in the file. This commit is pure code move, no functional changes. Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-10-13ath10k: add new cipher suite supportRajkumar Manoharan
QCA99x0 and QCA4019 family chips support CCMP-256, GCMP-128, and GCMP-256 ciphers in hardware, so advertise support for these. As firmware does not support group management frame ciphers (BIP), handle them in software (mac80211). Reviewed-by: Sebastian Gottschall <s.gottschall@dd-wrt.com> Cc: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-10-13ath10k: check power save support in STA mode through FW IEVenkateswara Naralasetty
Currently ath10k host enables power save support in station mode by default for all firmwares but Power save for station mode still not supported in some of the firmware versions. Which results in firmware crash while issueing multiple scan commands. Fix this problem by introducing new FW feature flag to check power save support in firmware and then the firmware image can tell to ath10k that power save mode is not supported in station mode. Signed-off-by: Venkateswara Naralasetty <vnaralas@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
generated by cgit 1.2.3-korg (git 2.39.0) at 2024-05-10 14:56:31 +0000