In order to preserve the connection in suspend/resume flow,
wil6210 host allows going to PCIe D3hot state in suspend,
instead of performing a full wil6210 device reset. This
requires the platform ability to initiate wakeup in case of
RX data. To check that, a new platform API is added.
In addition, add cfg80211 suspend/resume callbacks
implementation.
Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

After calling platform_ops.uninit() it is still possible to invoke
platform callbacks.
To prevent this, zero platform_ops right after invoking uninit.
Signed-off-by: Dedy Lansky <qca_dlansky@qca.qualcomm.com>
Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

QCA9888 supports VHT80 with 2x2. But it only support 1x1 with VHT160 or
VHT80+80. Inform userspace and the the QCA firmware about that limitation
whenever VHT80+80 or VHT160 is configured.
Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
[kvalo@qca.qualcomm.com: use hw_params]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

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>

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>

Trivial fix to spelling mistake in ath6kl_dbg debug message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Steve deRosier <derosier@gmail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Report per chain RSSI to mac80211.
Signed-off-by: Norik Dzhandzhapanyan <norikd@gmail.com>
[kvalo@qca.qualcomm.com: fix conflicts and style]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Define structures for the copy engine ctrl/misc registers,
that includes CE CMD halt, watermark source, watermark destination,
host IE ring, source, destination and dmax ring.

This adds support to avoid the conditional compilation,
code optimization and dynamic configuration of the copy engine
register map for respective hardware bus interface.
Signed-off-by: Sarada Prasanna Garnayak <c_sgarna@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

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>

QCA99X0, QCA9888, QCA9984 supports calibration data in
either OTP or DT/pre-cal file. Current ath10k supports
Calibration data from OTP only.

If caldata is loaded from DT/pre-cal file, fetching board id
and applying calibration parameters like tx power gets failed.

error log:
[   15.733663] ath10k_pci 0000:01:00.0: failed to fetch board file: -2
[   15.741474] ath10k_pci 0000:01:00.0: could not probe fw (-2)

This patch adds calibration data support from DT/pre-cal
file.  Below parameters are used to get board id and
applying calibration parameters from cal data.

		EEPROM[OTP]	FLASH[DT/pre-cal file]
Cal param	0x700		0x10000
Board id	0x10		0x8000

Tested on QCA9888 with pre-cal file.
Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k firmware checks nbytes == 0 as part of determining if DMA
has completed successfully.  To help make this work more often,
have the driver initialize nbytes to zero when freeing the descriptor
slot.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

This lets one have a clue that maybe timeouts are happening
when we just aren't waiting long enough.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

When testing a 9888 chipset NIC, I notice it often takes
almost 2 seconds, and then many times OTP fails, probably due
to the two-second timeout.

[ 2269.841842] ath10k_pci 0000:05:00.0: bmi cmd took: 1984 jiffies (HZ: 1000), rv: 0
[ 2273.608185] ath10k_pci 0000:05:00.0: bmi cmd took: 1986 jiffies (HZ: 1000), rv: 0
[ 2277.294732] ath10k_pci 0000:05:00.0: bmi cmd took: 1989 jiffies (HZ: 1000), rv: 0

So, increase the BMI timeout to 3 seconds.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

This reverts commit b0578865 ("ath10k: do not use coherent memory for
allocated device memory chunks") in 2015 which converted this allocation from
dma_map_coherent() to kzalloc() / dma_map_single().

The current problem manifests when using later model NICs with larger
(>700KiB) scratch spaces in memory.  Although the kzalloc call
succeeds, the software IOMMU TLB code (via dma_map_single()) panics
because it can't find 700KiB of linear physmem bounce buffers for DMA.
Now, this is a bit of a silly failure mode for the dma map API,
but it's what we currently have to play with.

In these cases, doing kzalloc() works fine, but the dma_map_single()
call fails.

After chatting with Linus briefly about this, it indeed should be
using dma_alloc_coherent() for doing larger device memory allocation
that requires some kind of physical address mapping.

You're not supposed to be using kzalloc and dma_map_* calls for
large memory regions, and I'm guessing not for long-held mappings
either.  Typically dma mappings should be temporary for DMA,
not long held like these.

Now, since hopefully the major annoying underlying problem has also been
addressed (ie, ath10k is no longer tears down all of these allocations
and reallocates them every time the vdevs are brought down) fragmentation
should stop being such a touchy issue.  If it is though, using
dma_alloc_coherent() use gets us access to the CMB APIs too relatively
easily and ideally we would be allocating memory early in boot for
exactly these reasons.
Signed-off-by: Adrian Chadd <adrian@FreeBSD.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

wil6210 devices can have different PCIe bar size, hence get the
bar size from PCIe device instead of using a constant bar size.
Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Set resetting flag early when stopping AP to avoid
disconnect events as a result of disconnect command
sent during AP stop procedure.
Signed-off-by: Hamad Kadmany <qca_hkadmany@qca.qualcomm.com>
Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Module parameter allows to load specific FW used
for FTM testing.
Signed-off-by: Hamad Kadmany <qca_hkadmany@qca.qualcomm.com>
Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Added vendor commands for low level control over
RF sectors. It allows user space a fine-grained control
over RF characteristics for TX and RX, such as direction
and gain of TX/RX. Main usages are debugging and diagnostics,
but also operational use cases.
API includes getting/setting a specific RF sector
configuration, as well as getting/setting the selected
sector which is used to communicate with a station.
Signed-off-by: Lior David <qca_liord@qca.qualcomm.com>
Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

The QCA4019 firmware 10.4-3.2.1-00050 reports only HT MCS rates between
0-9. But 802.11n MCS rates can be larger than that. For example a 2x2
device can send with up to MCS 15.

The firmware encodes the higher MCS rates using the NSS field. The actual
calculation is not documented by QCA but it seems like the NSS field can be
mapped for HT rates to following MCS offsets:

 * NSS 1: 0
 * NSS 2: 8
 * NSS 3: 16
 * NSS 4: 24

This offset therefore has to be added for HT rates before they are stored
in the rate_info struct.

Fixes: cec17c38 ("ath10k: add per peer htt tx stats support for 10.4")
Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

The array fields in struct wmi_start_scan_arg that are checked here are
fixed size arrays so they can never be NULL.

Addresses-Coverity-ID: 1260031
Cc: Arend Van Spriel <arend.vanspriel@broadcom.com>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath.git patches for 4.13. Major changes:

ath10k

* add initial SDIO support (still work in progress)

When driver fail to reset card ah->curchan value stay NULL. When
later driver try to update tx power it oops by using ah->curchan
(calltrace is shown below).

This problem were reported at various places and for some it was
fixed by making ath9k_hw_chip_reset() do not fail. I have this bug
report on some oldish RHEL kernel with AR9285, however it's hard to
debug where reset fail when kernel OOPS, so I think this patch
should be applied. Hopefully ah->curchan is not used unconditionally
on other places until is initialized on ath9k_config().

ath: phy0: Chip reset failed
ath: phy0: Unable to reset hardware; reset status -22 (freq 2412 MHz)
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<f8a35585>] ath9k_hw_set_txpowerlimit+0x25/0x80 [ath9k_hw]
Oops: 0000 [#1] SMP
<snip>
Call Trace:
 [<f8aac1aa>] ? ath9k_cmn_update_txpow+0x1a/0x30 [ath9k_common]
 [<f8cf4f4e>] ? ath_complete_reset+0x4e/0x130 [ath9k]
 [<f8cf54d7>] ? ath9k_start+0x127/0x1e0 [ath9k]
 [<f8c2e52f>] ? ieee80211_do_open+0x30f/0x910 [mac80211]
 [<c07bd96d>] ? dev_open+0x8d/0xf0
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

The array field eeprom_data in struct th9k_platform_data
is a fixed size array so it can never be NULL.

Addresses-Coverity-ID: 1364903
Cc: Arend Van Spriel <arend.vanspriel@broadcom.com>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Use memdup_user() helper instead of open-coding to simplify the code.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

The AR5K_EEPROM_READ macro returns with -EIO if a read error
occurs causing a memory leak on the allocated buffer buf. Fix
this by explicitly calling ath5k_hw_nvram_read and exiting on
the via the freebuf label that performs the necessary free'ing
of buf when a read error occurs.

Detected by CoverityScan, CID#1248782 ("Resource Leak")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

It's spelled hardware, not harware.
Signed-off-by: Ammly Fredrick <ammlyf@gmail.com>
[kvalo@qca.qualcomm.com: improve commit log]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

An issue was found brcmfmac driver in which a skbuff in .start_xmit()
callback was actually cloned. So instead of checking for sufficient
headroom it should also be writable. Hence use skb_cow_head() to
check and expand the headroom appropriately.
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Tested-by: Steve deRosier <derosier@gmail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Add the missing endianness conversions to a debug statement printing
the USB device-descriptor bcdUSB field during probe.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

These are already handled by mwifiex_shutdown_sw() and
mwifiex_reinit_sw(). Ideally, we'll kill the flag entirely eventually,
as I suspect it breeds race conditions.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

These pointers are retrieved via container_of(). There's no way they are
NULL.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

We're using 'adapter' right before calling this. Stop being
unnecessarily paranoid.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

If mwifiex_shutdown_drv() is racing with another mwifiex_shutdown_drv(),
we *really* have problems. Kill the lock.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

When removing or resetting an mwifiex device, we don't remember to free
the saved beacon buffer. Use the (somewhat misleadingly-named)
mwifiex_free_priv() helper to handle this.

Noticed by kmemleak during tests:

echo 1 > /sys/bus/pci/devices/.../reset

unreferenced object 0xffffffc09d034a00 (size 256):
...
  backtrace:
    [<ffffffc0003cdce4>] create_object+0x228/0x3c4
    [<ffffffc000c0b9d8>] kmemleak_alloc+0x54/0x88
    [<ffffffc0003c0848>] __kmalloc+0x1cc/0x2dc
    [<ffffffbffc1500c4>] mwifiex_save_curr_bcn+0x80/0x308 [mwifiex]
    [<ffffffbffc1516b8>] mwifiex_ret_802_11_associate+0x4ec/0x5fc [mwifiex]
    [<ffffffbffc15da90>] mwifiex_process_sta_cmdresp+0xaf8/0x1fa4 [mwifiex]
    [<ffffffbffc1411e0>] mwifiex_process_cmdresp+0x40c/0x510 [mwifiex]
    [<ffffffbffc13b8f4>] mwifiex_main_process+0x4a4/0xb00 [mwifiex]
    [<ffffffbffc13bf84>] mwifiex_main_work_queue+0x34/0x40 [mwifiex]
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

mwifiex_exec_next_cmd() seems to have a classic TOCTOU race, where we
drop the list lock in between retrieving the next command and deleting
it from the list. This potentially leaves room for someone else to also
retrieve / steal this node from the list (e.g.,
mwifiex_cancel_all_pending_cmd()).

Let's keep holding the lock while we do our 'ps_state' sanity checks.
There should be no harm in continuing to hold this lock for a bit more.

Noticed only by code inspection.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

The mwifiex_11n_delba() function walked the rx_reorder_tbl_ptr without
holding the lock, which was an obvious violation.

Grab the lock.

NOTE: we hold the lock while calling mwifiex_send_delba().  There's also
several callers in 11n_rxreorder.c that hold the lock and the comments
in the struct sound just like very other list/lock pair -- as if the
lock should definitely be help for all operations like this.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Just like in the previous patch ("mwifiex: Don't release
tx_ba_stream_tbl_lock while iterating"), in
mwifiex_cancel_all_pending_cmd() we were itearting over a list protected
by a spinlock.  Again, it is not safe to release the spinlock while
iterating.  Don't do it.

Luckily in this case there should be no need to release the spinlock.
This is evidenced by:

1. The only function called while the spinlock was released was
   mwifiex_recycle_cmd_node()
2. Aside from atomic functions (which are safe to call), the only
   function called by mwifiex_recycle_cmd_node() was
   mwifiex_insert_cmd_to_free_q().
3. It can be seen in mwifiex_cancel_pending_scan_cmd() that it's OK to
   call mwifiex_insert_cmd_to_free_q() while holding a different
   spinlock (scan_pending_q_lock), so in general holding a spinlock
   should be OK.
4. It doesn't appear that mwifiex_insert_cmd_to_free_q() has any
   interaction with the cmd_pending_q_lock

No known bugs are fixed with this change, but as with other similar
changes this could fix random list corruption.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Despite the macro list_for_each_entry_safe() having the word "safe" in
the name, it's still not actually safe to release the list spinlock
while iterating over the list.  The "safe" in the macro name actually
only means that it's safe to delete the current entry while iterating
over the list.

Releasing the spinlock while iterating over the list means that someone
else could come in and adjust the list while we don't have the
spinlock.  If they do that it can totally mix up our iteration and fully
corrupt the list.  Later iterating over a corrupted list while holding a
spinlock and having IRQs off can cause all sorts of hard to debug
problems.

As evidenced by the other call to
mwifiex_11n_delete_tx_ba_stream_tbl_entry() in
mwifiex_11n_delete_all_tx_ba_stream_tbl(), it's actually safe to skip
the spinlock release.  Let's do that.

No known problems are fixed by this patch, but it could fix all sorts of
weird problems and it should be very safe.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

If we fail to add an interface in mwifiex_add_virtual_intf(), we might
hit a BUG_ON() in the networking code, because we didn't tear things
down properly. Among the problems:

 (a) when failing to allocate workqueues, we fail to unregister the
     netdev before calling free_netdev()
 (b) even if we do try to unregister the netdev, we're still holding the
     rtnl lock, so the device never properly unregistered; we'll be at
     state NETREG_UNREGISTERING, and then hit free_netdev()'s:
	BUG_ON(dev->reg_state != NETREG_UNREGISTERED);
 (c) we're allocating some dependent resources (e.g., DFS workqueues)
     after we've registered the interface; this may or may not cause
     problems, but it's good practice to allocate these before registering
 (d) we're not even trying to unwind anything when mwifiex_send_cmd() or
     mwifiex_sta_init_cmd() fail

To fix these issues, let's:

 * add a stacked set of error handling labels, to keep error handling
   consistent and properly ordered (resolving (a) and (d))
 * move the workqueue allocations before the registration (to resolve
   (c); also resolves (b) by avoiding error cases where we have to
   unregister)

[Incidentally, it's pretty easy to interrupt the alloc_workqueue() in,
e.g., the following:

  iw phy phy0 interface add mlan0 type station

by sending it SIGTERM.]

This bugfix covers commits like commit 7d652034 ("mwifiex: channel
switch support for mwifiex"), but parts of this bug exist all the way
back to the introduction of dynamic interface handling in commit
93a1df48 ("mwifiex: add cfg80211 handlers add/del_virtual_intf").

Cc: <stable@vger.kernel.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

This code was duplicated as part of the PCIe FLR code added to this
driver. Let's de-duplicate it to:

 * make things easier to read (mwifiex_pcie_free_buffers() now has a
   corresponding mwifiex_pcie_alloc_buffers())
 * reduce likelihood of bugs
 * make error logging equally verbose
 * save lines of code!

Also drop some of the commentary that isn't really needed.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>