summaryrefslogtreecommitdiffstats
path: root/drivers/net/wireless/ath/ath10k/mac.c
Commit message (Collapse)AuthorAgeFilesLines
* ath10k: DFS Host ConfirmationSriram R2018-05-251-0/+12
| | | | | | | | | | | | | | | | | | | | | | 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>
* ath10k: add support to configure channel dwell timePradeep Kumar Chitrapu2018-05-251-3/+20
| | | | | | | | | | | | | | | | | | | | | 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>
* ath10k: fix return value check in wake_tx_q opErik Stromdahl2018-05-121-1/+1
| | | | | | | | | | | | | | | | | | 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>
* ath10k: enable sta idle power saveGovind Singh2018-04-241-0/+7
| | | | | | | | | | | 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>
* ath10k: support MAC address randomization in scanCarl Huang2018-04-241-0/+17
| | | | | | | | | | | | | 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>
* ath10k: add inlined wrappers for htt tx opsErik Stromdahl2018-04-191-1/+1
| | | | | | | | | | | 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>
* ath10k: advertize beacon_int_min_gcdAnilkumar Kolli2018-03-291-0/+2
| | | | | | | | | | | | | | | | 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>
* ath10k: fix TDLS peer TX data failure issue on encryped APYingying Tang2018-03-291-0/+4
| | | | | | | | | | | 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>
* ath10k: avoid to set WEP key for TDLS peerYingying Tang2018-03-291-1/+1
| | | | | | | | | 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>
* ath10k: enable TDLS peer buffer STA featureYingying Tang2018-03-291-0/+3
| | | | | | | | | | 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>
* Revert "ath10k: send (re)assoc peer command when NSS changed"Karthikeyan Periyasamy2018-03-291-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ath10k: Fix kernel panic while using worker (ath10k_sta_rc_update_wk)Karthikeyan Periyasamy2018-03-261-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ath10k: dma unmap mgmt tx buffer if wmi cmd send failsRakesh Pillai2018-03-141-5/+23
| | | | | | | | | | | | | | | | | | | | 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>
* ath10k: update copyright yearKalle Valo2017-12-271-1/+1
| | | | | | Update year for Qualcomm Atheros, Inc. copyrights. Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* ath10k: advertise TDLS wider bandwidth support for 5GHzBalaji Pothunoori2017-12-271-1/+2
| | | | | | | | | | 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>
* ath10k: Add support for htt_data_tx_desc_64 descriptorGovind Singh2017-12-271-1/+1
| | | | | | | | | | | | 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>
* ath10k: wmi: modify svc bitmap parsing for wcn3990Rakesh Pillai2017-12-141-1/+3
| | | | | | | | | | | | | | | | | 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>
* ath10k: add per peer tx stats support for 10.2.4Anilkumar Kolli2017-12-141-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ath10k: remove MAC80211_DEBUGFS dependency on ath10k_sta_statisticsAnilkumar Kolli2017-12-141-1/+29
| | | | | | | | | | | 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>
* ath10k: handling qos at STA side based on AP WMM enable/disableBalaji Pothunoori2017-12-141-1/+1
| | | | | | | | | | | | | | | | | | | | | 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>
* ath10k: update tdls teardown state to targetManikanta Pubbisetty2017-12-021-0/+10
| | | | | | | | | | | | | | | 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>
* ath10k: re-enable TXQs for all devicesToke Høiland-Jørgensen2017-12-021-9/+0
| | | | | | | | | | | | | | 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>
* ath10k: block offchannel operations if TDLS session is activeAnilkumar Kolli2017-10-271-0/+10
| | | | | | | | | | | | | 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>
* ath10k: move ath10k_mac_tdls_vif*() functionsAnilkumar Kolli2017-10-271-53/+53
| | | | | | | | | | | 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>
* ath10k: add new cipher suite supportRajkumar Manoharan2017-10-131-2/+41
| | | | | | | | | | | | 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>
* ath10k: check power save support in STA mode through FW IEVenkateswara Naralasetty2017-10-131-2/+7
| | | | | | | | | | | | | | 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>
* ath10k: configure and enable the wakeup capabilityRyan Hsu2017-08-311-0/+1
| | | | | | | | | | | | | | ACPI will rely on device driver to tell it if the device could support wakeup function when system in D3 state. This has caused some platform can't support remote wakeup correctly, because the ACPI wakeup GPE is not enabled, hence registers the .set_wakeup callback to handle it if device supports wakeup. Tested with QCA6174 hw3.0, firmware ('WLAN.RM.4.4.1-00008-QCARMSWP-1') Signed-off-by: Ryan Hsu <ryanhsu@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* ath10k: add tdls support for 10.4 firmwaresManikanta Pubbisetty2017-08-031-1/+4
| | | | | | | | | | | This patch adds the support of TDLS feature for 10.4 firmware versions. A new WMI service is added to advertise the support of TDLS for 10.4 firmwares. Signed-off-by: Manikanta Pubbisetty <mpubbise@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* ath10k: fix a bunch of spelling mistakes in messagesColin Ian King2017-06-281-1/+1
| | | | | | | | | | | Fix the following spelling mistakes in messages: syncronise -> synchronize unusally -> unusually addrress -> address inverval -> interval Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* Merge tag 'wireless-drivers-next-for-davem-2017-06-25' of ↵David S. Miller2017-06-251-29/+48
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 4.13 New features and bug fixes to quite a few different drivers, but nothing really special standing out. What makes me happy that we have now more vendors actively contributing to upstream drivers. In this pull request we have patches from Broadcom, Intel, Qualcomm, Realtek and Redpine Signals, and I still have patches from Marvell and Quantenna pending in patchwork. Now that's something comparing to how things looked 11 years ago in Jeff Garzik's "State of the Union: Wireless" email: https://lkml.org/lkml/2006/1/5/671 Major changes: wil6210 * add low level RF sector interface via nl80211 vendor commands * add module parameter ftm_mode to load separate firmware for factory testing * support devices with different PCIe bar size * add support for PCIe D3hot in system suspend * remove ioctl interface which should not be in a wireless driver ath10k * go back to using dma_alloc_coherent() for firmware scratch memory * add per chain RSSI reporting brcmfmac * add support multi-scheduled scan * add scheduled scan support for specified BSSIDs * add support for brcm43430 revision 0 wlcore * add wil1285 compatible rsi * add RS9113 USB support iwlwifi * FW API documentation improvements (for tools and htmldoc) * continuing work for the new A000 family * bump the maximum supported FW API to 31 * improve the differentiation between 8000, 9000 and A000 families ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * ath10k: configure rxnss_override for QCA9984Ben Greear2017-06-211-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QCA9984 hardware can do 4x4 at 80Mhz, but only 2x2 at 160Mhz. First, report this to user-space by setting the max-tx-speed and max-rx-speed vht capabilities. Second, if the peer rx-speed is configured, and if we are in 160 or 80+80 mode, and the peer rx-speed matches the max speed for 2x2 or 1x1 at 160Mhz (long guard interval), then use that info to set the peer_bw_rxnss_override appropriately. Without this, a 9984 firmware will not use 2x2 ratesets when transmitting to peer (it will be stuck at 1x1), because the firmware would not have configured the rxnss_override. Signed-off-by: Ben Greear <greearb@candelatech.com> [sven.eckelmann@openmesh.com: rebase, cleanup, drop 160Mhz workaround cleanup] Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> [kvalo@qca.qualcomm.com: use hw_params, rename the title] Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
| * ath10k: use complete VHT chan width for 160MHz workaroundBen Greear2017-06-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ath10k firmware doesn't announce its VHT channel width capabilities in the vht_cap information from the "service ready event" arguments. The driver must therefore check whether the 160MHz short GI bit is set and whether the driver still doesn't set the bits for the 160/80+80 MHz capabilities. The two bits for the channel width are a two bit integer and not two separate bits which cannot be parsed without the knowledge of the other bit. Using IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ (b10..) as a mask for this task doesn't make any sense. The correct mask for the VHT channel width should be used instead to make this check more readable. Signed-off-by: Ben Greear <greearb@candelatech.com> [sven.eckelmann@openmesh.com: separate 160Mhz workaround cleanup, add commit message] Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
| * ath10k: fix the logic of limiting tdls peer countsRyan Hsu2017-06-011-28/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | The original idea is to limit the maximum TDLS peer link, but the logic is always false, and never be able to restrict the number of TDLS peer creation. Fix the logic here and also move the checking earlier, so that it could avoid to handle the failure case, e.g disable the tdls peer, delete the peer and also vdev count cleanup. Signed-off-by: Ryan Hsu <ryanhsu@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | networking: introduce and use skb_put_data()Johannes Berg2017-06-161-3/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A common pattern with skb_put() is to just want to memcpy() some data into the new space, introduce skb_put_data() for this. An spatch similar to the one for skb_put_zero() converts many of the places using it: @@ identifier p, p2; expression len, skb, data; type t, t2; @@ ( -p = skb_put(skb, len); +p = skb_put_data(skb, data, len); | -p = (t)skb_put(skb, len); +p = skb_put_data(skb, data, len); ) ( p2 = (t2)p; -memcpy(p2, data, len); | -memcpy(p, data, len); ) @@ type t, t2; identifier p, p2; expression skb, data; @@ t *p; ... ( -p = skb_put(skb, sizeof(t)); +p = skb_put_data(skb, data, sizeof(t)); | -p = (t *)skb_put(skb, sizeof(t)); +p = skb_put_data(skb, data, sizeof(t)); ) ( p2 = (t2)p; -memcpy(p2, data, sizeof(*p)); | -memcpy(p, data, sizeof(*p)); ) @@ expression skb, len, data; @@ -memcpy(skb_put(skb, len), data, len); +skb_put_data(skb, data, len); (again, manually post-processed to retain some comments) Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge tag 'wireless-drivers-next-for-davem-2017-04-21' of ↵David S. Miller2017-04-241-16/+42
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 4.12 Quite a lot of patches for rtlwifi and iwlwifi this time, but changes also for other active wireless drivers. Major changes: ath9k * add support for Dell Wireless 1601 PCI device * add debugfs file to manually override noise floor ath10k * bump up FW API to 6 for a new QCA6174 firmware branch wil6210 * support 8 kB RX buffers iwlwifi * work to support A000 devices continues * add support for FW API 30 * add Geographical and Dynamic Specific Absorption Rate (SAR) support * support a few new PCI device IDs rtlwifi * work on adding Bluetooth coexistance support, not finished yet ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * ath10k: fix block comments styleMarcin Rokicki2017-04-051-16/+27
| | | | | | | | | | | | | | | | Fix output from checkpatch.pl like: Block comments use a trailing */ on a separate lin Signed-off-by: Marcin Rokicki <marcin.rokicki@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
| * ath10k: cancel coverage class work during stop and restartMohammed Shafi Shajakhan2017-04-051-0/+1
| | | | | | | | | | | | | | | | | | | | It seems set_coverage_class_work is not cancelled anywhere, though I could not find a crash/warning with this existing design, its safer to cancel it during stop() and also before restarting the hardware. Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
| * ath10k: fix station nss computationVenkateswara Rao Naralasetty2017-04-051-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If station advertises diffferent NSS capabilities in Rx_mcs set of HT and VHT IEs in assoc req, the current NSS computation logic configures the NSS support only based on Rx_mcs set of HT capabilities in the driver. This is configuring the station NSS capabilities incorreclty in the target. For example, if station advertise Rx_mcs set as 2 spatial streams in HT capabilities and 1 spatial streams in VHT capabilities in assoc request, as per current logic we are calculating nss from HT capabilities and the driver sets peer_num_spatial_streams as 2 for the station which is configured in VHT 1*1. This patchs fix this issue by calculating the nss from VHT cap if station supports vht. Signed-off-by: Venkateswara Rao Naralasetty <c_vnaral@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | Merge tag 'mac80211-next-for-davem-2017-04-18' of ↵David S. Miller2017-04-201-0/+2
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== My last pull request has been a while, we now have: * connection quality monitoring with multiple thresholds * support for FILS shared key authentication offload * pre-CAC regulatory compliance - only ETSI allows this * sanity check for some rate confusion that hit ChromeOS (but nobody else uses it, evidently) * some documentation updates * lots of cleanups ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * wireless: Set NL80211_EXT_FEATURE_CQM_RSSI_LIST in multiple driversAndrew Zaborowski2017-03-061-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Set the NL80211_EXT_FEATURE_CQM_RSSI_LIST wiphy extended feature wholesale in all mac80211-based drivers that do not set the IEEE80211_VIF_BEACON_FILTER flags on their interfaces. mac80211 will be processing supplied RSSI values in ieee80211_rx_mgmt_beacon and will detect when the thresholds set by ieee80211_set_cqm_rssi_range_config are crossed. Remaining (few) drivers need code to enable the firmware to monitor the thresholds. This is mostly only compile-tested. Signed-off-by: Andrew Zaborowski <andrew.zaborowski@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | ath10k: fix warnings from an earlier commitKalle Valo2017-03-201-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | I failed to notice that commit 523f6701dbab ("ath10k: update available channel list for 5G radio") added two new warnings: drivers/net/wireless/ath/ath10k/mac.c:3129:6: warning: symbol 'ath10k_mac_update_channel_list' was not declared. Should it be static? drivers/net/wireless/ath/ath10k/mac.c:3170: Alignment should match open parenthesis Fix those. Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | ath10k: update available channel list for 5G radioTamizh chelvam2017-03-161-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a 5 GHz radio is calibrated for operation in both the low band (channels 36 to 64) and high band(channels 100 to 169), hardware allows operations in all the listed channels. However, if the chip has been calibrated only for the low/high band and a high/low band channel is configured, due to lack of calibration there will be potentially invalid signal on those non calibrated channels. To avoid this problem this patch sets IEEE80211_CHAN_DISABLED flag for those non calibrated channels by using low_5ghz_chan and high_5ghz_chan values which we get from target through wmi service ready event. Driver initialized flags are getting re initialized in handle_channel in cfg80211. So calling the function to disable the non supported channel from reg_notifier(). Signed-off-by: Tamizh chelvam <c_traja@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | ath10k: fix a warning during channel switch with multiple vapsMohammed Shafi Shajakhan2017-03-091-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Doing a channel switch via hostapd_cli seems to update the new channel context for each VAP's appropriately as below in 'ath10k_mac_update_vif_chan', hence we can safely suppress the warning that shows up during this operation and dump the warning only if no vaps are available for channel switch hostapd_cli -i wlan0 chan_switch 5 5200 OK ath10k_pci : mac chanctx switch n_vifs 3 mode 1 ath10k_pci : mac chanctx switch vdev_id 2 freq 5180->5200 width 0->0 ath10k_pci : mac chanctx switch vdev_id 1 freq 5180->5200 width 0->0 ath10k_pci : mac chanctx switch vdev_id 0 freq 5180->5200 width 0->0 Call Trace: WARNING: backports-20161201-3.14.77-9ab3068/drivers/net/wireless/ath/ath10k/mac.c:7126 [<c022f2d4>] (warn_slowpath_null) from [<bf7f150c>] (ath10k_reconfig_complete+0xe4/0x25c [ath10k_core]) [<bf7f150c>] (ath10k_reconfig_complete [ath10k_core]) [<bf7f35f0>] (ath10k_mac_vif_ap_csa_work+0x214/0x370 [ath10k_core]) [<bf7f38b8>] (ath10k_mac_op_change_chanctx+0x108/0x128 [ath10k_core]) [<bf782ac0>] (ieee80211_recalc_chanctx_min_def+0x30c/0x430 [mac80211]) [<bf7830a4>] (ieee80211_recalc_smps_chanctx+0x2ec/0x840 [mac80211]) [<bf7843e8>] (ieee80211_vif_use_reserved_context+0x7c/0xf8 [mac80211]) [<bf7843e8>] (ieee80211_vif_use_reserved_context [mac80211]) [<bf76e5d4>] (ieee80211_csa_finalize_work+0x5c/0x88 [mac80211]) Fixes: d7bf4b4aba05 ("ath10k: fix ar->rx_channel updating logic") Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* ath10k: remove ath10k_vif_to_arvif()Amadeusz Sławiński2017-02-141-34/+34
| | | | | | | | it adds unnecessary level of indirection, while we just access structure field Signed-off-by: Amadeusz Sławiński <amadeusz.slawinski@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* ath10k: prevent sta pointer rcu violationMichal Kazior2017-01-191-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | Station pointers are RCU protected so driver must be extra careful if it tries to store them internally for later use outside of the RCU section it obtained it in. It was possible for station teardown to race with some htt events. The possible outcome could be a use-after-free and a crash. Only peer-flow-control capable firmware was affected (so hardware-wise qca99x0 and qca4019). This could be done in sta_state() itself via explicit synchronize_net() call but there's already a convenient sta_pre_rcu_remove() op that can be hooked up to avoid extra rcu stall. The peer->sta pointer itself can't be set to NULL/ERR_PTR because it is later used in sta_state() for extra sanity checks. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* ath10k: add VHT160 supportSebastian Gottschall2017-01-131-2/+33
| | | | | | | | | | | This patch adds full VHT160 support for QCA9984 chipsets Tested on Netgear R7800. 80+80 is possible, but disabled so far since it seems to contain glitches like missing vht station flags (this may be firmware or mac80211 related). Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com> [kvalo@qca.qualcomm.com: refactoring and fix few warnings] Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* ath10k: refactor ath10k_peer_assoc_h_phymode()Kalle Valo2017-01-131-6/+16
| | | | | | | | When adding VHT160 support to ath10k_peer_assoc_h_phymode() the VHT mode selection code becomes too complex. Simplify it by refactoring the vht part to a separate function. Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* ath10k: enable advertising support for channel 169, 5GhzMohammed Shafi Shajakhan2016-12-301-0/+1
| | | | | | | | | | Enable advertising support for channel 169, 5Ghz so that based on the regulatory domain(country code) this channel shall be active for use. For example in countries like India this channel shall be available for use with latest regulatory updates Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* ath10k: Remove passing unused argument for ath10k_mac_txMohammed Shafi Shajakhan2016-12-301-4/+3
| | | | | | | | | 'ath10k_mac_tx' does not seems to use the per station table entry pointer 'sta' (struct ieee80211_sta), hence remove passing this unused argument Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* ath10k: recal the txpower when removing interfaceRyan Hsu2016-12-301-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The txpower is being recalculated when adding interface to make sure txpower won't overshoot the spec, and when removing the interface, the txpower should again to be recalculated to restore the correct value from the active interface list. Following is one of the scenario vdev0 is created as STA and connected: txpower:23 vdev1 is created as P2P_DEVICE for control interface: txpower:0 vdev2 is created as p2p go/gc interface: txpower is 21 So the vdev2@txpower:21 will be set to firmware when vdev2 is created. When we tear down the vdev2, the txpower needs to be recalculated to re-set it to vdev0@txpower:23 as vdev0/vdev1 are the active interface. ath10k_pci mac vdev 0 peer create 8c:fd:f0:01:62:98 ath10k_pci mac vdev_id 0 txpower 23 ... (adding interface) ath10k_pci mac vdev create 2 (add interface) type 1 subtype 3 ath10k_pci mac vdev_id 2 txpower 21 ath10k_pci mac txpower 21 ... (removing interface) ath10k_pci mac vdev 2 delete (remove interface) ath10k_pci vdev 1 txpower 0 ath10k_pci vdev 0 txpower 23 ath10k_pci mac txpower 23 Signed-off-by: Ryan Hsu <ryanhsu@qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
OpenPOWER on IntegriCloud