This overrides whatever regulatory the device
EEPROM contains and uses what the platform says
instead - in this implementation the ACPI driver.

In case the hint is not programmed or corrupted (0xffff)
the device falls back to the eeprom programmed settings.
Signed-off-by: NBartosz Markowski <bartosz.markowski@tieto.com>
[kvalo@qca.qualcomm.com: remove ifdef, change error handling, change info messages to dbg]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

This will be helpful for drivers that can acquire
alpha2 regulatory codes.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NBartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

During offchannel scan, iw survey dump shows wrong values.
Fix this by assigning cycle counter wranarround type for
QCA9888 and QCA9884, they share same config with QCA4019.
Signed-off-by: NAnilkumar Kolli <akolli@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

This patch helps to get the TPC stats for 10.4 fw variants.
Signed-off-by: NMaharaja Kennadyrajan <c_mkenna@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

When building with W=1, we got one warning as belows:
drivers/net/wireless/ath/ath6kl/wmi.c:3509:6: warning: variable ‘ret’
set but not used [-Wunused-but-set-variable]

At the end of ath6kl_wmi_set_pvb_cmd, it is returned by 0 regardless of
return value of ath6kl_wmi_cmd_send.
This patch fixes return value from 0 to ret that has result of
ath6kl_wmi_cmd_send execution.
Signed-off-by: NChaehyun Lim <chaehyun.lim@gmail.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

ath9k RNG will dominates all the noise sources from the real HW
RNG, disable it by default. But we strongly recommand to enable
it if the system without HW RNG, especially on embedded systems.
Signed-off-by: NMiaoqing Pan <miaoqing@codeaurora.org>
Acked-by: NStephan Mueller <smueller@chronox.de>
Acked-by: NStephan Mueller <smueller@chronox.de>
Reviewed-by: NJason Cooper <jason@lakedaemon.net>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

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.

Cc: stable@vger.kernel.org
Tested-by: NTamizh chelvam <c_traja@qti.qualcomm.com>
Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Ignore processing further in SWBA event scheduled for a vif, if mac80211
has marked the particular vif for stop beaconing and brought the vdev
down in 'ath10k_control_beaconing'. This should potentially avoid ath10k
warning/error messages while running continuous wifi down/up with max
number of vaps configured. Found this change during code walk through
and going through other beacon configuration related functions in ath10k
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Fix to return a negative error code from the error handling case
instead of 0, as done elsewhere in function ath10k_ahb_probe() or
ath10k_ahb_resource_init().
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

The (1 << x) - 1 trick won't work when you
are trying to fill up all 64 bits, so add special
case for that.
Signed-off-by: NBen Greear <greearb@candelatech.com>
[kvalo@qca.qualcomm.com: remove the sentence about moving limits]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

They are not necessarily named in an intuitive manner,
so at least add some comments to help the next person.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Chipset from QCA99X0 onwards (QCA99X0, QCA9984, QCA4019 & future)
rx_hdr_status is not padded to align in 4-byte boundary. Define a
new hw_params field to handle different alignment behaviour between
different hw. This patch fixes improper retrieval of rfc1042 header
with QCA4019. This patch along with "ath10k: Properly remove padding
from the start of rx payload" will fix traffic failure in ethernet
decap mode for QCA4019.
Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Since reset_control_get() never returns NULL, we can use IS_ERR()
instead of IS_ERR_OR_NULL().  The return statements can be simpler
as well.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Use the managed variant of reset_control_get() to simplify the
failure path and the .remove callback.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Use the managed variant of clk_get() to simplify the failure path
and the .remove callback.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Correct some trivial comment typos.
Remove unnecessary parentheses in a long line.
Signed-off-by: NJoe Perches <joe@perches.com>
[kvalo@qca.qualcomm.com: drop the change for return]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

For structure types defined in the same file or local header files, find
top-level static structure declarations that have the following
properties:
1. Never reassigned.
2. Address never taken
3. Not passed to a top-level macro call
4. No pointer or array-typed field passed to a function or stored in a
variable.
Declare structures having all of these properties as const.

Done using Coccinelle.
Based on a suggestion by Joe Perches <joe@perches.com>.
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

hw_4addr_pad was added to handle different types of padding
in 4-address rx frame. But this padding is not very specific
to 4-address, it can happen even with three address + ethernet
decap mode. Since the  padding information can be obtained
through Rx desc for QCA99X0 and newer chips, this hw_param
is not needed any more.
Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

In QCA99X0 (QCA99X0, QCA9984, QCA9888 and QCA4019) family chips,
hw adds padding at the begining of the rx payload to make L3
header 4-byte aligned. In the chips doing this type of padding,
the number of bytes padded will be indicated through msdu_end:info1.
Define a hw_rx_desc_ops wrapper to retrieve the number of padded
bytes and use this while doing undecap. This should fix padding
related issues with ethernt decap format with QCA99X0, QCA9984,
QCA9888 and QCA4019 hw.
Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
[Rename operations to hw_ops for other purposes]
Signed-off-by: NBenjamin Berg <benjamin@sipsolutions.net>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

There are slight differences in Rx hw descriptor information
among different chips. So far driver does not use those new
information for any functionalities, but there is one important
information which is available from QCA99X0 onwards to indicate
the number of bytes that hw padded at the begining of the rx
payload and this information is needed to undecap the rx
packet. Add an abstraction for Rx desc to make use of the
new desc information available. The callback that this patch
defines to retrieve the padding bytes will be used in follow-up
patch.
Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
[Rename operations to hw_ops for other purposes]
Signed-off-by: NBenjamin Berg <benjamin@sipsolutions.net>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

This is to prepare for rx descriptor abstraction where we'll
be dereferencing ath10k_hw_params member in hw.h. Moreover
hw.h looks more suitable to house ath10k_hw_params definition
than core.h
Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Helps to know the sta pointer.
Signed-off-by: NBen Greear <greearb@candelatech.com>
[kvalo@qca.qualcomm.com: add %pK and remove the colon]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

IFTYPE_MESH_POINT need to rely on these for accurate path
selection metrics. Other modes will probably also find
them useful. Enabling peer stats has the side effect of
reducing max number of STAs from 128 to 118. There should
be negligible performance impact.

If users really need 128 STAs and don't mind losing out on
peer stats, they can still disable them:

echo 0 > debugfs/ieee80211/phyn/ath10k/peer_stats
Signed-off-by: NThomas Pedersen <twp@qca.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Trival fix to remove unused variable ar_pci in ath10k_pci_tx_pipe_cleanup
when building with W=1:
drivers/net/wireless/ath/ath10k/pci.c:1696:21: warning: variable
'ar_pci' set but not used [-Wunused-but-set-variable]
Signed-off-by: NChaehyun Lim <chaehyun.lim@gmail.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

caldata is not being free'd on the error exit path, causing
a memory leak and data definitely should not be freed. Free
caldata instead of data.

Thanks to Kalle Valo for spotting that data should not be
free'd.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

carl9170_usb_stop() is used from several places to flush and cleanup any
pending work. The normal pattern is to send a request and wait for the
irq handler to call complete(). The completion is not reinitialized
during normal operation and as the old comment indicates it is important
to keep calls to wait_for_completion_timeout() and complete() balanced.

Calling complete_all() brings this equilibirum out of balance and needs
to be fixed by a reinit_completion(). But that opens a small race
window. It is possible that the sequence of complete_all(),
reinit_completion() is faster than the wait_for_completion_timeout() can
do its work. The wake up is not lost but the done counter test is after
reinit_completion() has been executed. The only reason we don't see
carl9170_exec_cmd() hang forever is we use the timeout version of
wait_for_copletion().

Let's fix this by reinitializing the completion (that is just setting
done counter to 0) just before we send out an request. Now,
carl9170_usb_stop() can be sure a complete() call is enough to make
progess since there is only one waiter at max. This is a common pattern
also seen in various drivers which use completion.
Signed-off-by: NDaniel Wagner <daniel.wagner@bmw-carit.de>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

The ath6kl driver attempts to get the txpower value from the radio by first
clearing the existing stored value and then watching the value to become
non-zero.

APs allow setting client power to values from -127..127, but this radio
is not capable of setting values less then 0 and so will report txpower
as 0dbm for both negative and 0 client power values.

When the radio has txpower set to 0dbm txpower (equivalent to 1mw) the
ath6kl_cfg80211_get_txpower() function will remain in the
wait_event_interruptible_timeout() loop waiting for the value to be
non-zero, and will eventually timeout. This results in a 5 second delay in
response. However, the correct value of zero is eventually returned.

The 6004 defaults to 63dbm which is then limited by regulatory and
hardware limits with max of 18dbm (6003 max is 16dbm), therefore we can
use values larger then these to be able to determine when the value has
been updated.

To correct the issue, set the value to a nonsensical value (255) and wait
for it to change to the valid value.

Tested on both 6003 and 6004 based radios.  Return value of zero is
correctly returned in an expected amount of time (similar to when
returning non-zero values) when AP client power is set to both 0 and
negative values.
Signed-off-by: NEric Bentley <eric.bentley@lairdtech.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

The firmware crash dumps on the 6004 are the same as the 6003. Remove the
statement guarding it from dumping on the 6004.  Renamed the
REG_DUMP_COUNT_AR6003 to reflect support on both chips.
Signed-off-by: NDan Kephart <dan.kephart@lairdtech.com>
Reviewed-by: NSteve deRosier <steve.derosier@lairdtech.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

The constant "123", which is the number of elements in
mask_m / mask_p, is repeated several times in this function.

Replace memsets with array initialization, and replace a loop
conditional with ARRAY_SIZE() so that we don't repeat ourselves.
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Reviewed-by: NOleksij Rempel <linux@rempel-privat.de>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

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: fa7937e3 ("ath10k: update bss channel survey information")
Signed-off-by: NAshok Raj Nagarajan <arnagara@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

The error assigned does not seems to be used anywhere,
fixes nothing just a small cleanup
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

For non-aggregated frames, ath9k was leaving handling of powersave
filtered packets to mac80211. This can be too slow if the intermediate
queue is already filled with packets and mac80211 does not immediately
send a new packet via drv_tx().

Improve response time with filtered frames by triggering clearing the
powersave filter internally.
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

It removes the need for undoing the padding changes to skb->data and it
improves performance by eliminating one tx status lookup per MPDU in the
status path. It is also useful for preparing a follow-up fix to better
handle powersave filtering.

A side effect is that these counters, available via debugfs, become now invalid:

* dot11TransmittedFragmentCount
* dot11FrameDuplicateCount,
* dot11ReceivedFragmentCount
* dot11MulticastReceivedFrameCount
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
[kvalo@qca.qualcomm.com: add a note about counters, thanks to Zefir Kurtisi]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

commit 7a0adc83 ("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: 7a0adc83 ("ath10k: improve tx scheduling")
Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Add NAPI support for rx and tx completion. NAPI poll is scheduled
from interrupt handler. The design is as below

 - on interrupt
     - schedule napi and mask interrupts
 - on poll
   - process all pipes (no actual Tx/Rx)
   - process Rx within budget
   - if quota exceeds budget reschedule napi poll by returning budget
   - process Tx completions and update budget if necessary
   - process Tx fetch indications (pull-push)
   - push any other pending Tx (if possible)
   - before resched or napi completion replenish htt rx ring buffer
   - if work done < budget, complete napi poll and unmask interrupts

This change also get rid of two tasklets (intr_tq and txrx_compl_task).

Measured peak throughput with NAPI on IPQ4019 platform in controlled
environment. No noticeable reduction in throughput is seen and also
observed improvements in CPU usage. Approx. 15% CPU usage got reduced
in UDP uplink case.

DL: AP DUT Tx
UL: AP DUT Rx

IPQ4019 (avg. cpu usage %)

========
                TOT              +NAPI
              ===========      =============
TCP DL       644 Mbps (42%)    645 Mbps (36%)
TCP UL       673 Mbps (30%)    675 Mbps (26%)
UDP DL       682 Mbps (49%)    680 Mbps (49%)
UDP UL       720 Mbps (28%)    717 Mbps (11%)
Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

A regression was introduced in commit id 79d4db12 ("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: 79d4db12 ("ath9k: cleanup led_pin initial")
Cc: Miaoqing Pan <miaoqing@codeaurora.org>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: <stable@vger.kernel.org> # 4.7+
Link: https://bugzilla.kernel.org/show_bug.cgi?id=151711Signed-off-by: NGiedrius Statkevičius <giedrius.statkevicius@gmail.com>
[kvalo@qca.qualcomm.com: improve commit log]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

EEPROM size calculated in 16-bit words, so we should take into account
this fact during buffer allocation.

CC: Jiri Slaby <jirislaby@gmail.com>
CC: Nick Kossifidis <mickflemm@gmail.com>
CC: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: NSergey Ryazanov <ryazanov.s.a@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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:
      [<ffffffff81290fd3>] ? dump_stack+0x5c/0x79
      [<ffffffff81063fd4>] ? __warn+0xb4/0xd0
      [<ffffffffa0668fb8>] ? ath9k_hw_gpio_get+0x148/0x1a0 [ath9k_hw]
Signed-off-by: NMiaoqing Pan <miaoqing@codeaurora.org>
Reported-by: NStefan Lippers-Hollmann <s.l-h@gmx.de>
Tested-by: NStefan Lippers-Hollmann <s.l-h@gmx.de>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

We get 1 warning about global functions without a declaration
in the ath9k gpio driver when building with W=1:
drivers/net/wireless/ath/ath9k/gpio.c:25:6: warning: no previous prototype for 'ath_fill_led_pin' [-Wmissing-prototypes]

In fact, this function is only used in the file in which it is declared
and don't need a declaration, but can be made static.
so this patch marks it 'static'.
Signed-off-by: NBaoyou Xie <baoyou.xie@linaro.org>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>