This reverts commit 9ed4f916.

The commit introduced a regression that over read the ie with
the padding.

- the expected IE information

ath10k_pci 0000:03:00.0: found firmware features ie (1 B)
ath10k_pci 0000:03:00.0: Enabling feature bit: 6
ath10k_pci 0000:03:00.0: Enabling feature bit: 7
ath10k_pci 0000:03:00.0: features
ath10k_pci 0000:03:00.0: 00000000: c0 00 00 00 00 00 00 00

- the wrong IE with padding is read (0x77)

ath10k_pci 0000:03:00.0: found firmware features ie (4 B)
ath10k_pci 0000:03:00.0: Enabling feature bit: 6
ath10k_pci 0000:03:00.0: Enabling feature bit: 7
ath10k_pci 0000:03:00.0: Enabling feature bit: 8
ath10k_pci 0000:03:00.0: Enabling feature bit: 9
ath10k_pci 0000:03:00.0: Enabling feature bit: 10
ath10k_pci 0000:03:00.0: Enabling feature bit: 12
ath10k_pci 0000:03:00.0: Enabling feature bit: 13
ath10k_pci 0000:03:00.0: Enabling feature bit: 14
ath10k_pci 0000:03:00.0: Enabling feature bit: 16
ath10k_pci 0000:03:00.0: Enabling feature bit: 17
ath10k_pci 0000:03:00.0: Enabling feature bit: 18
ath10k_pci 0000:03:00.0: features
ath10k_pci 0000:03:00.0: 00000000: c0 77 07 00 00 00 00 00
Tested-by: NMike Lothian <mike@fireburn.co.uk>
Signed-off-by: NRyan Hsu <ryanhsu@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Some modern Ubiquiti devices contain a rebranded QCA988X rev2 with
a custom Ubiquiti vendor and device id. This patch adds support for
those devices, treating them as a QCA988X v2.
Signed-off-by: NTobias Schramm <tobleminer@gmail.com>
[kvalo@codeaurora.org: rebase, add missing fields in hw_params, fix a long line in pci.c:61]
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Checkpatch found these issues:

drivers/net/wireless/ath/ath10k/ce.h:324: Please use a blank line after function/struct/union/enum declarations
drivers/net/wireless/ath/ath10k/core.c:1321: Please don't use multiple blank lines
drivers/net/wireless/ath/ath10k/htt.h:1859: Please use a blank line after function/struct/union/enum declarations
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Validate ie_len after the alignment padding before access the buffer
to avoid potential overflow.
Signed-off-by: NRyan Hsu <ryanhsu@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

It was accidentally left out from the switch statement and target info was not
queried.
Signed-off-by: NErik Stromdahl <erik.stromdahl@gmail.com>
[kvalo@codeaurora.org: add commit log]
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Update year for Qualcomm Atheros, Inc. copyrights.
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Add memory dump to the firmware crash data file which is provided to user space
via devcoredump interface. This makes it easier for firmware engineers to debug
firmware crashes.

Due to increased memory consumption the memory dump is disabled by default. To
enable it make sure that bit 3 is set in coredump_mask module parameter:

modprobe ath10k_core coredump_mask=0xffffffff

When RAMDUMP is enabled a buffer for the dump is allocated with vmalloc during
device probe. The actual memory layout is different in hardware versions and
the layouts are defined in coredump.c. The memory is split to regions and, to
get even finegrained control of what to copy, the region can split to smaller
sections as not all registers are readable (which could cause the whole system
to stall).
Signed-off-by: NAlan Liu <alanliu@qca.qualcomm.com>
[kvalo@qca.qualcomm.com: refactoring and cleanup]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

For memory dump support (it consumes quite a lot of memory) we need to control
what is exactly stored to the crash dump. Add a module parameter call
coredump_mask to do that. It's a bit mask of these values:

enum ath10k_fw_crash_dump_type {
	ATH10K_FW_CRASH_DUMP_REGISTERS = 0,
	ATH10K_FW_CRASH_DUMP_CE_DATA = 1,

	ATH10K_FW_CRASH_DUMP_MAX,
};

For example, if we only want to store CE_DATA we would enable bit 2:

modprobe ath10k_core coredump_mask=0x2
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Now coredump is totally separate from debug.c and doesn't depend on
CONFIG_ATH10K_DEBUGFS anymore, only on CONFIG_DEV_COREDUMP. Also remove
leftovers from the removed debugfs file support.
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

In preparation to add RAM dump support. No functional changes, only moving code
and renaming function names.
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

HL1.0 firmware is not loaded via bmi. The bmi specific
code should not be executed for HL1.0

Add fw feature flag for non bmi targets and skip the bmi
specific code for non bmi targets.
Signed-off-by: NRakesh Pillai <pillair@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

WCN3990 is integrated chipset which uses system NOC.
Add SNOC bus type and related definitions.
Signed-off-by: NGovind Singh <govinds@qti.qualcomm.com>
Signed-off-by: NRakesh Pillai <pillair@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

WCN3990 uses larger ring size in comparison to existing
ring size value.
Add rx ring size hw param for supporting different rx ring
size across multiple target.
Signed-off-by: NGovind Singh <govinds@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

WCN3990 target supports 37-bit addressing mode. In order
to accommodate extended address support, add hw param to
indicate if the target supports addressing above 32-bits.
Signed-off-by: NRakesh Pillai <pillair@qti.qualcomm.com>
Signed-off-by: NGovind Singh <govinds@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

This reverts commit e937b8da.

Turns out that a new driver (mt76) is coming in through
Kalle's tree, and will conflict with this. It also has some
conflicting requirements, so we'll revisit this later.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add hw params entry for wcn3990 and populate various
target specific values for wcn3990.
Signed-off-by: NRakesh Pillai <pillair@qti.qualcomm.com>
Signed-off-by: NGovind Singh <govinds@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

The parameter values for skid limit, number of peers and wds
entries values which are sent in wmi init cmd are hardware
specific.

Add support to obtain skid limit, number of peers and wds entries
values from hw params which will have the hw specific values
for these parameters.
Signed-off-by: NRakesh Pillai <pillair@qti.qualcomm.com>
Signed-off-by: NGovind Singh <govinds@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

HL1.0 firmware branch, used in wcn3990, transmits management
frames by reference over WMI.

Add support for management tx by reference over WMI.
Signed-off-by: NRakesh Pillai <pillair@qti.qualcomm.com>
Signed-off-by: NGovind Singh <govinds@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Board Data File (BDF) is loaded upon driver boot-up procedure. The right
board data file is identified on QCA4019 using bus, bmi-chip-id and
bmi-board-id.

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.

This problem was solved for SMBIOS by adding a special SMBIOS type 0xF8.
Something similar has to be provided for systems without SMBIOS but with
device trees. No solution was specified by QCA and therefore a new one has
to be found for ath10k.

The device tree requires addition strings to define the variant name

    wifi@a000000 {
    	status = "okay";
    	qcom,ath10k-calibration-variant = "RT-AC58U";
    };

    wifi@a800000 {
    	status = "okay";
    	qcom,ath10k-calibration-variant = "RT-AC58U";
    };

This would create the boarddata identifiers for the board-2.bin search

 *  bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U
 *  bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U
Signed-off-by: NSven Eckelmann <sven.eckelmann@openmesh.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

This adds an API to mac80211 to handle scheduling of TXQs and changes the
interface between driver and mac80211 for TXQ handling as follows:

- The wake_tx_queue callback interface no longer includes the TXQ. Instead,
  the driver is expected to retrieve that from ieee80211_next_txq()

- Two new mac80211 functions are added: ieee80211_next_txq() and
  ieee80211_schedule_txq(). The former returns the next TXQ that should be
  scheduled, and is how the driver gets a queue to pull packets from. The
  latter is called internally by mac80211 to start scheduling a queue, and
  the driver is supposed to call it to re-schedule the TXQ after it is
  finished pulling packets from it (unless the queue emptied).

The ath9k and ath10k drivers are changed to use the new API.
Signed-off-by: NToke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

QCA99x0 and QCA4019 family chips support CCMP-256, GCMP-128, and
GCMP-256 ciphers in hardware, so advertise support for these. As
firmware does not support group management frame ciphers (BIP),
handle them in software (mac80211).
Reviewed-by: NSebastian Gottschall <s.gottschall@dd-wrt.com>
Cc: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Currently ath10k host enables power save support in station mode by
default for all firmwares but Power save for station mode still not supported
in some of the firmware versions. Which results in firmware crash while
issueing multiple scan commands.

Fix this problem by introducing new FW feature flag to check power save
support in firmware and then the firmware image can tell to ath10k that power
save mode is not supported in station mode.
Signed-off-by: NVenkateswara Naralasetty <vnaralas@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

In commit 9f5bcfe9 ("ath10k: silence firmware file probing
warnings") the firmware loading was changed from request_firmware() to
request_firmware_direct() to silence some warnings in case it fails.
request_firmware_direct() directly searches in the file system only and
does not send a hotplug event to user space in case it could not find
the firmware directly.
In LEDE we use a user space script to extract the calibration data from
the flash memory which gets triggered by the hotplug event. This way the
firmware gets extracted from some vendor specific partition when the
driver requests this firmware. This mechanism does not work any more
after this change.

Fixes: 9f5bcfe9 ("ath10k: silence firmware file probing warnings")
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Cc: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

The rx ring buffers are added to a hash table if
firmware support full rx reorder. If the full rx
reorder support flag is not set before allocating
the rx ring buffers, none of the buffers are added
to the hash table.

There is a race condition between rx ring refill and
rx buffer replenish from napi poll. The interrupts are
enabled in hif start, before the rx ring is refilled during init.
We replenish buffers from napi poll due to the interrupts which
get enabled after hif start. Hence before the entire rx ring is
refilled during the init, the napi poll replenishes a few buffers
in steps of 100 buffers per attempt. During this rx ring replenish
from napi poll, the rx reorder flag has not been set due to which
the replenished buffers are not added to the hash table

Set the rx full reorder support flag before we allocate
the rx ring buffer to avoid the memory leak.
Signed-off-by: NRakesh Pillai <pillair@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

This patch adds the support of TDLS feature for 10.4 firmware
versions.

A new WMI service is added to advertise the support of TDLS for
10.4 firmwares.
Signed-off-by: NManikanta Pubbisetty <mpubbise@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Definitions for USB based chipsets
Signed-off-by: NErik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Copy engine is a host to target communication interface
between wlan firmware and wlan wcn3990 platform driver. Add copy
engine register map for wcn3990 wlan module. This add support
for the copy engine source/destination ring configuration for
wcn3990 chipset.
Signed-off-by: NGovind Singh <govinds@qti.qualcomm.com>
Signed-off-by: NKalle 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: NSven Eckelmann <sven.eckelmann@openmesh.com>
[kvalo@qca.qualcomm.com: use hw_params]
Signed-off-by: NKalle 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: NBen Greear <greearb@candelatech.com>
[sven.eckelmann@openmesh.com: rebase, cleanup, drop 160Mhz workaround cleanup]
Signed-off-by: NSven Eckelmann <sven.eckelmann@openmesh.com>
[kvalo@qca.qualcomm.com: use hw_params, rename the title]
Signed-off-by: NKalle 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: NSarada Prasanna Garnayak <c_sgarna@qti.qualcomm.com>
Signed-off-by: NKalle 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: NAnilkumar Kolli <akolli@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Since both SDIO based chipsets will use different
firmware from the PCIe and AHB chipsets, the fw file name
must be different depending on bus type.

The new firmware names are:

For PCIe and AHB:
firmware-<api_version>.bin (same as before)

For SDIO:
firmware-sdio-<api_version>.bin
Signed-off-by: NErik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Special BMI get target info function for SDIO.
Signed-off-by: NErik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Extra initializations needed by all sdio boards.
Derived from qcacld.
Signed-off-by: NErik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

spectral_bin length (number of bins per fft sample) is usually
a value where (2^n = value), n is an integer.  All of the QCA99X0
family of chipsets seems to report a spectral_bin length of
2^n + 'm' bytes, where m = 4, 12 based on the chipset. This 'm'
bytes seems to carry some radar related info which is currently
discarded only for 'bin_len = 68' bytes. Extend this discarding of
irrelevant 'bin_len' for QCA9984, QCA9888, IPQ4019 as well by
introducing a hardware parameter 'spectral_bin_discard'. Also
for QCA988X based family of chipsets which doesn't seem to have this
issue and also for some of the hardware which I have not tested
like QCA6174/QCA9377 the existing behaviour is retained as it is.
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Fix output from checkpatch.pl like:
 Block comments use a trailing */ on a separate lin
Signed-off-by: NMarcin Rokicki <marcin.rokicki@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

It seems set_coverage_class_work is not cancelled anywhere,
though I could not find a crash/warning  with this existing
design, its safer to cancel it during stop() and also before
restarting the hardware.
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

QCA9377 is the family of QCA61x4 which shared the same procedure
to enable the hardware clock that could improve the firmware download time.
Signed-off-by: NRyan Hsu <ryanhsu@qca.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Len Brown reported the system resume time is taking more than 2 seconds in
bug - https://bugzilla.kernel.org/show_bug.cgi?id=185621.

The reason of the 2 seconds is due to the firmware download time.

The chip is booted up in the default reference clock speed to handle the
firmware download to chip memory and advanced to the support higher speed
clock to run the firmware after all. The default reference clock in the
hardware is slow so that the firmware download time is taking up to 2
seconds for a 600KB firmware file.

	[76796.349701] ath10k_pci : boot uploading firmware image len 688691
	[76798.334612] ath10k_pci : htt tx max num pending tx 1056

The resolution here is to enable the higher speed clock if the hardware
supported before the firmware download at BMI stage, so that the hardware
can handle the firmare download in a more efficient way. This can help to
improve the firmware download time from 2 seconds to around 500ms for the
same 600KB firmware file.

	[322858.577919] ath10k_pci boot uploading firmware image len 688691
	[322859.093094] ath10k_pci htt tx max num pending tx 1056

The steps to advance to the higher speed clock is very hardware specific,
so adding the hardware ops for the hardware that can support this.
Reported-by: NLen Brown <lenb@kernel.org>
Tested-by: NPaul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: NRyan Hsu <ryanhsu@qca.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

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"

If board data file name extension is set but board-2.bin does not contain
board data file for the variant, the driver will fallback to the default
board data file not to break backward compatibility.

This was first applied in commit f2593cb1 ("ath10k: Search SMBIOS for OEM
board file extension") but later reverted in commit 005c3490 ("Revert
"ath10k: Search SMBIOS for OEM board file extension"". This patch is now
otherwise the same as commit f2593cb1 except the regression fixed.
Signed-off-by: NWaldemar Rymarkiewicz <ext.waldemar.rymarkiewicz@tieto.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>