kernel/linux.git/drivers/net/wireless/ath, branch v4.8.16

ath10k: cache calibration data when the core is stopped

2016-11-10T15:38:53+00:00

commit f67b107d4ceddcf7aa65b706aaaf50d68edb52a6 upstream. Commit 0b8e3c4ca29f ("ath10k: move cal data len to hw_params") broke retrieving the calibration data from cal_data debugfs file. The length of file was always zero. The reason is: static ssize_t ath10k_debug_cal_data_read(struct file *file, char __user *user_buf, size_t count, loff_t *ppos) { struct ath10k *ar = file->private_data; void *buf = file->private_data; This is obviously bogus, private_data cannot contain both struct ath10k and the buffer. Fix it by caching calibration data to ar->debug.cal_data. This also allows it to be accessed when the device is not active (interface is down). The cal_data buffer is fixed size because during the first firmware probe we don't yet know what will be the lenght of the calibration data. It was simplest just to use a fixed length. There's a WARN_ON() in ath10k_debug_cal_data_fetch() if the buffer is too small. Tested with qca988x and firmware 10.2.4.70.56. Reported-by: Nikolay Martynov Fixes: 0b8e3c4ca29f ("ath10k: move cal data len to hw_params") Signed-off-by: Marty Faltesek [kvalo@qca.qualcomm.com: improve commit log and minor other changes] Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

Revert "ath9k_hw: implement temperature compensation support for AR9003+"

2016-11-10T15:38:53+00:00

commit 304e5ac118cc351eb047b6c433a89e13ea7259cf upstream. This reverts commit 171f6402e4aa ("ath9k_hw: implement temperature compensation support for AR9003+"). Some users report that this commit causes a regression in performance under some conditions. Fixes: 171f6402e4aa ("ath9k_hw: implement temperature compensation support for AR9003+") Signed-off-by: Felix Fietkau [kvalo@qca.qualcomm.com: improve commit log] Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

ath10k: fix throughput regression in multi client mode

2016-10-31T11:02:09+00:00

commit 18f53fe0f30331e826b075709ed7b26b9283235e upstream. commit 7a0adc83f34d ("ath10k: improve tx scheduling") is causing severe throughput drop in multi client mode. This issue is originally reported in veriwave setup with 50 clients with TCP downlink traffic. While increasing number of clients, the average throughput drops gradually. With 50 clients, the combined peak throughput is decreased to 98 Mbps whereas reverting given commit restored it to 550 Mbps. Processing txqs for every tx completion is causing overhead. Ideally for management frame tx completion, pending txqs processing can be avoided. The change partly reverts the commit "ath10k: improve tx scheduling". Processing pending txqs after all skbs tx completion will yeild enough room to burst tx frames. Fixes: 7a0adc83f34d ("ath10k: improve tx scheduling") Signed-off-by: Rajkumar Manoharan Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

ath10k: fix reporting channel survey data

2016-10-31T11:02:09+00:00

commit 77eb3d693182b4eaa88c6ba406fbb92b1f1bd636 upstream. When user requests for survey dump data, driver is providing wrong survey information. This information we sent is the survey data that we have collected during previous user request. This issue occurs because we request survey dump for wrong channel. With this change, we correctly display the correct and current survey information to userspace. Fixes: fa7937e3d5c2 ("ath10k: update bss channel survey information") Signed-off-by: Ashok Raj Nagarajan Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

ath10k: fix sending frame in management path in push txq logic

2016-10-31T11:02:09+00:00

commit e4fd726f21cdae0dc9cea6cbfcb7e27f21393f88 upstream. In the wake tx queue path, we are not checking if the frame to be sent takes management path or not. For eg. QOS null func frame coming here will take the management path. Since we are not incrementing the descriptor counter (num_pending_mgmt_tx) w.r.t tx management, on tx completion it is possible to see negative values. When the above counter reaches a negative value, we will not be sending a probe response out. if (is_presp && ar->hw_params.max_probe_resp_desc_thres < htt->num_pending_mgmt_tx) For IPQ4019, max_probe_resp_desc_thres (u32) is 24 is compared against num_pending_mgmt_tx (int) and the above condtions comes true if the counter is negative and we drop the probe response. To avoid this, check on the wake tx queue path as well for the tx path of the frame and increment the appropriate counters Fixes: cac085524cf1 "ath10k: move mgmt descriptor limit handle under mgmt_tx" Signed-off-by: Ashok Raj Nagarajan Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

ath10k: Add WMI_SERVICE_PERIODIC_CHAN_STAT_SUPPORT wmi service

2016-10-31T11:02:09+00:00

commit 64ed5771aca2fcfb8ea440fc679741054011fd7e upstream. WMI_SERVICE_PERIODIC_CHAN_STAT_SUPPORT service has missed in the commit 7e247a9e88dc ("ath10k: add dynamic tx mode switch config support for qca4019"). This patch adds the service to avoid mismatch between host and target. Fixes: 7e247a9e88dc ("ath10k: add dynamic tx mode switch config support for qca4019") Signed-off-by: Tamizh chelvam Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

ath10k: fix copy engine 5 destination ring stuck

2016-10-28T07:45:18+00:00

commit 0628467f97b5227755428bac10a68257322f7e34 upstream. Firmware is running watchdog timer for tracking copy engine ring index and write index. Whenever both indices are stuck at same location for given duration, watchdog will be trigger to assert target. While updating copy engine destination ring write index, driver ensures that write index will not be same as read index by finding delta between these two indices (CE_RING_DELTA). HTT target to host copy engine (CE5) is special case where ring buffers will be reused and delta check is not applied while updating write index. In rare scenario, whenever CE5 ring is full, both indices will be referring same location and this is causing CE ring stuck issue as explained above. This issue is originally reported on IPQ4019 during long hour stress testing and during veriwave max clients testsuites. The same issue is also observed in other chips as well. Fix this by ensuring that write index is one less than read index which means that full ring is available for receiving data. Tested-by: Tamizh chelvam Signed-off-by: Rajkumar Manoharan Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

carl9170: fix debugfs crashes

2016-10-22T10:40:22+00:00

commit 6ee6d1cb391ca85b419f8d18bdfb1f020a5e859c upstream. Ben Greear reported: > I see lots of instability as soon as I load up the carl9710 NIC. > My application is going to be poking at it's debugfs files... > > BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0 > [carl9170] at addr 0xffff8801bc1208b0 > Read of size 8 by task btserver/5888 > ======================================================================= > BUG kmalloc-256 (Tainted: G W ): kasan: bad access detected > ----------------------------------------------------------------------- > > INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772 >... This breakage was caused by the introduction of intermediate fops in debugfs by commit 9fd4dcece43a ("debugfs: prevent access to possibly dead file_operations at file open") Thankfully, the original/real fops are still available in d_fsdata. Reported-by: Ben Greear Signed-off-by: Christian Lamparter Signed-off-by: Greg Kroah-Hartman

ath9k: bring back direction setting in ath9k_{start_stop}

2016-09-07T13:21:04+00:00

A regression was introduced in commit id 79d4db1214a ("ath9k: cleanup led_pin initial") that broken the WLAN status led on my laptop with AR9287 after suspending and resuming. Steps to reproduce: * Suspend (laptop) * Resume (laptop) * Observe that the WLAN led no longer turns ON/OFF depending on the status and is always red Even though for my case it only needs to be set to OUT in ath9k_start but for consistency bring back the IN direction setting as well. Fixes: 79d4db1214a0 ("ath9k: cleanup led_pin initial") Cc: Miaoqing Pan Cc: Kalle Valo Cc: # 4.7+ Link: https://bugzilla.kernel.org/show_bug.cgi?id=151711 Signed-off-by: Giedrius Statkevičius [kvalo@qca.qualcomm.com: improve commit log] Signed-off-by: Kalle Valo

ath9k: fix AR5416 access GPIO warning

2016-09-02T16:32:04+00:00

The warning was seen on AR5416 chip, which invoke ath9k_hw_gio_get() before the GPIO initialized correctly. WARNING: CPU: 1 PID: 1159 at ~/drivers/net/wireless/ath/ath9k/hw.c:2776 ath9k_hw_gpio_get+0x148/0x1a0 [ath9k_hw] ... CPU: 1 PID: 1159 Comm: systemd-udevd Not tainted 4.7.0-rc7-aptosid-amd64 #1 aptosid 4.7~rc7-1~git92.slh.3 Hardware name: /DH67CL, BIOS BLH6710H.86A.0160.2012.1204.1156 12/04/2012 0000000000000286 00000000f912d633 ffffffff81290fd3 0000000000000000 0000000000000000 ffffffff81063fd4 ffff88040c6dc018 0000000000000000 0000000000000002 0000000000000000 0000000000000100 ffff88040c6dc018 Call Trace: [] ? dump_stack+0x5c/0x79 [] ? __warn+0xb4/0xd0 [] ? ath9k_hw_gpio_get+0x148/0x1a0 [ath9k_hw] Signed-off-by: Miaoqing Pan Reported-by: Stefan Lippers-Hollmann Tested-by: Stefan Lippers-Hollmann Signed-off-by: Kalle Valo