summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/ath/ath10k
AgeCommit message (Collapse)Author
2017-02-07ath10k: prefer unsigned int over just unsignedKalle Valo
Fixes new checkpatch warnings: drivers/net/wireless/ath/ath10k/htt.h:1639: Prefer 'unsigned int' to bare use of 'unsigned' drivers/net/wireless/ath/ath10k/htt.h:1660: Prefer 'unsigned int' to bare use of 'unsigned' Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-02-01Merge tag 'wireless-drivers-next-for-davem-2017-02-01' 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.11 It's nice to see rt2x00 development has becoming active, for example adding support for a new chip version. Also wcn36xx has been converted to use the recently merged QCOM_SMD subsystem. Otherwise new features and fixes it lots of drivers. Major changes: iwlwifi * some more work in preparation for A000 family support * add support for radiotap timestamps * some work on our firmware debugging capabilities wcn36xx * convert to a proper QCOM_SMD driver (from the platform_driver interface) ath10k * VHT160 support * dump Copy Engine registers during firmware crash * search board file extension from SMBIOS wil6210 * add disable_ap_sme module parameter rt2x00 * support RT3352 with external PA * support for RT3352 with 20MHz crystal * add support for RT5350 WiSoC brcmfmac * add support for BCM43455 sdio device rtl8xxxu * add support for D-Link DWA-131 rev E1, TP-Link TL-WN822N v4 and others ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-01-30drivers: net: generalize napi_complete_done()Eric Dumazet
napi_complete_done() allows to opt-in for gro_flush_timeout, added back in linux-3.19, commit 3b47d30396ba ("net: gro: add a per device gro flush timer") This allows for more efficient GRO aggregation without sacrifying latencies. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-01-27ath10k: Search SMBIOS for OEM board file extensionWaldemar Rymarkiewicz
Board Data File (BDF) is loaded upon driver boot-up procedure. The right board data file is identified, among others, by device and sybsystem ids. The problem, however, can occur when the (default) board data file cannot fulfill with the vendor requirements and it is necessary to use a different board data file. To solve the issue QCA uses SMBIOS type 0xF8 to store Board Data File Name Extension to specify the extension/variant name. The driver will take the extension suffix into consideration and will load the right (non-default) board data file if necessary. If it is unnecessary to use extension board data file, please leave the SMBIOS field blank and default configuration will be used. Example: If a default board data file for a specific board is identified by a string "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028, subsystem-device=0310" then the OEM specific data file, if used, could be identified by variant suffix: "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028, subsystem-device=0310,variant=DE_1AB" Signed-off-by: Waldemar Rymarkiewicz <ext.waldemar.rymarkiewicz@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-01-27ath10k: fix typo in addr calculationSrinivas Kandagatla
CORE_CTRL_ADDRESS is offset in register address space, it does not make sense to OR it to derive the final address. It looks like its a typo, so fix it. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-01-27ath10k: use dma_zalloc_coherent()Srinivas Kandagatla
use dma_zalloc_coherent() instead of dma_alloc_coherent and memset(). Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-01-27ath10k: remove multiple defines of DIAG_TRANSFER_LIMITSrinivas Kandagatla
DIAG_TRANSFER_LIMIT is redefined with same value and comments just below this entry, remove this duplicate entry. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-01-19ath10k: dump Copy Engine registers during firmware crashMohammed Shafi Shajakhan
Dump Copy Engine source and destination ring addresses. This is useful information to debug firmware crashes, assertes or hangs over long run assessing the Copy Engine Register status. This also enables dumping CE register status in debugfs Crash Dump file. Screenshot: ath10k_pci 0000:02:00.0: simulating hard firmware crash ath10k_pci 0000:02:00.0: firmware crashed! (uuid 84901ff5-d33c-456e-93ee-0165dea643cf) ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000 ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 1 testmode 1 ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.59-2 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498 ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08 ath10k_pci 0000:02:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1 ath10k_pci 0000:02:00.0: firmware register dump: ath10k_pci 0000:02:00.0: [00]: 0x4100016C 0x00000000 0x009A0F2A 0x00000000 ath10k_pci 0000:02:00.0: [04]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [08]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [12]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [16]: 0x00000000 0x00000000 0x00000000 0x009A0F2A ath10k_pci 0000:02:00.0: [20]: 0x00000000 0x00401930 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [24]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [28]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [32]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [36]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [40]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [44]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [48]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [52]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: [56]: 0x00000000 0x00000000 0x00000000 0x00000000 ath10k_pci 0000:02:00.0: Copy Engine register dump: ath10k_pci 0000:02:00.0: [00]: 0x00057400 7 7 3 3 ath10k_pci 0000:02:00.0: [01]: 0x00057800 18 18 85 86 ath10k_pci 0000:02:00.0: [02]: 0x00057c00 49 49 48 49 ath10k_pci 0000:02:00.0: [03]: 0x00058000 16 16 17 16 ath10k_pci 0000:02:00.0: [04]: 0x00058400 4 4 44 4 ath10k_pci 0000:02:00.0: [05]: 0x00058800 12 12 11 12 ath10k_pci 0000:02:00.0: [06]: 0x00058c00 3 3 3 3 ath10k_pci 0000:02:00.0: [07]: 0x00059000 0 0 0 0 ieee80211 phy0: Hardware restart was requested ath10k_pci 0000:02:00.0: device successfully recovered Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> [kvalo@qca.qualcomm.com: simplify the implementation] Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-01-19ath10k: fix per station tx bit rate reportingMohammed Shafi Shajakhan
Not clearing the previous tx bit rate status results in a ambigous tx bit rate reporting to mac80211/cfg80211, for example the previous bit rate status would have been marked as legacy rate , while the current rate would have been an HT/VHT rate with the tx bit rate flags set and this results in exporting tx bitrate as legacy rate but with HT/VHT rate flags set, fix this by clearing the tx bitrate status for each event. This also fixes the below warning when we do: iw dev wlan#N station dump WARNING: net/wireless/util.c:1222 cfg80211 [<c022f104>] (warn_slowpath_null) from [<bf3b9adc>] (cfg80211_calculate_bitrate+0x110/0x1f4 [cfg80211]) [<bf3b9adc>] (cfg80211_calculate_bitrate [cfg80211]) from [<bf3dcd54>] (nl80211_put_sta_rate+0x44/0x1dc [cfg80211]) [<bf3dcd54>] (nl80211_put_sta_rate [cfg80211]) from [<bf3cbc34>] (nl80211_set_interface+0x724/0xd70 [cfg80211]) [<bf3cbc34>] (nl80211_set_interface [cfg80211]) from [<bf3d0a18>] (nl80211_dump_station+0xdc/0x100 [cfg80211]) [<bf3d0a18>] (nl80211_dump_station [cfg80211]) Fixes: cec17c382140 ("ath10k: add per peer htt tx stats support for 10.4") Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-01-19ath10k: prevent sta pointer rcu violationMichal Kazior
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>
2017-01-14Merge tag 'mac80211-next-for-davem-2017-01-13' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== For 4.11, we seem to have more than in the past few releases: * socket owner support for connections, so when the wifi manager (e.g. wpa_supplicant) is killed, connections are torn down - wpa_supplicant is critical to managing certain operations, and can opt in to this where applicable * minstrel & minstrel_ht updates to be more efficient (time and space) * set wifi_acked/wifi_acked_valid for skb->destructor use in the kernel, which was already available to userspace * don't indicate new mesh peers that might be used if there's no room to add them * multicast-to-unicast support in mac80211, for better medium usage (since unicast frames can use *much* higher rates, by ~3 orders of magnitude) * add API to read channel (frequency) limitations from DT * add infrastructure to allow randomizing public action frames for MAC address privacy (still requires driver support) * many cleanups and small improvements/fixes across the board ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-01-13ath10k: fix tx legacy rate reportingMohammed Shafi Shajakhan
Tx legacy rate is reported 10 fold, as below iw dev wlan#N station dump | grep "tx bitrate" tx bitrate: 240.0 MBit/s This is because by mistake we multiply by the hardware reported rate twice by 10, fix this. Fixes: cec17c382140 ("ath10k: add per peer htt tx stats support for 10.4") Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-01-13ath10k: fix wifi connectivity and warning in rx with channel 169Mohammed Shafi Shajakhan
In countries where basic operation of channel 169 is allowed, this fixes the below WARN_ON_ONCE in Rx and fixes the station connectivity failure in channel 169 as the packet is dropped in the driver as the current check limits to channel 165. As of now all the packets beyond channel 165 is dropped, fix this by extending the range to channel 169. Call trace: drivers/net/wireless/ath/ath10k/wmi.c:1505 ath10k_wmi_event_mgmt_rx+0x278/0x440 [ath10k_core]() Call Trace: [<c158f812>] ? printk+0x2d/0x2f [<c105a182>] warn_slowpath_common+0x72/0xa0 [<f8b67b58>] ? ath10k_wmi_event_mgmt_rx+0x278/0x440 [<f8b67b58>] ? ath10k_wmi_event_mgmt_rx+0x278/0x440 [<c105a1d2>] warn_slowpath_null+0x22/0x30 [<f8b67b58>] ath10k_wmi_event_mgmt_rx+0x278/0x440 [<f8b0e72b>] ? ath10k_pci_sleep+0x8b/0xb0 [ath10k_pci] [<f8b6ac63>] ath10k_wmi_10_2_op_rx+0xf3/0x3b0 [<f8b6495e>] ath10k_wmi_process_rx+0x1e/0x60 [<f8b5f077>] ath10k_htc_rx_completion_handler+0x347/0x4d0 [ath10k_core] [<f8b11dc3>] ? ath10k_ce_completed_recv_next+0x53/0x70 [ath10k_pci] [<f8b0f921>] ath10k_pci_ce_recv_data+0x171/0x1d0 [ath10k_pci] [<f8b0ec69>] ? ath10k_pci_write32+0x39/0x80 [ath10k_pci] [<f8b120bc>] ath10k_ce_per_engine_service+0x5c/0xa0 [ath10k_pci] [<f8b1215f>] ath10k_ce_per_engine_service_any+0x5f/0x70 [ath10k_pci] [<c1060dc0>] ? local_bh_enable_ip+0x90/0x90 [<f8b1048b>] ath10k_pci_tasklet+0x1b/0x50 [ath10k_pci] Fixes: 34c30b0a5e97 ("ath10k: enable advertising support for channel 169, 5Ghz") Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-01-13ath10k: add accounting for the extended peer statisticsChristian Lamparter
The 10.4 firmware adds extended peer information to the firmware's statistics payload. This additional info is stored as a separate data field and the elements are stored in their own "peers_extd" list. These elements can pile up in the same way as the peer information elements. This is because the ath10k_wmi_10_4_op_pull_fw_stats() function tries to pull the same amount (num_peer_stats) for every statistic data unit. Fixes: 4a49ae94a448faa ("ath10k: fix 10.4 extended peer stats update") Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-01-13ath10k: add VHT160 supportSebastian Gottschall
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>
2017-01-13ath10k: refactor ath10k_peer_assoc_h_phymode()Kalle Valo
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>
2017-01-12ath10k: htc: simplified credit distributionErik Stromdahl
Simplified transmit credit distribution code somewhat. Since the WMI control service will get assigned all credits there is no need for having a credit_allocation array in struct ath10k_htc. Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-01-12ath10k: htc: removal of unused struct membersErik Stromdahl
Removed tx_credits_per_max_message and tx_credit_size from struct ath10k_htc_ep since they are not used anywhere in the code. They are just written, never read. Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2017-01-02Merge tag 'wireless-drivers-next-for-davem-2017-01-02' 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.11 The most notable change here is the inclusion of airtime fairness scheduling to ath9k. It prevents slow clients from hogging all the airtime and unfairly slowing down faster clients. Otherwise smaller changes and cleanup. Major changes: ath9k * cleanup eeprom endian handling * add airtime fairness scheduling ath10k * fix issues for new QCA9377 firmware version * support dev_coredump() for firmware crash dump * enable channel 169 on 5 GHz band ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-30ath10k: enable advertising support for channel 169, 5GhzMohammed Shafi Shajakhan
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>
2016-12-30ath10k: Remove passing unused argument for ath10k_mac_txMohammed Shafi Shajakhan
'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>
2016-12-30ath10k: ignore configuring the incorrect board_idRyan Hsu
With command to get board_id from otp, in the case of following boot get otp board id result 0x00000000 board_id 0 chip_id 0 boot using board name 'bus=pci,bmi-chip-id=0,bmi-board-id=0" ... failed to fetch board data for bus=pci,bmi-chip-id=0,bmi-board-id=0 from ath10k/QCA6174/hw3.0/board-2.bin The invalid board_id=0 will be used as index to search in the board-2.bin. Ignore the case with board_id=0, as it means the otp is not carrying the board id information. Signed-off-by: Ryan Hsu <ryanhsu@qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-12-30ath10k: recal the txpower when removing interfaceRyan Hsu
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>
2016-12-30ath10k: support dev_coredump for crash dumpArun Khandavalli
Whenever firmware crashes, and both CONFIG_ATH10K_DEBUGFS and CONFIG_ALLOW_DEV_COREDUMP are enabled, dump information about the crash via a devcoredump device. Dump can be read from userspace for further analysis from: /sys/class/devcoredump/devcd*/data As until now we have provided the firmware crash dump file via fw_crash_dump debugfs keep it still available but deprecate and a warning print that the user should switch to using dev_coredump. Future improvement would be not to depend on CONFIG_ATH10K_DEBUGFS, as there might be systems which want to get the firmware crash dump but not enable debugfs. How to handle memory consumption is also something which needs to be taken into account. Signed-off-by: Arun Khandavalli <akhandav@qti.qualcomm.com> [kvalo@qca.qualcomm.com: rebase, fixes, improve commit log] Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-12-30ath10k: fix incorrect txpower set by P2P_DEVICE interfaceRyan Hsu
Ath10k reports the phy capability that supports P2P_DEVICE interface. When we use the P2P supported wpa_supplicant to start connection, it'll create two interfaces, one is wlan0 (vdev_id=0) and one is P2P_DEVICE p2p-dev-wlan0 which is for p2p control channel (vdev_id=1). ath10k_pci mac vdev create 0 (add interface) type 2 subtype 0 ath10k_add_interface: vdev_id: 0, txpower: 0, bss_power: 0 ... ath10k_pci mac vdev create 1 (add interface) type 2 subtype 1 ath10k_add_interface: vdev_id: 1, txpower: 0, bss_power: 0 And the txpower in per vif bss_conf will only be set to valid tx power when the interface is assigned with channel_ctx. But this P2P_DEVICE interface will never be used for any connection, so that the uninitialized bss_conf.txpower=0 is assinged to the arvif->txpower when interface created. Since the txpower configuration is firmware per physical interface. So the smallest txpower of all vifs will be the one limit the tx power of the physical device, that causing the low txpower issue on other active interfaces. wlan0: Limiting TX power to 21 (24 - 3) dBm ath10k_pci mac vdev_id 0 txpower 21 ath10k_mac_txpower_recalc: vdev_id: 1, txpower: 0 ath10k_mac_txpower_recalc: vdev_id: 0, txpower: 21 ath10k_pci mac txpower 0 This issue only happens when we use the wpa_supplicant that supports P2P or if we use the iw tool to create the control P2P_DEVICE interface. Signed-off-by: Ryan Hsu <ryanhsu@qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-12-30ath10k: fix potential memory leak in ath10k_wmi_tlv_op_pull_fw_stats()Christian Lamparter
ath10k_wmi_tlv_op_pull_fw_stats() uses tb = ath10k_wmi_tlv_parse_alloc(...) function, which allocates memory. If any of the three error-paths are taken, this tb needs to be freed. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-12-29ath10k: add debug trace to rts/cts set functionBartosz Markowski
Align it with the cts protection call. Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-12-29ath10k: set CTS protection VDEV param only if VDEV is upBartosz Markowski
The cts protection vdev parameter, in new QCA9377 TF2.0 firmware, requires bss peer to be created for the STATION vdev type. bss peer is being allocated by the firmware after vdev_start/_up commands. mac80211 may call the cts protection setup at any time, so the we needs to track the situation and defer the cts configuration to prevent firmware asserts, like below: [00]: 0x05020001 0x000015B3 0x0099ACE2 0x00955B31 [04]: 0x0099ACE2 0x00060730 0x00000004 0x00000000 [08]: 0x0044C754 0x00412C10 0x00000000 0x00409C54 [12]: 0x00000009 0x00000000 0x00952F6C 0x00952F77 [16]: 0x00952CC4 0x00910712 0x00000000 0x00000000 [20]: 0x4099ACE2 0x0040E858 0x00421254 0x004127F4 [24]: 0x8099B9B2 0x0040E8B8 0x00000000 0xC099ACE2 [28]: 0x800B75CB 0x0040E8F8 0x00000007 0x00005008 [32]: 0x809B048A 0x0040E958 0x00000010 0x00433B10 [36]: 0x809AFBBC 0x0040E9A8 0x0042BB74 0x0042BBBC [40]: 0x8091D252 0x0040E9C8 0x0042BBBC 0x00000001 [44]: 0x809FFA45 0x0040EA78 0x0043D3E4 0x0042C2C8 [48]: 0x809FCEF4 0x0040EA98 0x0043D3E4 0x00000001 [52]: 0x80911210 0x0040EAE8 0x00000010 0x004041D0 [56]: 0x80911154 0x0040EB28 0x00400000 0x00000000 Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-12-29ath10k: decrease num of peers supportBartosz Markowski
The correct number for QCA9377 chip is 33 VDEVs. This impacts also QCA6174 chip and it's max VDEV number. Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-12-29ath10k: override CE5 config for QCA9377Bartosz Markowski
Similarly to QCA6174, QCA9377 requires the CE5 configuration to be available for other feature. Use the ath10k_pci_override_ce_config() for it as well. This is required for TF2.0 firmware. Previous FW revisions were working fine without this patch. Fixes: a70587b3389a ("ath10k: configure copy engine 5 for HTT messages") Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-12-29ath10k: fix IRAM banks number for QCA9377Bartosz Markowski
QCA9377 firmware shall alloc 4 IRAM banks Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-12-20ath10k: free host-mem with DMA_BIRECTIONAL flagBen Greear
Hopefully this fixes the problem reported by Kalle: Noticed this in my log, but I don't have time to investigate this in detail right now: [ 413.795346] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 414.158755] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 477.439659] ath10k_pci 0000:02:00.0: could not get mac80211 beacon [ 481.666630] ------------[ cut here ]------------ [ 481.666669] WARNING: CPU: 0 PID: 1978 at lib/dma-debug.c:1155 check_unmap+0x320/0x8e0 [ 481.666688] ath10k_pci 0000:02:00.0: DMA-API: device driver frees DMA memory with different direction [device address=0x000000002d130000] [size=63800 bytes] [mapped with DMA_BIDIRECTIONAL] [unmapped with DMA_TO_DEVICE] [ 481.666703] Modules linked in: ctr ccm ath10k_pci(E-) ath10k_core(E) ath(E) mac80211(E) cfg80211(E) snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi arc4 snd_rawmidi snd_seq_midi_event snd_seq btusb btintel snd_seq_device joydev coret [ 481.671468] CPU: 0 PID: 1978 Comm: rmmod Tainted: G E 4.9.0-rc7-wt+ #54 [ 481.671478] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS 68CDD Ver. F.04 01/27/2010 [ 481.671489] ef49dcec c842ee92 c8b5830e ef49dd34 ef49dd20 c80850f5 c8b5a13c ef49dd50 [ 481.671560] 000007ba c8b5830e 00000483 c8461830 c8461830 00000483 ef49ddcc f34e64b8 [ 481.671641] c8b58360 ef49dd3c c80851bb 00000009 00000000 ef49dd34 c8b5a13c ef49dd50 [ 481.671716] Call Trace: [ 481.671731] [<c842ee92>] dump_stack+0x76/0xb4 [ 481.671745] [<c80850f5>] __warn+0xe5/0x100 [ 481.671757] [<c8461830>] ? check_unmap+0x320/0x8e0 [ 481.671769] [<c8461830>] ? check_unmap+0x320/0x8e0 [ 481.671780] [<c80851bb>] warn_slowpath_fmt+0x3b/0x40 [ 481.671791] [<c8461830>] check_unmap+0x320/0x8e0 [ 481.671804] [<c8462054>] debug_dma_unmap_page+0x84/0xa0 [ 481.671835] [<f937cd7a>] ath10k_wmi_free_host_mem+0x9a/0xe0 [ath10k_core] [ 481.671861] [<f9363400>] ath10k_core_destroy+0x50/0x60 [ath10k_core] [ 481.671875] [<f8e13969>] ath10k_pci_remove+0x79/0xa0 [ath10k_pci] [ 481.671889] [<c848d8d8>] pci_device_remove+0x38/0xb0 [ 481.671901] [<c859fe4b>] __device_release_driver+0x7b/0x110 [ 481.671913] [<c85a00e7>] driver_detach+0x97/0xa0 [ 481.671923] [<c859ef8b>] bus_remove_driver+0x4b/0xb0 [ 481.671934] [<c85a0cda>] driver_unregister+0x2a/0x60 [ 481.671949] [<c848c888>] pci_unregister_driver+0x18/0x70 [ 481.671965] [<f8e14dae>] ath10k_pci_exit+0xd/0x25f [ath10k_pci] [ 481.671979] [<c812bb84>] SyS_delete_module+0xf4/0x180 [ 481.671995] [<c81f801b>] ? __might_fault+0x8b/0xa0 [ 481.672009] [<c80037d0>] do_fast_syscall_32+0xa0/0x1e0 [ 481.672025] [<c88d4c88>] sysenter_past_esp+0x45/0x74 [ 481.672037] ---[ end trace 3fd23759e17e1622 ]--- [ 481.672049] Mapped at: [ 481.672060] [ 481.672072] [<c846062c>] debug_dma_map_page.part.25+0x1c/0xf0 [ 481.672083] [ 481.672095] [<c8460799>] debug_dma_map_page+0x99/0xc0 [ 481.672106] [ 481.672132] [<f93745ec>] ath10k_wmi_alloc_chunk+0x12c/0x1f0 [ath10k_core] [ 481.672142] [ 481.672168] [<f937d0c4>] ath10k_wmi_event_service_ready_work+0x304/0x540 [ath10k_core] [ 481.672178] [ 481.672190] [<c80a3643>] process_one_work+0x1c3/0x670 [ 482.137134] ath10k_pci 0000:02:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0 [ 482.313144] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:02:00.0.bin failed with error -2 [ 482.313274] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/cal-pci-0000:02:00.0.bin failed with error -2 [ 482.313768] ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000 [ 482.313777] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 0 testmode 1 [ 482.313974] ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.59-2 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498 [ 482.369858] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2 [ 482.370011] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08 [ 483.596770] ath10k_pci 0000:02:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1 [ 483.701686] ath: EEPROM regdomain: 0x0 [ 483.701706] ath: EEPROM indicates default country code should be used [ 483.701713] ath: doing EEPROM country->regdmn map search [ 483.701721] ath: country maps to regdmn code: 0x3a [ 483.701730] ath: Country alpha2 being used: US [ 483.701737] ath: Regpair used: 0x3a Reported-by: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-12-15ath10k: Avoid potential page alloc BUG_ON in tx free pathMohammed Shafi Shajakhan
'ath10k_htt_tx_free_cont_txbuf' and 'ath10k_htt_tx_free_cont_frag_desc' have NULL pointer checks to avoid crash if they are called twice but this is as of now not sufficient as these pointers are not assigned to NULL once the contiguous DMA memory allocation is freed, fix this. Though this may not be hit with the explicity check of state variable 'tx_mem_allocated' check, good to have this addressed as well. Below BUG_ON is hit when the above scenario is simulated with kernel debugging enabled page:f6d09a00 count:0 mapcount:-127 mapping: (null) index:0x0 flags: 0x40000000() page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0) ------------[ cut here ]------------ kernel BUG at ./include/linux/mm.h:445! invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC EIP is at put_page_testzero.part.88+0xd/0xf Call Trace: [<c118a2cc>] __free_pages+0x3c/0x40 [<c118a30e>] free_pages+0x3e/0x50 [<c10222b4>] dma_generic_free_coherent+0x24/0x30 [<f8c1d9a8>] ath10k_htt_tx_free_cont_txbuf+0xf8/0x140 [<f8c1e2a9>] ath10k_htt_tx_destroy+0x29/0xa0 [<f8c143e0>] ath10k_core_destroy+0x60/0x80 [ath10k_core] [<f8acd7e9>] ath10k_pci_remove+0x79/0xa0 [ath10k_pci] [<c13ed7a8>] pci_device_remove+0x38/0xb0 [<c14d3492>] __device_release_driver+0x72/0x100 [<c14d36b7>] driver_detach+0x97/0xa0 [<c14d29c0>] bus_remove_driver+0x40/0x80 [<c14d427a>] driver_unregister+0x2a/0x60 [<c13ec768>] pci_unregister_driver+0x18/0x70 [<f8aced4f>] ath10k_pci_exit+0xd/0x2be [ath10k_pci] [<c1101e78>] SyS_delete_module+0x158/0x210 [<c11b34f1>] ? __might_fault+0x41/0xa0 [<c11b353b>] ? __might_fault+0x8b/0xa0 [<c1001a4b>] do_fast_syscall_32+0x9b/0x1c0 [<c178da34>] sysenter_past_esp+0x45/0x74 Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-12-14Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial Pull trivial updates from Jiri Kosina. * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: NTB: correct ntb_spad_count comment typo misc: ibmasm: fix typo in error message Remove references to dead make variable LINUX_INCLUDE Remove last traces of ikconfig.h treewide: Fix printk() message errors Documentation/device-mapper: s/getsize/getsz/
2016-12-14treewide: Fix printk() message errorsMasanari Iida
This patch fix spelling typos in printk and kconfig. Signed-off-by: Masanari Iida <standby24x7@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-12-13cfg80211: get rid of name indirection trick for ieee80211_get_channel()Arend Van Spriel
The comment on the name indirection suggested an issue but turned out to be untrue. Digging in older kernel version showed issue with ipw2x00 but that is no longer true so get rid on the name indirection. Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2016-12-02Merge tag 'wireless-drivers-next-for-davem-2016-12-01' 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.10 Major changes: rsi * filter rx frames * configure tx power * make it possible to select antenna * support 802.11d brcmfmac * cleanup of scheduled scan code * support for bcm43341 chipset with different chip id * support rev6 of PCIe device interface ath10k * add spectral scan support for QCA6174 and QCA9377 families * show used tx bitrate with 10.4 firmware wil6210 * add power save mode support * add abort scan functionality * add support settings retry limit for short frames bcma * add Dell Inspiron 3148 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-01ath10k: wmi-alloc-chunk should use DMA_BIDIRECTIONALBen Greear
These memory chunks are often used as 'swap' by the NIC, so it will be both reading and writing to these areas. This seems to fix errors like this on my x86-64 machine: kernel: DMAR: DMAR:[DMA Write] Request device [05:00.0] fault addr ff5de000 DMAR:[fault reason 05] PTE Write access is not set Tested-by: Marek Behun <kabel@blackhole.sk> Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-12-01ath10k: fix Tx DMA alloc failure during continuous wifi down/upMohammed Shafi Shajakhan
With maximum number of vap's configured in a two radio supported systems of ~256 Mb RAM, doing a continuous wifi down/up and intermittent traffic streaming from the connected stations results in failure to allocate contiguous memory for tx buffers. This results in the disappearance of all VAP's and a manual reboot is needed as this is not a crash (or) OOM(for OOM killer to be invoked). To address this allocate contiguous memory for tx buffers one time and re-use them until the modules are unloaded but this results in a slight increase in memory footprint of ath10k when the wifi is down, but the modules are still loaded. Also as of now we use a separate bool 'tx_mem_allocated' to keep track of the one time memory allocation, as we cannot come up with something like 'ath10k_tx_{register,unregister}' before 'ath10k_probe_fw' is called as 'ath10k_htt_tx_alloc_cont_frag_desc' memory allocation is dependent on the hw_param 'continuous_frag_desc' a) memory footprint of ath10k without the change lsmod | grep ath10k ath10k_core 414498 1 ath10k_pci ath10k_pci 38236 0 b) memory footprint of ath10k with the change ath10k_core 414980 1 ath10k_pci ath10k_pci 38236 0 Memory Failure Call trace: hostapd: page allocation failure: order:6, mode:0xd0 [<c021f150>] (__dma_alloc_buffer.isra.23) from [<c021f23c>] (__alloc_remap_buffer.isra.26+0x14/0xb8) [<c021f23c>] (__alloc_remap_buffer.isra.26) from [<c021f664>] (__dma_alloc+0x224/0x2b8) [<c021f664>] (__dma_alloc) from [<c021f810>] (arm_dma_alloc+0x84/0x90) [<c021f810>] (arm_dma_alloc) from [<bf954764>] (ath10k_htt_tx_alloc+0xe0/0x2e4 [ath10k_core]) [<bf954764>] (ath10k_htt_tx_alloc [ath10k_core]) from [<bf94e6ac>] (ath10k_core_start+0x538/0xcf8 [ath10k_core]) [<bf94e6ac>] (ath10k_core_start [ath10k_core]) from [<bf947eec>] (ath10k_start+0xbc/0x56c [ath10k_core]) [<bf947eec>] (ath10k_start [ath10k_core]) from [<bf8a7a04>] (drv_start+0x40/0x5c [mac80211]) [<bf8a7a04>] (drv_start [mac80211]) from [<bf8b7cf8>] (ieee80211_do_open+0x170/0x82c [mac80211]) [<bf8b7cf8>] (ieee80211_do_open [mac80211]) from [<c056afc8>] (__dev_open+0xa0/0xf4) [21053.491752] Normal: 641*4kB (UEMR) 505*8kB (UEMR) 330*16kB (UEMR) 126*32kB (UEMR) 762*64kB (UEMR) 237*128kB (UEMR) 1*256kB (M) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 95276kB Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-12-01ath10k: fix soft lockup during firmware crash/hw-restartMohammed Shafi Shajakhan
During firmware crash (or) user requested manual restart the system gets into a soft lock up state because of the below root cause. During user requested hardware restart / firmware crash the system goes into a soft lockup state as 'napi_synchronize' is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED' bit) and it sleeps into infinite loop as it waits for 'NAPI_STATE_SCHED' to be cleared. This condition is hit because 'ath10k_hif_stop' is called twice as below (resulting in calling 'napi_synchronize' after 'napi_disable') 'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) -> -> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' -> 'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING) Fix this by calling 'ath10k_halt' in ath10k_core_restart itself as it makes more sense before informing mac80211 to restart h/w Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting' Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support") Cc: <stable@vger.kernel.org> # v4.9 Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-12-01ath10k: fix TLV set regdomain commandErik Stromdahl
There is a typo bug in the current implementation of ath10k_wmi_tlv_op_gen_pdev_set_rd. The conformance test limits are not set up properly. The two arguments ctl2g and ctl5g were not used at all. Instead, the regdomain arguments rd2g and rd5g were used for the ctl settings as well. Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-11-27Merge tag 'wireless-drivers-next-for-davem-2016-11-25' 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.10 Major changes: iwlwifi * finalize and enable dynamic queue allocation * use dev_coredumpmsg() to prevent locking the driver * small fix to pass the AID to the FW * use FW PS decisions with multi-queue ath9k * add device tree bindings * switch to use mac80211 intermediate software queues to reduce latency and fix bufferbloat wl18xx * allow scanning in AP mode ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-23ath10k: fix monitor vdev for receiving other bss framesManoharan, Rajkumar
In order to receive other BSS entries in mesh mode, Monitor vdev is created whenever filter flag is set with OTHER_BSS. Recently it is root caused that setting promisc filter for Mesh interface is causing performance and stability issues. To fix this issue, firmware will configure appropriate rxfilters by default for mesh vdev during vdev creation. This change fixes monitor vdev creation based on firmware IE Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-11-23ath10k: add support for per sta tx bitrateAnilkumar Kolli
Per STA tx bitrate info is filled from peer stats. Export per sta txrate info to cfg80211/nl80211 Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-11-23ath10k: add per peer htt tx stats support for 10.4Anilkumar Kolli
Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS' event, Firmware sends one HTT event for every four PPDUs. HTT payload has success pkts/bytes, failed pkts/bytes, retry pkts/bytes and rate info per ppdu. Peer stats are enabled through 'WMI_SERVICE_PEER_STATS', which are nowadays enabled by default. Parse peer stats and update the tx rate information per STA. tx rate, Peer stats are tested on QCA4019 with Firmware version 10.4-3.2.1-00028. Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-11-23ath10k: add spectral scan support to wmi-tlvMichal Kazior
Command structure and event flow doesn't seem to be any different compared to existing implementation for other firmware branches. This patch effectively adds in-driver support for spectral scanning on QCA61x4 and QCA9377. Tested QCA9377 w/ WLAN.TF.1.0-00267-1. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-11-23ath10k: fix null deref on wmi-tlv when trying spectral scanMichal Kazior
WMI ops wrappers did not properly check for null function pointers for spectral scan. This caused null dereference crash with WMI-TLV based firmware which doesn't implement spectral scan. The crash could be triggered with: ip link set dev wlan0 up echo background > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl The crash looked like this: [ 168.031989] BUG: unable to handle kernel NULL pointer dereference at (null) [ 168.037406] IP: [< (null)>] (null) [ 168.040395] PGD cdd4067 PUD fa0f067 PMD 0 [ 168.043303] Oops: 0010 [#1] SMP [ 168.045377] Modules linked in: ath10k_pci(O) ath10k_core(O) ath mac80211 cfg80211 [last unloaded: cfg80211] [ 168.051560] CPU: 1 PID: 1380 Comm: bash Tainted: G W O 4.8.0 #78 [ 168.054336] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014 [ 168.059183] task: ffff88000c460c00 task.stack: ffff88000d4bc000 [ 168.061736] RIP: 0010:[<0000000000000000>] [< (null)>] (null) ... [ 168.100620] Call Trace: [ 168.101910] [<ffffffffa03b9566>] ? ath10k_spectral_scan_config+0x96/0x200 [ath10k_core] [ 168.104871] [<ffffffff811386e2>] ? filemap_fault+0xb2/0x4a0 [ 168.106696] [<ffffffffa03b97e6>] write_file_spec_scan_ctl+0x116/0x280 [ath10k_core] [ 168.109618] [<ffffffff812da3a1>] full_proxy_write+0x51/0x80 [ 168.111443] [<ffffffff811957b8>] __vfs_write+0x28/0x120 [ 168.113090] [<ffffffff812f1a2d>] ? security_file_permission+0x3d/0xc0 [ 168.114932] [<ffffffff8109b912>] ? percpu_down_read+0x12/0x60 [ 168.116680] [<ffffffff811965f8>] vfs_write+0xb8/0x1a0 [ 168.118293] [<ffffffff81197966>] SyS_write+0x46/0xa0 [ 168.119912] [<ffffffff818f2972>] entry_SYSCALL_64_fastpath+0x1a/0xa4 [ 168.121737] Code: Bad RIP value. [ 168.123318] RIP [< (null)>] (null) Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-11-23ath10k: remove set/get_tsf ieee80211_opsPedersen, Thomas
Neither of these did the right thing: - get_tsf just returned 0 - set_tsf assumed a simple offset was applied against get_tsf(), which works, except in the case of calculating TSF from rx_mactime (actual TSF). Just remove them for now. We can reimplement set_tsf in terms of TSF increment/decrement in the future if get_tsf is ever supported by FW. Signed-off-by: Thomas Pedersen <twp@qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-11-23ath10k: implement offset_tsf ieee80211_opPedersen, Thomas
Current set_tsf is implemented in terms of TSF_INCREMENT only. Instead support new WMI command TSF_DECREMENT and export these through offset_tsf. Advantage is we get more accurate TSF adjustments, and don't calculate wrong offset in case absolute TSF was calculated from rx_mactime (actual TSF). The new WMI command is available in firmware 10.4-3.2.1-00033 for QCA4019 chips. Old drivers on new firmware or vice versa shouldn't be a problem since get/set tsf logic was already broken. Signed-off-by: Thomas Pedersen <twp@qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-11-23ath10k: advertize hardware packet loss mechanismRajkumar Manoharan
Indicate hardware (or firmware) supports that CQM packet-loss report will be generated based on station kickout algorithm. As of now mac80211 tracks connection loss by missing msdu counts (50) whereas ath10k firmware tracks them by missing ppdus (+ BAR tries). While firmware is trying to adapt its rate table, mac80211 might send out low_ack event to hostapd. This is causing frequent connect and disconnect iteration under noisy environment or when station is roaming around. Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>