wifi: ath10k: add support to allow broadcast action frame RX

Broadcast action frames are needed for the Device Provisioning
Protocol (DPP) for Presence and PKEX Exchange requests. Currently
just ath9k has this capability so this is being enabled for
ath10k (for at least one hardware variant).

Add a new capability flag in ath10k_hw_params to indicate support
for receiving multicast action frames. This bit is then checked
when configuring the RX filter and (if set) multicast action frame
registration is enabled.

Until more hardware can be tested only the "qca6174 hw3.2" variant
is enabling this feature.

Note: I went ahead and removed the 'changed_flags' mask operation
since it had no effect, that parameter was not being used anywhere.

Tested-on: QCA6174 hw3.2 WLAN.RM.4.4.1-00288-

Signed-off-by: James Prestwood <prestwoj@gmail.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20231116173246.40458-1-prestwoj@gmail.com

wifi: ath10k: Update Qualcomm Innovation Center, Inc. copyrights

Update the copyright for all ath10k files modified on behalf of
Qualcomm Innovation Center, Inc. in 2021 through 2023.

Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20231128-ath12kcopyrights-v1-3-be0b7408cbac@quicinc.com

wifi: ath10k: Delay the unmapping of the buffer

On WCN3990, we are seeing a rare scenario where copy engine hardware is
sending a copy complete interrupt to the host driver while still
processing the buffer that the driver has sent, this is leading into an
SMMU fault triggering kernel panic. This is happening on copy engine
channel 3 (CE3) where the driver normally enqueues WMI commands to the
firmware. Upon receiving a copy complete interrupt, host driver will
immediately unmap and frees the buffer presuming that hardware has
processed the buffer. In the issue case, upon receiving copy complete
interrupt, host driver will unmap and free the buffer but since hardware
is still accessing the buffer (which in this case got unmapped in
parallel), SMMU hardware will trigger an SMMU fault resulting in a
kernel panic.

In order to avoid this, as a work around, add a delay before unmapping
the copy engine source DMA buffer. This is conditionally done for
WCN3990 and only for the CE3 channel where issue is seen.

Below is the crash signature:

wifi smmu error: kernel: [ 10.120965] arm-smmu 15000000.iommu: Unhandled
context fault: fsr=0x402, iova=0x7fdfd8ac0,
fsynr=0x500003,cbfrsynra=0xc1, cb=6 arm-smmu 15000000.iommu: Unhandled
context fault:fsr=0x402, iova=0x7fe06fdc0, fsynr=0x710003,
cbfrsynra=0xc1, cb=6 qcom-q6v5-mss 4080000.remoteproc: fatal error
received: err_qdi.c:1040:EF:wlan_process:0x1:WLAN RT:0x2091:
cmnos_thread.c:3998:Asserted in copy_engine.c:AXI_ERROR_DETECTED:2149
remoteproc remoteproc0: crash detected in
4080000.remoteproc: type fatal error <3> remoteproc remoteproc0:
handling crash #1 in 4080000.remoteproc

pc : __arm_lpae_unmap+0x500/0x514
lr : __arm_lpae_unmap+0x4bc/0x514
sp : ffffffc011ffb530
x29: ffffffc011ffb590 x28: 0000000000000000
x27: 0000000000000000 x26: 0000000000000004
x25: 0000000000000003 x24: ffffffc011ffb890
x23: ffffffa762ef9be0 x22: ffffffa77244ef00
x21: 0000000000000009 x20: 00000007fff7c000
x19: 0000000000000003 x18: 0000000000000000
x17: 0000000000000004 x16: ffffffd7a357d9f0
x15: 0000000000000000 x14: 00fd5d4fa7ffffff
x13: 000000000000000e x12: 0000000000000000
x11: 00000000ffffffff x10: 00000000fffffe00
x9 : 000000000000017c x8 : 000000000000000c
x7 : 0000000000000000 x6 : ffffffa762ef9000
x5 : 0000000000000003 x4 : 0000000000000004
x3 : 0000000000001000 x2 : 00000007fff7c000
x1 : ffffffc011ffb890 x0 : 0000000000000000 Call trace:
__arm_lpae_unmap+0x500/0x514
__arm_lpae_unmap+0x4bc/0x514
__arm_lpae_unmap+0x4bc/0x514
arm_lpae_unmap_pages+0x78/0xa4
arm_smmu_unmap_pages+0x78/0x104
__iommu_unmap+0xc8/0x1e4
iommu_unmap_fast+0x38/0x48
__iommu_dma_unmap+0x84/0x104
iommu_dma_free+0x34/0x50
dma_free_attrs+0xa4/0xd0
ath10k_htt_rx_free+0xc4/0xf4 [ath10k_core] ath10k_core_stop+0x64/0x7c
[ath10k_core]
ath10k_halt+0x11c/0x180 [ath10k_core]
ath10k_stop+0x54/0x94 [ath10k_core]
drv_stop+0x48/0x1c8 [mac80211]
ieee80211_do_open+0x638/0x77c [mac80211] ieee80211_open+0x48/0x5c
[mac80211]
__dev_open+0xb4/0x174
__dev_change_flags+0xc4/0x1dc
dev_change_flags+0x3c/0x7c
devinet_ioctl+0x2b4/0x580
inet_ioctl+0xb0/0x1b4
sock_do_ioctl+0x4c/0x16c
compat_ifreq_ioctl+0x1cc/0x35c
compat_sock_ioctl+0x110/0x2ac
__arm64_compat_sys_ioctl+0xf4/0x3e0
el0_svc_common+0xb4/0x17c
el0_svc_compat_handler+0x2c/0x58
el0_svc_compat+0x8/0x2c

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1

Tested-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Youghandhar Chintala <quic_youghand@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20221012142733.32420-1-quic_youghand@quicinc.com

wifi: ath10k: Set tx credit to one for WCN3990 snoc based devices

Currently host can send two WMI commands at once. There is possibility to
cause SMMU issues or corruption, if host wants to initiate 2 DMA
transfers, it is possible when copy complete interrupt for first DMA
reaches host, CE has already updated SRRI (Source ring read index) for
both DMA transfers and is in the middle of 2nd DMA. Host uses SRRI
(Source ring read index) to interpret how many DMA’s have been completed
and tries to unmap/free both the DMA entries. Hence now it is limiting to
one.Because CE is still in the middle of 2nd DMA which can cause these
issues when handling two DMA transfers.

This change will not impact other targets, as it is only for WCN3990.

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1

Signed-off-by: Youghandhar Chintala <quic_youghand@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220801134941.15216-1-quic_youghand@quicinc.com

ath10k: Trigger sta disconnect on hardware restart

Currently after the hardware restart triggered from the driver,
the station interface connection remains intact, since a disconnect
trigger is not sent to userspace. This can lead to a problem in
targets where the wifi mac sequence is added by the firmware.

After the target restart, its wifi mac sequence number gets
reset to zero. Hence AP to which our device is connected will receive
frames with a wifi mac sequence number jump to the past, thereby
resulting in the AP dropping all these frames, until the frame
arrives with a wifi mac sequence number which AP was expecting.

To avoid such frame drops, its better to trigger a station disconnect
upon target hardware restart which can be done with API
ieee80211_reconfig_disconnect exposed to mac80211.

The other targets are not affected by this change, since the hardware
params flag is not set.

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1
Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00110-QCARMSWP-1
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00048

Signed-off-by: Youghandhar Chintala <youghand@codeaurora.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220315082944.12406-3-youghand@codeaurora.org

ath10k: abstract htt_rx_desc structure

QCA6174 card often hangs with the current htt_rx_desc
memory layout in some circumstances, because its firmware
fails to handle length differences.
Therefore we must abstract the htt_rx_desc structure
and operations on it, to allow different wireless cards
to use different, unrelated rx descriptor structures.

Define a base htt_rx_desc structure and htt_rx_desc_v1
for use with the QCA family of ath10k supported cards
and htt_rx_desc_v2 for use with the WCN3990 card.

Define htt_rx_desc_ops which contains the abstract operations
to access the generic htt_rx_desc, give implementations
for each card and update htt_rx.c to use the defined
abstract interface to rx descriptors.

Fixes: e3def6f7ddf8 ("ath10k: Update rx descriptor for WCN3990 target")

Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00157-QCARMSWPZ-1

Co-developed-by: Enrico Lumetti <enrico@fracta.dev>
Signed-off-by: Enrico Lumetti <enrico@fracta.dev>
Signed-off-by: Francesco Magliocca <franciman12@gmail.com>
Link: https://lore.kernel.org/ath10k/CAH4F6usFu8-A6k5Z7rU9__iENcSC6Zr-NtRhh_aypR74UvN1uQ@mail.gmail.com/
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211216151823.68878-1-franciman12@gmail.com

ath10k: Fix the MTU size on QCA9377 SDIO

On an imx6dl-pico-pi board with a QCA9377 SDIO chip, simply trying to
connect via ssh to another machine causes:

[ 55.824159] ath10k_sdio mmc1:0001:1: failed to transmit packet, dropping: -12
[ 55.832169] ath10k_sdio mmc1:0001:1: failed to submit frame: -12
[ 55.838529] ath10k_sdio mmc1:0001:1: failed to push frame: -12
[ 55.905863] ath10k_sdio mmc1:0001:1: failed to transmit packet, dropping: -12
[ 55.913650] ath10k_sdio mmc1:0001:1: failed to submit frame: -12
[ 55.919887] ath10k_sdio mmc1:0001:1: failed to push frame: -12

, leading to an ssh connection failure.

One user inspected the size of frames on Wireshark and reported
the followig:

"I was able to narrow the issue down to the mtu. If I set the mtu for
the wlan0 device to 1486 instead of 1500, the issue does not happen.

The size of frames that I see on Wireshark is exactly 1500 after
setting it to 1486."

Clearing the HI_ACS_FLAGS_ALT_DATA_CREDIT_SIZE avoids the problem and
the ssh command works successfully after that.

Introduce a 'credit_size_workaround' field to ath10k_hw_params for
the QCA9377 SDIO, so that the HI_ACS_FLAGS_ALT_DATA_CREDIT_SIZE
is not set in this case.

Tested with QCA9377 SDIO with firmware WLAN.TF.1.1.1-00061-QCATFSWPZ-1.

Fixes: 2f918ea98606 ("ath10k: enable alt data of TX path for sdio")
Signed-off-by: Fabio Estevam <festevam@denx.de>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211124131047.713756-1-festevam@denx.de

ath10k: allow dynamic SAR power limits via common API

ath10k assigns ath10k_mac_set_sar_specs to ath10k_ops, and
this function is called when user space application calls
NL80211_CMD_SET_SAR_SPECS. ath10k also registers SAR type,
and supported frequency ranges to wiphy so user space can
query SAR capabilities.

This SAR power limitation is compared to regulatory txpower
and selects the minimal one to set when station is connected.
Otherwise, it delays until the station is connected. If the
station is disconnected, it returns to regulatory txpower.

This feature is controlled by hw parameter: dynamic_sar_support.

Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00110-QCARMSWP-1

Signed-off-by: Carl Huang <cjhuang@codeaurora.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Abhishek Kumar <kuabhs@chromium.org>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201203103728.3034-4-cjhuang@codeaurora.org

ath10k: Get rid of "per_ce_irq" hw param

As of the patch ("ath10k: Keep track of which interrupts fired, don't
poll them") we now have no users of this hardware parameter. Remove
it.

Suggested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200709082024.v2.2.I083faa4e62e69f863311c89ae5eb28ec5a229b70@changeid

ath10k: Replace zero-length array with flexible-array

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
int stuff;
struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200507041127.GA31587@embeddedor

ath10k: add rx bitrate report for SDIO

For SDIO chip, its rx indication is struct htt_rx_indication_hl, which
does not include the bitrate info as well as PCIe, for PCIe, it use
function ath10k_htt_rx_h_rates to parse the bitrate info in struct
rx_ppdu_start and then report it to mac80211 via ieee80211_rx_status.

SDIO does not have the same info as PCIe, then iw command can not get
the rx bitrate by "iw wlan0 station dump".

for example, it always show 6.0 MBit/s
localhost ~ # iw wlan0 link
Connected to 3c:28:6d:96:fd:69 (on wlan0)
SSID: kukui_test
freq: 5180
RX: 111800 bytes (595 packets)
TX: 35419 bytes (202 packets)
signal: -41 dBm
rx bitrate: 6.0 MBit/s

This patch is to send WMI_TLV_REQUEST_PEER_STATS_INFO_CMDID to firmware
for ath10k_sta_statistics and save the rx bitrate for WMI event
WMI_TLV_PEER_STATS_INFO_EVENTID.

This patch only effect SDIO chip, ath10k_mac_sta_get_peer_stats_info
has check for bitrate_statistics of hw_params, this patch only enable
it for "qca6174 hw3.2 sdio".

Tested with QCA6174 SDIO firmware WLAN.RMH.4.4.1-00042.

Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200427080416.8265-3-wgong@codeaurora.org

ath10k: disable TX complete indication of htt for sdio

For sdio chip, it is high latency bus, all the TX packet's content will
be tranferred from HOST memory to firmware memory via sdio bus, then it
need much more memory in firmware than low latency bus chip, for low
latency chip, such as PCI-E, it only need to transfer the TX descriptor
via PCI-E bus to firmware memory. For sdio chip, reduce the complexity of
TX logic will help TX efficiency since its memory is limited, and it will
reduce the TX circle's time of each packet and then firmware will have more
memory for TX since TX complete also need memeory.

This patch disable TX complete indication from firmware for htt data
packet, it will not have TX complete indication from firmware to ath10k.
It will cut the cost of bus bandwidth of TX complete and make the TX
logic of firmware simpler, it results in significant performance
improvement on TX path.

Udp TX throughout is 130Mbps without this patch, and it arrives
400Mbps with this patch.

The downside of this patch is the command "iw wlan0 station dump" will
show 0 for "tx retries" and "tx failed" since all tx packet's status
is success.

This patch only effect sdio chip, it will not effect PCI, SNOC etc.

Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00017-QCARMSWPZ-1

Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200212080415.31265-2-wgong@codeaurora.org

ath10k: add QCA9377 sdio hw_param item

Add hardware parameters for QCA9377 sdio devices, it's now properly supported.

Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Revert "ath10k: fix DMA related firmware crashes on multiple devices"

This reverts commit 76d164f582150fd0259ec0fcbc485470bcd8033e.
PCIe hung issue was observed on multiple platforms. The issue was reproduced
when DUT was configured as AP and associated with 50+ STAs.

For QCA9984/QCA9888, the DMA_BURST_SIZE register controls the AXI burst size
of the RD/WR access to the HOST MEM.
0 - No split , RAW read/write transfer size from MAC is put out on bus
as burst length
1 - Split at 256 byte boundary
2,3 - Reserved

With PCIe protocol analyzer, we can see DMA Read crossing 4KB boundary when
issue happened. It broke PCIe spec and caused PCIe stuck. So revert
the default value from 0 to 1.

Tested: IPQ8064 + QCA9984 with firmware 10.4-3.10-00047
QCS404 + QCA9984 with firmware 10.4-3.9.0.2--00044
Synaptics AS370 + QCA9888 with firmware 10.4-3.9.0.2--00040

Signed-off-by: Zhi Chen <zhichen@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: add large size for BMI download data for SDIO

Download firmware time cost of SDIO is too long, it is about 480ms,
add large size 2048 bytes for BMI download for SDIO chip, its time
cost will reduced to 240ms.

This will optimize the download firmware time cost.

Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00017-QCARMSWP-1.

Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: add support for hardware rfkill

When hardware rfkill is enabled in the firmware it will report the
capability via using WMI_TLV_SYS_CAP_INFO_RFKILL bit in the WMI_SERVICE_READY
event to the host. ath10k will check the capability, and if it is enabled then
ath10k will set the GPIO information to firmware using WMI_PDEV_SET_PARAM. When
the firmware detects hardware rfkill is enabled by the user, it will report it
via WMI_RFKILL_STATE_CHANGE_EVENTID. Once ath10k receives the event it will
send wmi command WMI_PDEV_SET_PARAM to the firmware to enable/disable the radio
and also notifies cfg80211.

We can't power off the device when rfkill is enabled, as otherwise the
firmware would not be able to detect GPIO changes and report them to the
host. So when rfkill is enabled, we need to keep the firmware running.

Tested with QCA6174 PCI with firmware
WLAN.RM.4.4.1-00109-QCARMSWPZ-1.

Signed-off-by: Alan Liu <alanliu@codeaurora.org>
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: add new hw_ops for sdio chip

It report error message while suspend/resume test.
dmesg log:
[ 150.749962] ath10k_sdio mmc1:0001:1: hif read32 not supported
[ 150.755728] ath10k_sdio mmc1:0001:1: failed to set coverage class: expected integer microsecond value in register

Reason is sdio chip does not support set_coverage_class as well as
pcie chip, remove the set_coverage_class handler will avoid it.

callstack of the error message:
OUTLINED_FUNCTION_6+0xc/0x14 [ath10k_core]
ath10k_mac_op_set_coverage_class+0x2c/0x40 [ath10k_core]
ieee80211_reconfig+0x5d0/0x108c [mac80211]
ieee80211_resume+0x34/0x6c [mac80211]
wiphy_resume+0xbc/0x13c [cfg80211]
dpm_run_callback+0xa4/0x168
device_resume+0x1d4/0x200
async_resume+0x1c/0x34
async_run_entry_fn+0x48/0xf8
process_one_work+0x178/0x2f8
worker_thread+0x1d8/0x2cc
kthread+0x11c/0x12c
ret_from_fork+0x10/0x18

the error log will not happen after this patch applied.

Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00007-QCARMSWP-1.

Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: enabling tx stats support over pktlog

For QCA988X target, pktlog gives details of the tx bitrate
which is used in the driver for station info.

Enabling pktlog by default will cause more interrupts
in target to host CE pipe, which can impact more CPU usage
for targets ex:WCN3990 and also not required for all other
platforms (eg: WCN3990), for getting tx bitrate.

Enable pktlog only for QCA988X based on hardware params.

Tested HW : WCN3990
Tested FW : WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1

Fixes: e8123bb74c4e ("ath10k: add per peer tx stats support for 10.2.4")
Signed-off-by: Balaji Pothunoori <bpothuno@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: change firmware file name for UTF mode of SDIO/USB

Firmware name for UTF mode of SDIO has changed from utf-2.bin to
utf-sdio-2.bin, so it need to change in ath10k, otherwise it will
fail for UTF mode.

After change the name in ath10k, it will success for UTF mode of
SDIO/USB.

Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00007-QCARMSWP-1.

Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: add support for firmware crash recovery on SDIO chip

The command to simulate firmware crash:
echo soft > /sys/kernel/debug/ieee80211/phy0/ath10k/simulate_fw_crash

It will send WMI_FORCE_FW_HANG_ASSERT to firmware, then it will trigger
CPU interrupt status register for SDIO chip, ath10k driver need to
configure it while enable SDIO interrupt, otherwise ath10k driver will
not get the assert error info.

After this change, it will success for simulate firmware crash.

Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00007-QCARMSWP-1.

Signed-off-by: Wen Gong <wgong@codeaurora.org>
Tested-by: Claire Chang <tientzu@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: enable QCA6174 hw3.2 SDIO hardware

After implementing PN replay check we can enable SDIO support on QCA6174.
Tested with client mode on all security modes, and fragmentation as well. AP
mode does not work yet.

Also tone down the warning about SDIO being not ready yet.

Tested on QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1. AP mode
is not working yet.

Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: sdio: workaround firmware UART pin configuration bug

On QCA6174 SDIO devices the SDIO interrupt will fail if UART is
disabled from ath10k. SDIO firmware enables UART printouts by
default. If ath10k will try to enable UART again the firmware
will configure it's GPIO line incorrectly and SDIO interrupts
won't work anymore. The workaround is to set UART pin again (19
for QCA6174 SDIO) if uart_print is 0.

Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1.

Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: update the max num of peers supported for WCN3990

WCN3990 firmware versions WLAN.HL.2.0-01617-QCAHLSWMTPLZ-1 & onwards
supports maximum 33 peers including self peer. To support maximum peers,
send updated peer param to firmware during initialization.

Tested HW: WCN3990
Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1

Signed-off-by: Abhishek Ambure <aambure@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: add support for ack rssi value of data tx packets

In WCN3990, WMI_TLV_SERVICE_TX_DATA_MGMT_ACK_RSSI service Indicates that
the firmware has the capability to send the RSSI value of the ACK for all
data and management packets transmitted.

If WMI_RSRC_CFG_FLAG_TX_ACK_RSSI is set in host capability then firmware
sends RSSI value in "data" tx completion event. Host extracts ack rssi
values of data packets from their tx completion event.

Tested HW: WCN3990
Tested FW: WLAN.HL.2.0-01617-QCAHLSWMTPLZ-1

Signed-off-by: Abhishek Ambure <aambure@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: switch to use SPDX license identifiers

Use SPDX identifiers everywhere in ath10k.

Makefile was incorrectly marked in commit b24413180f56 ("License cleanup: add
SPDX GPL-2.0 license identifier to files with no license"), fix that as well.

Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: reduce transmit msdu count

Reduce the transmit MSDU count for SDIO, to match with the descriptors
as used by the firmware. This also acts as a high watermark level for
transmit. Too many packets to the firmware results in transmit overflow
interrupt.

It only affect SDIO chip, it will not cause functionaly changes to
other hardware.

Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00005-QCARMSWP-1.

Signed-off-by: Alagu Sankar <alagusankar@silex-india.com>
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: Set DMA address mask to 35 bit for WCN3990

WCN3990 is a 37-bit target but can address memory range
only upto 35 bits. The 36th bit is used to control the
smmu/iommu translation and the 37th bit is used by the
internal bus masters to access the wifi subsystem internal
SRAM. With the DMA mask set to 37i-bit, the host driver
can get 37-bit dma address, which leads to incorrect
address access in the target.

Hence the host driver can used addresses upto 35-bit
for WCN3990. Fix the dma mask for wcn3990 to 35-bit,
instead of 37-bit.

Tested HW: WCN3990
Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1

Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: fix warning due to msdu limit error

Some hardwares variants (QCA99x0) are limiting msdu deaggregation with
some threshold value(default limit in QCA99x0 is 64 msdus), it was introduced to
avoid excessive MSDU-deaggregation in error cases. When number of sub frames
exceeds the limit, target hardware will send all msdus starting from present
msdu in RAW format as a single msdu packet and it will be indicated with
error status bit "RX_MSDU_END_INFO0_MSDU_LIMIT_ERR" set in rx descriptor.
This msdu frame is a partial raw MSDU and does't have first msdu and ieee80211
header. It caused below warning message.

[ 320.151332] ------------[ cut here ]------------
[ 320.155006] WARNING: CPU: 0 PID: 3 at drivers/net/wireless/ath/ath10k/htt_rx.c:1188

In our issue case, MSDU limit error happened due to FCS error and generated
this warning message.

This fixes the warning by handling the MSDU limit error. If msdu limit error
happens, driver adds first MSDU's ieee80211 header and sets A-MSDU present bit
in QOS header so that upper layer processes this frame if it is valid or drop it
if FCS error set. And removed the warning message, hence partial msdus without
first msdu is expected in msdu limit error cases.

Tested on QCA9984, Firmware 10.4-3.6-00104

Signed-off-by: Bhagavathi Perumal S <bperumal@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: add bus type check in ath10k_init_hw_params

The bus type is used together with the other hw parameters
to find a matching entry in ath10k_hw_params_list for the device.

This is necessary since HL devices can have the same dev_id and
target_version as a corresponding LL device (same chipset) and
yet use a totally different configuration.

Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: download firmware via diag Copy Engine for QCA6174 and QCA9377.

Downloading firmware via BMI protocol takes too long time. For example,
a ~700K bytes firmware takes about 500ms to download via BMI protocol.
This is too long especially in suspend and resume scenario where firmware
is re-downloaded unless WoWLAN is enabled. Downloading firmware via diag CE
can reduce the time to ~40ms for a ~700K bytes firmware binary.

Ath10k driver parses the firmware to segments and downloads the segments
to the specified address directly. If the firmware is compressed or has
unsupported segments, ath10k driver will try BMI download again.

It's tested with QCA6174 hw3.2 and
firmware-6.bin_WLAN.RM.4.4.1-00111-QCARMSWP-1. QCA9377 is also affected.

Signed-off-by: Carl Huang <cjhuang@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: support extended board data download for dual-band QCA9984

To support dual-band variant of QCA9984, new extended board data (eBDF)
is introduced since existing board data ran out of space.

Below is the brief implementation & design detail,
----------------------------------------------------

1. New OTP changes to inform eBDF support in existing OTP download to
fetch board ID and chip ID. This is backward compatible and older
card sends 0 by default for eBDF support bit (bit 18 of OTP response) we
check in ath10k driver.

2. If eBDF is supported, then we need to fetch eBDF ID which is bundled
in downloaded board data. So again OTP is executed for knowing the eBDF ID.
This is done once we set 'board_data_initialized' bit. If eBDF ID
returned is zero, we continue booting with previous board data downloaded.

3. Based on the eBDF ID fetched, ath10k driver tries to download the
extended board data to a new offset ahead of already downloaded board
data address.

4. A new BD IE type, ATH10K_BD_IE_BOARD_EXT is added to differentiate in
bundling eBDF separately in board-2.bin and also to parse through
board bundle for eBDF download in ath10k boot.

5. If eBDF is not present in the board-2.bin bundle or when board ID is
zero, we do a fallback boot to "eboard.bin" in the same QCA9984/hw1.0 dir.
This is same as done to existing "board.bin" if board ID is not present
in board-2.bin bundle.

Current design is that eBDF size will be 2KB and eBDF ID will be
byte value.

Tested the above changes with dual-band variant of QCA9984 card. OTP
update needed for the test will be part of next FW release 10.4-3.6-xxxx.

Below are the logs with ath10k BOOT debugs enabled.

First OTP response :
---------------------
..
boot upload otp to 0x1234 len 9478 for board id
boot get otp board id result 0x00040400 board_id 1 chip_id 0 ext_bid_support 1
..

Second OTP response :
---------------------
..
boot upload otp to 0x1234 len 9478 for ext board id
boot get otp ext board id result 0x00000005 ext_board_id 5
boot using eboard name 'bus=pci,bmi-chip-id=0,bmi-eboard-id=5'
..

Extended board data download:
------------------------------
..
board name
00000000: 62 75 73 3d 70 63 69 2c 62 6d 69 2d 63 68 69 70 bus=pci,bmi-chip
00000010: 2d 69 64 3d 30 2c 62 6d 69 2d 65 62 6f 61 72 64 -id=0,bmi-eboard
00000020: 2d 69 64 3d 35 -id=5
boot found match for name 'bus=pci,bmi-chip-id=0,bmi-eboard-id=5'
boot found eboard data for 'bus=pci,bmi-chip-id=0,bmi-eboard-id=5'
using board api 2
boot writing ext board data to addr 0xc3000
..

Fallback Extended board data download from "eboard.bin":
---------------------------------------------------------
..
board name
00000000: 62 75 73 3d 70 63 69 2c 62 6d 69 2d 63 68 69 70 bus=pci,bmi-chip
00000010: 2d 69 64 3d 30 2c 62 6d 69 2d 62 6f 61 72 64 2d -id=0,bmi-board-
00000020: 69 64 3d 31 30 id=10
failed to fetch board data for bus=pci,bmi-chip-id=0,bmi-eboard-id=5 from ath10k/QCA9984/hw1.0/board-2.bin
boot fw request 'ath10k/QCA9984/hw1.0/eboard.bin': 0
using board api 1
boot writing ext board data to addr 0xc3000
..

Signed-off-by: Sathishkumar Muruganandam <murugana@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: skip resetting rx filter for WCN3990

WCN3990 has the MAC_PCU_ADDR1 configured properly
and hence it will not send spurious ack frames
during boot up.

Hence the reset_rx_filter workaround is not needed
for WCN3990. Add a hw_param to indicate if hardware rx
filter reset is needed and skip the reset_rx_filter for
WCN3990.

Tested HW: WCN3990
Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1

Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: handle mgmt tx completion event

WCN3990 transmits management frames via WMI
with reference. Currently, with the management
tx completion not being handled, these frames are
not getting freed even after the transmission status
is returned by the firmware.

The transmitted management frames should be freed
when the firmware sends the over-the-air tx status of
the corresponding management frames.

Handle the wmi mgmt tx completion event and free
the corresponding management frame.

Tested HW: WCN3990
Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1

Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: fix spectral scan for QCA9984 and QCA9888 chipsets

The spectral scan has been always broken on QCA9984 and QCA9888.

Introduce a hardware parameter 'spectral_bin_offset' to resolve this issue for
QCA9984 and QCA9888 chipsets. For other chipsets, the hardware parameter
'spectral_bin_offset' is zero so that existing behaviour is retained as it is.

In QCA9984 and QCA9888 chipsets, hardware param value 'spectral_bin_discard'
is 12 bytes. This 12 bytes is derived as the sum of segment index (4 bytes),
extra bins before the actual data (4 bytes) and extra bins after the actual
data (4 bytes). Always discarding (12 bytes) happens at end of the samples and
incorrect samples got dumped, so that user can find incorrect arrangement
samples in spectral scan dump.

To fix this issue, we have to discard first 8 bytes and last 4 bytes in every
samples, so totally 12 bytes are discarded. In every sample we need to consider
the offset while taking the actual spectral data. For QCA9984, QCA9888 the
offset is 8 bytes (segment index + extra bins before actual data).

Hardware tested: QCA9984 and QCA9888
Firmware tested: 10.4-3.5.3-00053

Signed-off-by: Karthikeyan Periyasamy <periyasa@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: hw: make consistent usage of ATH10K_FW_DIR in paths

For some reason not all entries used ATH10K_FW_DIR so fix that. No functional
changes.

Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: enable SRRI/DRRI support on ddr for WCN3990

SRRI/DRRI are not mapped in the HW Shadow block and can lead
to un-clocked access if common subsystem in the target is
powered down due to idle mode.

To mitigate this problem SRRI/DRRI can be read from
DDR instead of doing an actual hardware read.
Host allocates non cached memory on ddr and configures
the physical address of this memory to the CE hardware.
The hardware updates the RRI on this particular location.
Read SRRI/DRRI from DDR location instead of
direct target read.

Enable retention restore on ddr using hw params to enable
in specific targets.

Signed-off-by: Govind Singh <govinds@codeaurora.org>
Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: add hw params for shadow register support

wcn3990 supports shadow register for ce write.

Add a hw param for shadow register support.

Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: fix fw path name for WCN3990 target

FW path is mapped incorrectly for the WCN3990
hw version. Fix fw path with correct hw1.0 name.

Signed-off-by: Govind Singh <govinds@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: check all CE for data if irq summary is not retained

WCN3990 has interrupts per CE and the interrupt summary
is not retained after the interrupt handler has finished
execution. We need to check if we received any
ce in rx and tx completion path.

Generate a interrupt summary with all CE interrupts if
the target does not retain interrupt summary after the
execution of interrupt handler.

Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
Signed-off-by: Govind Singh <govinds@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath10k: add support for Ubiquiti rebranded QCA988X v2

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: Tobias 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: Kalle Valo <kvalo@codeaurora.org>

ath10k: update copyright year

Update year for Qualcomm Atheros, Inc. copyrights.

Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add memory dump support for QCA6174/QCA9377

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: Alan Liu <alanliu@qca.qualcomm.com>
[kvalo@qca.qualcomm.com: refactoring and cleanup]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: Add hw param for rx ring size support

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: Govind Singh <govinds@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: Add hw param for 64-bit address support

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: Rakesh Pillai <pillair@qti.qualcomm.com>
Signed-off-by: Govind Singh <govinds@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: wmi: add hw params entry for wcn3990

Add hw params entry for wcn3990 and populate various
target specific values for wcn3990.

Signed-off-by: Rakesh Pillai <pillair@qti.qualcomm.com>
Signed-off-by: Govind Singh <govinds@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: wmi: get wmi init parameter values from hw params

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: Rakesh Pillai <pillair@qti.qualcomm.com>
Signed-off-by: Govind Singh <govinds@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add new cipher suite support

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: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Cc: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: make ath10k_hw_ce_regs const

Make them const as they are not modified in the file referencing
them. They are only stored in the const field 'hw_ce_reg' of an ath10k
structure. Also, make the declarations in the header const.

Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add tdls support for 10.4 firmwares

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: Manikanta Pubbisetty <mpubbise@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add copy engine register MAP for wcn3990 target

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: Govind Singh <govinds@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: configure rxnss_override for QCA9984

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>

ath10k: define structures for CE ctrl/misc register

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>

ath10k: various sdio related definitions

Debug masks for SDIO HIF layer.
Address definitions for SDIO/mbox based chipsets.
Augmented struct host_interest with more members.

Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: bump up FW API to 6

For QCA6174 hw3.0, since WLAN.RM.4.4-00022-QCARMSWPZ-2, it starts to
support the board ID information from otp, with some devices released on
the market that didn't calibrated with OTP, will have 0 for board ID
information, which cause the backward compatibility issue and was fixed
in commit 'd2e202c06ca4 ("ath10k: ignore configuring the incorrect board_id")'

So bump the fw api version to differentiate the latest firmware support.

Signed-off-by: Ryan Hsu <ryanhsu@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: fix spectral scan for QCA99X0 family of chipsets

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: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: clean header files from bad block comments

Fix output from checkpatch.pl like:

Block comments use a trailing */ on a separate line

Signed-off-by: Marcin Rokicki <marcin.rokicki@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: improve the firmware download time for QCA6174

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: Len Brown <lenb@kernel.org>
Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Ryan Hsu <ryanhsu@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: fetch firmware images in a loop

To make it easier to handle minimum and maximum firmware API numbers convert
the firmware fetch functionality to a loop. If no firmware image is found print
an error with minimum and maximum API numbers and the name of firmware
directory. This is needed when we switch to using request_firmware_direct()
which doesn't print any errors anymore.

Also add a new function for creating the fw file name dynamically which makes it
easier to add new bus support, for example SDIO and USB, later.

Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
[kvalo@qca.qualcomm.com: remove sdio/usb part, new error message, clarify commit log]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: dump Copy Engine registers during firmware crash

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>

ath10k: decrease num of peers support

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>

ath10k: allow setting coverage class

Unfortunately ath10k does not generally allow modifying the coverage class
with the stock firmware and Qualcomm has so far refused to implement this
feature so that it can be properly supported in ath10k. If we however know
the registers that need to be modified for proper operation with a higher
coverage class, then we can do these modifications from the driver.

This is a hack and might cause subtle problems but as it's not enabled by
default (only when user space changes the coverage class explicitly) it should
not cause new problems for existing setups. But still this should be considered
as an experimental feature and used with caution.

This patch implements the support for first generation cards (QCA9880, QCA9887
and so on) which are based on a core that is similar to ath9k. The registers
are modified in place and need to be re-written every time the firmware sets
them. To achieve this the register status is verified after certain WMI events
from the firmware.

The coverage class may not be modified temporarily right after the card
re-initializes the registers. This is for example the case during scanning.

Thanks to Sebastian Gottschall <s.gottschall@dd-wrt.com> for initially
working on a userspace support for this. This patch wouldn't have been
possible without this documentation.

Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: fix rfc1042 header retrieval in QCA4019 with eth decap mode

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: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: spelling and miscellaneous neatening

Correct some trivial comment typos.
Remove unnecessary parentheses in a long line.

Signed-off-by: Joe Perches <joe@perches.com>
[kvalo@qca.qualcomm.com: drop the change for return]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: remove 4-addr padding related hw_param configuration

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: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: properly remove padding from the start of rx payload

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: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
[Rename operations to hw_ops for other purposes]
Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add provision for Rx descriptor abstraction

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: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
[Rename operations to hw_ops for other purposes]
Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: move ath10k_hw_params definition to hw.h

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: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: enable support for QCA9888

QCA9888 shares the same configuration with QCA99X0
with NSS=2.

Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: remove unused member in ath10k_hw_regs

rtc_state_cold_reset_mask is unused in ath10k_hw_regs.
instead fixed delays are used.

Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: simplify pktlog htt event processing

It is expected that all pktlog events for 10.4 firmware based solutions
should come through CE8 where as in case of 10.2 firmware based solutions,
it should come through one of the HTT events (HTT_T2H_MSG_TYPE_PKTLOG).

But from experiments with 10.4 based solutions, it is observed that pktlog
event for ATH_PKTLOG_TYPE_TX_MSDU_ID is coming through HTT pktlog event.
Currently, we always parse with 10.2 pktlog header which will lead to
pktlog decoding issues (payload length mismatch exceptions)

For trace points, it is required to provide only the payload size. So
fixing this by simplifying the payload size calculation without the use of
ath10k pktlog headers.

While there, remove the unused ath10k pktlog headers.

Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: fix cycle counter wraparound handling for QCA4019

In QCA4019, cycle counter wraparound is not tied to rx
clear counter. Each counter would wraparound individually
and after wraparound the respective counter will be reset
to 0x7fffffff while other counter still running unaffected.
Define a new wraparound type for this behaviour and handle
it separately so that rx clear counter wraparound is also
handled just like cycle counter. With this type of
wraparound we can accurately compute and report channel
active/busy time when any of the counter overflows.

Fixes: ee9ca147c59 ("ath10k: Fix survey reporting with QCA4019")
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: define an enum to enable cycle counter wraparound logic

QCA988X hw implements a different cycle counter wraparound
behaviour when compared to QCA4019. To properly handle different
wraparound logic for these chipsets replace already available
bool hw_params member, has_shifted_cc_wraparound, with an
enum which could be extended to handle different wraparound
behaviour. This patch keeps the existing logic functionally
same and a prepares cycle counter wraparound handling to
extend for other chips.

Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
[kvalo@qca.qualcomm.com: change also QCA9887 wrap type]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: fix CCK h/w rates for QCA99X0 and newer chipsets

CCK hardware table mapping from QCA99X0 onwards got revised.
The CCK hardware rate values are in a proper order wrt. to
rate and preamble as below

ATH10K_HW_RATE_REV2_CCK_LP_1M = 1,
ATH10K_HW_RATE_REV2_CCK_LP_2M = 2,
ATH10K_HW_RATE_REV2_CCK_LP_5_5M = 3,
ATH10K_HW_RATE_REV2_CCK_LP_11M = 4,
ATH10K_HW_RATE_REV2_CCK_SP_2M = 5,
ATH10K_HW_RATE_REV2_CCK_SP_5_5M = 6,
ATH10K_HW_RATE_REV2_CCK_SP_11M = 7,

This results in reporting of rx frames (with CCK rates)
totally wrong for QCA99X0, QCA4019. Fix this by having
separate CCK rate table for these chipsets with rev2 suffix
and registering the correct rate mapping to mac80211 based on
the new hw_param (introduced) 'cck_rate_map_rev2' which shall
be true for any newchipsets from QCA99X0 onwards

Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add board data download from target

The QCA9887 stores its calibration data (board.bin) inside the EEPROM of
the target. This has to be downloaded manually to allow the device to
initialize correctly.

Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>
[kvalo@qca.qualcomm.com: handle -EOPNOTSUPP and s/fetch_board_data/fetch_cal_eeprom]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add QCA9887 chipset support

Add the hardware name, revision, firmware names and update the pci_id
table.

QA9887 HW1.0 is supposed to be similar to QCA988X HW2.0 . Details about
he firmware interface are currently unknown.

Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>
[kvalo@qca.qualcomm.com: add a warning about experimental support]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: enable support for QCA9984

QCA9984 shares the same configuration with QCA99X0.

Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: remove deprecated firmware API 1 support

This has ben deprecated years ago, I haven't heard anyone using it since and
most likely it won't even work anymore. So just remove all of it.

Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: move cal data len to hw_params

ath10k_download_cal_dt() compares obtained cal data content length
against QCA988X_CAL_DATA_LEN (2116 bytes). It was written by keeping
qca988x in mind. In fact, cal data length is more chip specific.
To make ath10k_download_cal_dt() more generic and reusable for other
chipsets (like qca4019), cal data length is moved to hw_params.

Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: change htt tx desc/qcache peer limit config

The number of HTT Tx descriptors and qcache peer
limit aren't hw-specific. In fact they are
firmware specific and should not be placed in
hw_params.

The QCA4019 limits were submitted with the peer
flow control firmware only and to my understanding
there's no non-peer-flow-ctrl QCA4019 firmware.

However QCA99X0 is planned to run firmware
supporting the feature as well. Therefore this
patch enables QCA99X0 to use 2500 tx descriptors
whenever possible instead of just 1424.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: reduce number of peers to support peer stats feature

To enable per peer stats feature we are reducing the number of peers.
Firmware has introduced tx stats feature. We have memory limitation in
firmware to add these additional bytes.

These are the new variables introduced in the firmware.
======== =======================
Variable Bytes required/per rate
======== =======================
TX success packets 1
TX failed packets 1
Retry packets 1
Success bytes 2
TX failed bytes 2
Retry bytes 2
Tx duration 4
Rate 1
Bw and AMPDU flags 1
Total 16 (because of allocation in word pattern)

Firmware sends these tx_stats in pktlog.
If we consider 4 feedbacks at a time, Frimware need about ~1K memory for coding
and 8192 bytes required / per rate [ 4*16*128(peers)].
To accommodate this firmware needs to reduce 10 peers.

This fixes a firmware crash with firmware-5.bin_10.2.4.70.22-2.

Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: populate qca4019 fw specific wmi init params

Some of the parameter like tx/rx chain mask, number of htt tx desc,
qcache active peer count, etc goes via wmi init cmd to qca4019 firmware
are different.

To make use of 10.4 gen_init function for qca4019, change wmi service
ready handler and 10.4 wmi init functions to adapt qca4019 specific
init values.

Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add qca4019 hw params

Add a new entry in hw_params_list for qca4019 with list of
it's own details.

Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: expose hif ops for ahb

Like how pci.c exposes hif ops for the bus specific operation,
expose similar hif ops table for ahb with all required functions
linked to it. Many ath10k_pci_* functions are reused here in hif ops
table. If something is not sharable, new functions are added for ahb
and linked to hif ops table.

Finally, make ath10k_ahb_probe/remove() to perform what is expected
out of it.

Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: include qca4019 register map table

New register table is added for qca4019 to tell about it's
register mapping details.

Nothing much other than this.

Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add basic skeleton to support ahb

qca4019 uses ahb instead of pci where it slightly differs in device
enumeration, clock control, reset control, etc. Good thing is that
ahb also uses copy engine for the data transaction. So, the most of
the stuff implemented in pci.c/ce.c are reusable in ahb case too.

Device enumeration in ahb case comes through platform driver/device
model. All resource details like irq, memory map, clocks, etc for
qca4019 can be fetched from of_node of platform device.

Simply flow would look like,

device tree => platform device (kernel) => platform driver (ath10k)

Device tree entry will have all qca4019 resource details and the same
info will be passed to kernel. Kernel will prepare new platform device
for that entry and expose DT info to of_node in platform device.
Later, ath10k would register platform driver with unique compatible name
and then kernels binds to corresponding compatible entry & calls ath10k
ahb probe functions. From there onwards, ath10k will take control of it
and move forward.

New bool flag CONFIG_ATH10K_AHB is added in Kconfig to conditionally
enable ahb support in ath10k. On enabling this flag, ath10k_pci.ko
will have ahb support. This patch adds only basic skeleton and few
macros to support ahb in the context of qca4019.

Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: adjust the RX packet pad offset at QCA99X0 4addr mode

The QCA99X0 4 addresses RX packets pad 2 bytes at the beginning of
MSDU instead the end of ieee80211 header to keep alignment. The currently RX
data path can't parse the header correctly in this case. This patch fixes it
for QCA99X0.

Signed-off-by: Yanbo Li <yanbol@qca.qualcomm.com>
[kvalo@qca.qualcomm.com: checkpatch fixes and naming changes]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add QCA9377 hw1.0 support

Add new BMI target version and chip id revision. Register it
on supported chips list.

Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: introduce dev_id to hw_params

A follow up patch introducing a QCA9377 hw1.0 support will need
this device identification helper for an explicit distinction of
HWs, as apparently both QCA6174 hw3.0 and QCA9377 share the same BMI
target version (0x0502000x). For the QCA9377 hw1.1 previously
added we were just lucky we did not overlap with the same chip_id_rev.

Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: fix the currently supported QCA9377 target version name

When introducing the original QCA9377 support, the chip target
version was wrongly picked. The chip advertising itself with
bmi target value equal to 0x05020001 is in fact a 1.1 revision.
I realized this once I got a real 1.1 hw to play with.

Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add support for pktlog in QCA99X0

This patch adds pktlog support for 10.4 fw versions.

Signed-off-by: Vivek Natarajan <nataraja@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add QCA9377 chipset support

Add the hardware name, revision and update the pci_id table.

Currently there're two HW ref. designs available I'm aware of,
with 1.0.2 and 1.1 chip revisions. I've access and been using
the first one so far and this patch cover only it.

QCA9377 inherits most of the stuff (e.g. fw interfaces)
from QCA61x4 design, so the integration was pretty straightforward.

Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add FW API support to test mode

Add WMI-TLV and FW API support in ath10k testmode.
Ath10k can get right wmi command format from UTF image
to communicate UTF firmware.

Signed-off-by: Alan Liu <alanliu@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add board 2 API support

QCA6174 needs different board files based on board type. To make it easier to
distribute multiple board files and automatically choose correct board file
create a simple TLV file format following the same principles as with FW IEs.
The file is named board-2.bin and contain multiple board files. Each board file
then can have multiple names.

ath10k searches for file board-N.bin (where N is the interface version number
for the board file, just like we for firmware files) in /lib/firmware/*, for
example for qca99x0 it will try to find it here:

/lib/firmware/ath10k/QCA99X0/hw2.0/board-2.bin

If ath10k doesn't find board-2.bin then it will fallback to the old board.bin file.

This patch adds a simple name scheme using pci device id which for now will be
used by qca6174:

bus=%s,vendor=%04x,device=%04x,subsystem-vendor=%04x,subsystem-device=%04x

This removes the old method of having subsystem ids in ar->spec_board_id and
using that in the board file name.

Signed-off-by: Manikanta Pubbisetty <c_mpubbi@qti.qualcomm.com>
[kvalo@qca.qualcomm.com: simplified the file format, rewrote commit log, other smaller changes]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: fix MSI-X registering for qca99x0

In case of qca99x0 and MSI-X supported/enabled we
failed during interrupts registering with message:

ath10k_pci 0000:04:00.0: failed to request MSI-X ce irq 50: -22

Issue/fix was reproduced/tested using Dell Latitude E6430 laptop.

Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: fix DMA related firmware crashes on multiple devices

Some platforms really don't like DMA bursts of 256 bytes, and this
causes the firmware to crash when sending beacons.
Also, changing this based on the firmware version does not seem to make
much sense, so use 128 bytes for all versions.

Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add cycle/rx_clear counters frequency to hw_params

The frequency at which cycle/rx_clear counters are running might
change from one target type to another. QCA99X0 is running the
counters at 150Mhz while QCA9888X and QCA6174 are running at 88Mhz.
Add a new entry to hw_params to store the target specific frequency
and use it in msecs conversion. This change fixes inconsistent
channel active/busy time.

Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: increase max client to 512 in qca99x0

When max client was set to 512 in qca99x0, there was host memory
alloc failure during wmi service ready event handling. This issue
got resolved now, increasing max client limit from 256 to 512.

Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: enable raw encap mode and software crypto engine

This patch enables raw Rx/Tx encap mode to support software based
crypto engine. This patch introduces a new module param 'cryptmode'.

cryptmode:

0: Use hardware crypto engine globally with native Wi-Fi mode TX/RX
encapsulation to the firmware. This is the default mode.
1: Use sofware crypto engine globally with raw mode TX/RX
encapsulation to the firmware.

Known limitation:
A-MSDU must be disabled for RAW Tx encap mode to perform well when
heavy traffic is applied.

Testing: (by Michal Kazior <michal.kazior@tieto.com>)

a) Performance Testing

cryptmode=1
ap=qca988x sta=killer1525
killer1525 -> qca988x 194.496 mbps [tcp1 ip4]
killer1525 -> qca988x 238.309 mbps [tcp5 ip4]
killer1525 -> qca988x 266.958 mbps [udp1 ip4]
killer1525 -> qca988x 477.468 mbps [udp5 ip4]
qca988x -> killer1525 301.378 mbps [tcp1 ip4]
qca988x -> killer1525 297.949 mbps [tcp5 ip4]
qca988x -> killer1525 331.351 mbps [udp1 ip4]
qca988x -> killer1525 371.528 mbps [udp5 ip4]
ap=killer1525 sta=qca988x
qca988x -> killer1525 331.447 mbps [tcp1 ip4]
qca988x -> killer1525 328.783 mbps [tcp5 ip4]
qca988x -> killer1525 375.309 mbps [udp1 ip4]
qca988x -> killer1525 403.379 mbps [udp5 ip4]
killer1525 -> qca988x 203.689 mbps [tcp1 ip4]
killer1525 -> qca988x 222.339 mbps [tcp5 ip4]
killer1525 -> qca988x 264.199 mbps [udp1 ip4]
killer1525 -> qca988x 479.371 mbps [udp5 ip4]

Note:
- only open network tested for RAW vs nwifi performance comparison
- killer1525 (qca6174 hw2.2) is 2x2 device (hence max 866mbps)
- used iperf
- OTA, devices a few cm apart from each other, no shielding
- tcpX/udpX, X - means number of threads used

Overview:
- relative Tx performance drop is seen but is within reasonable and
expected threshold (A-MSDU must be disabled with RAW Tx)

b) Connectivity Testing

cryptmode=1
ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta OK
ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta OK
ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta OK
ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta OK
ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta OK
ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta OK
ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta OK
ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta OK
ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br OK
ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br OK
ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br OK
ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br OK
ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br OK
ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br OK
ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br OK
ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br OK
ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br1vlan OK
ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br1vlan OK
ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br1vlan OK
ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br1vlan OK
ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br1vlan OK
ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br1vlan OK
ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br1vlan OK
ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br1vlan OK

Note:
- each test takes all possible endpoint pairs and pings
- each pair-ping flushes arp table
- ip6 is used

c) Testbed Topology:

1ap1sta:
[ap] ---- [sta]

endpoints: ap, sta

1ap1sta2br:
[veth0] [ap] ---- [sta] [veth2]
| | | |
[veth1] | \ [veth3]
\ / \ /
[br0] [br1]

endpoints: veth0, veth2, br0, br1
note: STA works in 4addr mode, AP has wds_sta=1

1ap1sta2br1vlan:
[veth0] [ap] ---- [sta] [veth2]
| | | |
[veth1] | \ [veth3]
\ / \ /
[br0] [br1]
| |
[vlan0_id2] [vlan1_id2]

endpoints: vlan0_id2, vlan1_id2
note: STA works in 4addr mode, AP has wds_sta=1

Credits:

Thanks to Michal Kazior <michal.kazior@tieto.com> who helped find the
amsdu issue, contributed a workaround (already squashed into this
patch), and contributed the throughput and connectivity tests results.

Signed-off-by: David Liu <cfliu.tw@gmail.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Tested-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add 10.4 fw specific htt msg definitions

New htt event table is added for 10.4 firmware. Following new htt
events are available only 10.4. adding this to generic htt event
table,
HTT_T2H_MSG_TYPE_EN_STATS,
HTT_T2H_MSG_TYPE_TX_FETCH_IND,
HTT_T2H_MSG_TYPE_TX_FETCH_CONF,
HTT_T2H_MSG_TYPE_TX_LOW_LATENCY_IND

Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: adjust default peer limits if qcache enabled in 10.4 fw

10.4 firmware supports upto 512 clients when qcache feature is enabled.
Make adjustment on default max peer count, active peers, number of tid in
such case to meet qcache requirement. 10.4 fw has extra unit info flag
NUM_UNITS_IS_NUM_ACTIVE_PEERS which is also handled in this patch.

Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: fill 10.4 fw wmi init cmd default values

Define 10.4 wmi init command structure and introduce new function
ath10k_wmi_10_4_op_gen_init() to fill default values for each field
which goes as part of wmi init cmd to 10.4 firmware.

Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: include new wmi op version for 10.4 fw

qca99X0 chip uses firmware version 10.4. Define a new macro
ATH10K_FW_WMI_OP_VERSION_10_4 for 10.4 firmware and include
in switch cases where ATH10K_FW_WMI_OP_VERSION_* is used
to avoid compilation error.

Signed-off-by: Raja Mani <rmani@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: Add support for code swap

Code swap is a mechanism to use host memory to store
some fw binary code segment. Ath10k host driver allocates
and loads the code swap binary into the host memory and
configures the target with the host allocated memory
information at the address taken from code swap binary.
This patch adds code swap support for firmware binary.
Code swap binary for firmware bin is available in
ATH10K_FW_IE_FW_CODE_SWAP_IMAGE.

Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: Extend CE src desc flags for interrupt indication

QCA99X0 uses two new copy engine src desc flags for interrupt
indication. Bit_2 is to mark if host interrupt is disabled after
processing the current desc and bit_3 is to mark if target interrupt
is diabled after the processing of current descriptor.
CE_DESC_FLAGS_META_DATA_MASK and CE_DESC_FLAGS_META_DATA_LSB are based
on the target type.

Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: Copy Engine related changes for QCA99X0

QCA99X0 supports upto 12 Copy engines. Host and target
CE configuration table is updated to support new copy engine
pipes. This also fixes the assumption of diagnostic CE by making
CE_7 as the one instead of CE_COUNT - 1.

Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: Add hw register/values for QCA99X0 chip

This is to prepare the driver for QCA99X0 chip support.
This commit adds hw_params, hw register table and hw_values
table for QCA99X0 chip. Please note this is only a partial patch adding
support for QCA99X0, so the device id is not yet added to pci device
table.

Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: Add new reg_address/mask to hw register table

Add more register address and mask which can be different
for newer chip to hw_reg table.

Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: Add a table to store hw specific values

This is to prepare ath10k to support newer chip set.
Values like CE_COUNT, MSI_ASSIGN_CE_MAX and
RTC_STATE_V_ON can be different for different
chips.

Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: handle cycle counter wraparound

When QCA988X cycle counter HW register wraps
around it resets to 0x7fffffff instead of 0. All
other cycle counter related registers are divided
by 2 so they never wraparound themselves. QCA61X4
has a uniform CC and it wraparounds in a regular
fashion though.

Worst case wraparound time is approx 24 seconds
(2**31 / 88MHz). Since scan channel visit times
are max 5 seconds (offchannel case) it is
guaranteed there's been at most 1 wraparound and
it is possible to compute survey active time
value. It is, however, impossible to determine the
point at which Rx Clear Count has been divided by
two so it is not reported upon wraparound.

This fixes some occasional incorrect survey data
on QCA988X as some channels (depending on how/when
scan/offchannel requests were requested) would
have approx 24 sec active time which wasn't
actually the case.

This should improve hostapd ACS a little bit.

Reported-by: Srinivasa Duvvuri <sduvvuri@chromium.org>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: move cycle_count macro

The macro isn't WMI specific. Instead it is
related to hardware chip so move the macro
accordingly. While at it document the magic value.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: allocate fw resources for iface combinations

The number of 3 vdevs wasn't enough to handle the
worst case for interface combinations in practice.

wpa_supplicant may need up to 4 vifs to have 2
vifs actually connected, i.e. p2pdev + client + 2x
p2p (either p2p client or p2p go).

This fixes worst case warning:

Free vdev map is empty, no more interfaces allowed.

This keeps the ability to associate 32 stations in
AP mode at the cost of not being able to guarantee
that under all circumstances, i.e. some
combinations may consume additional fw peer
entries for internal purposes leaving less
resource for stations in AP mode.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add hw rate definitions

Prepare defines for future use.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: store max tdls vdevs that fw can handle

Currently number of tdls vdevs supported by firmware
is hardcoded. For future usage it is stored in ath10k
structure based on defined value.

Signed-off-by: Marek Puzyniak <marek.puzyniak@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: bump up FW API to 5

Firmware 10.2.4.48-3 now supports management frames over HTT feature and has
ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX. But as 10.2.4 branch has conflicting HTT ids
patch "ath10k: add ATH10K_FW_IE_HTT_OP_VERSION" is needed to fix the issue.
Older ath10k versions don't have support that support and to maintain backwards
compatibility we need bump up the FW API to 5 not break older versions.

Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add ATH10K_FW_IE_HTT_OP_VERSION

Target to host HTT messages are conflicting between 10.x and other
firmware revisions. By maintaining separate HTT T2H tables for each
firmware revisions (main, 10x and tlv) similar to WMI abstraction,
solves the conflicts. Add ATH10K_FW_IE_HTT_OP_VERSION so that the firmware can
advertise the HTT interface to ath10k.

This fix is needed to get management frames over HTT (ie.
ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX disabled) working with 10.2.4.48-2 firmware.
Otherwise there will be unknown htt events and nothing works:

[30087.438343] ath10k_pci 0000:02:00.0: htt event (19) not handled
[30087.448691] ath10k_pci 0000:02:00.0: htt event (19) not handled
[30149.032974] ath10k_pci 0000:02:00.0: htt event (19) not handled

If the firmware does not have ATH10K_FW_IE_HTT_OP_VERSION use the main HTT
interface. That way old firmware images will still work.

Cc: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add WOW patterns support

Add patterns support for WOW.

Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: increase AST table SKID length limit

The current SKID length configuration causes firmware
to reject peer creation for not able to allocate
AST entries for peers. This issue is observed when
least significant 3 bytes are used ramdomly to create
client MAC addresses.

AST table SKID length configuration is increased to
maximum value to fix this issue.

Signed-off-by: SenthilKumar Jegadeesan <sjegadee@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: enable qca6174 hw3.2

The 3.2 revision has a different target BMI
version so it wasn't recognized by ath10k (despite
the chip_id rev being on the supported list
already).

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add support for qca6174

The QCA6174 in combination with new wmi-tlv firmware is capable of
multi-channel, beamforming, tdls and other features.

This patch just makes it possible to boot these devices and do some basic stuff
like connect to an AP without encryption. Some things may not work or may be
unreliable. New features will be implemented later. This will be addressed
eventually with future patches.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: Fix DMA burst size

A value of zero indicates that 128B is the maximum
DMA request size for read/writes. But PCI cards based
on AR9880 can support 256B, so enable this for
the 10.2 firmware.

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add 10.2.4 firmware support

10.2.4 firmware uses bitmask in wmi_resource_config to configure
10.2 firmware features like airtime fairness and rx batch mode instead
of maintaining separete bool entry. This allows new features that can be
configure during init time without breaking backward compatibility.

kvalo: use WMI op version, bump up FW API to 4 to not break older versions of
ath10k

Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: implement wmi-tlv backend

Latest main firmware branch introduced a new WMI
ABI called wmi-tlv. It is not a tlv strictly
speaking but something that resembles it because
it is ordered and may have duplicate id entries.

This prepares ath10k to support new hw.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add ATH10K_FW_IE_WMI_OP_VERSION

Instead of using feature flags, add new 32 bit variable for managing different
WMI versions. This makes it firmware interface tests a bit less convoluted,
especially when we add one more interface.

Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: fix station count enforcement

The number of peers isn't directly translatable to
the number of stations because ath10k needs to
reserve a few extra peers for special cases like
multi-vif concurrency.

The previous limit was 126 and 15 stations in AP
mode for 10.x and main firmware branches
respectively. The limit is now 128 and 16 which
was the original intention.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: mask/unmask msi fw irq

This was the final missing bit to making sure the
device doesn't assert interrupts to host.

This should fix possible race when target crashes
during driver teardown.

This also removes an early warm reset workaround
during pci probing.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: retrieve calibration data from file

A frequent request have been to be able to provide calibration data from a
file as some of the AP devices store the calibration data on an MTD partition.
This patchset adds support for that and also makes it easier to add Device Tree
support later on.

The calibration data is found by using the id string provided by dev_name()
using this format:

cal-<bus>-<id>.bin

With PCI the id string contains bus, slot and func values. For example for a
PCI device in bus 2 slot 0, ath10k will try to retrieve a calibration data from
a file:

/lib/firmware/ath10k/cal-pci-0000:02:00.0.bin

The calibration data sequence is:

1. Check with request_firmware() if there's a calibration file
("cal-<bus>-<id>.bin") on the filesystem for this device. If yes, use that. If
not, goto 2

2. Check if otp.bin is able to successfully load the calibration data
from OTP. If yes, use that. If not, goto 3.

4. Print an error message that no calibration data found and stop driver
initialization for this device.

Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: advertise all possible firmware(-api) files

This is required if we take into account possibility to load the driver
from initrd (RAM disk), so in other words: very early in the boot process,
before the file system is visible.

In such case we need to have the firmware files accessible from ram disk too,
and this patch guarantee this.

Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add tracing for ath10k_htt_pktlog

This is useful for collecting pktlog statistics of tx, rx
and rate information, so add tracing for the API call.

Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add cal_data debugfs file

Provide calibration data used by the firmware to user space via a debugfs file.
This makes it easier to debug calibration related problems.

Example:

sudo cp /sys/kernel/debug/ieee80211/phy0/ath10k/cal_data 1.cal

Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add testmode

Add testmode interface for starting and using UTF firmware which is used to run
factory tests. This is implemented by adding new state ATH10K_STATE_UTF and user
space can enable this state with ATH10K_TM_CMD_UTF_START command. To go back to
normal mode user space can send ATH10K_TM_CMD_UTF_STOP.

Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: provide firmware crash info via debugfs

Store the firmware registers and other relevant data to a firmware crash dump
file and provide it to user-space via debugfs. Should help with figuring out
why the firmware crashed.

kvalo: remove dbglog support, rework and refactor the code to avoid ifdefs and
otherwise simplify it as well

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

ath10k: add support for 10.2 firmware

The 10.2 firmware is a successor of 10.1 firmware
(formerly identified as 10.x). Both share a lot
but have some slight ABI differences that need to
be taken care of.

The 10.2 firmware introduces some new features but
those can be added in subsequent patches. This
patch makes ath10k boot and work with 10.2 with
comparable functionality to 10.1.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: advertise only firmware API 2 files

We do not really support older firmware API 1 anymore, so better remove
MODULE_FIRMWARE() declarations for them and only list for API 2 files.

Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: fix device initialization routine

Hardware CUS232 version 2 has some issues with cold
reset that lead to Data Bus Errors or system hangs
in some cases. It's safer to use warm reset when
possible as it shouldn't trigger the
aforementioned issues.

Prefer warm reset over cold reset. However since
warm reset doesn't work after FW crash make sure to
fallback to cold reset when booting up the HW.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Marek Puzyniak <marek.puzyniak@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: track number of existing peers

To not exceed number of allowed clients (AP mode), make sure to
check how many of them are already on the peers list.

10.X firmware support up to 127 peers, non-AP centric firmwares 16.

Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: don't consume other's shared interrupts

ath10k assumed all interrupts were directed to it.
This isn't the case for legacy shared interrupts.
ath10k consumed interrupts for other devices.

Check device irq status and return IRQ_NONE when
appropriate.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: fix RX performance when using AP 10.X FW

Due to oversight AP 10.X support was merged with
Ethernet RX decap mode.

Only Native Wifi RX decap mode guarantees IP
header is properly aligned and avoids sk_buff data
realignment (which is very expensive
performance-wise) in mac80211.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: implement firmware IE container support

Firmware IE containers can dynamically provide various information what
firmware supports. Also it can embed more than one image so updating firmware
is easy, user just needs to update one file in /lib/firmware/.

The firmware API 2 or higher will use the IE container format, the current API
1 will not use the new format but it still is supported for some time. FW API 2
files are named as firmware-2.bin (which contains both firmware and otp images)
and API 1 files are firmware.bin and otp.bin.

Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add TARGET values for 10.x firmware

Introduce all TARGET specific values for 10.x firmware.
Some of them are common for both firmwares we will support,
but to avoid confusion, define everything with prefix 10X_.

Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: drop the fw versioning sanity check

It was corrupted and leading to compilation warning
core.c: In function 'ath10k_check_fw_version':
core.c:79: warning: comparison is always true due to limited range of data type

Since we are going to support new FW track in the driver,
the sanity check for fw version number would be an overkill
then. This is just for information purposes anyway.

Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: align RX frames properly

Ethernet-like decapping mode leaves IP protocol
frame not aligned to 4-byte boundaries. This leads
to re-aligning in mac80211 which in turn leads to
poor CPU cache behaviour on some machines.

Since HW doesn't allow to change payload offset
properly the solution is to force HW to decap in
Native Wifi mode which always has 24-bytes long
802.11 header (even for QoS frames). This means IP
frame is properly aligned in this decap mode.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: check chip id from the soc register during probe

ath10k doesn't support qca988x hw1.0 boards anymore. Unfortunately
the PCI id is the same in hw1.0 and hw2.0 so ath10k tries to use
hw1.0 boards anyway. But without hw1.0 workarounds in place
ath10k just crashes horribly.

To avoid using hw1.0 boards at all add a chip id detection
and fail the probe if hw1.0 is detected:

[ 5265.786408] ath10k: ERROR: qca988x hw1.0 is not supported
[ 5265.786497] ath10k: Unsupported chip id 0x043200ff
[ 5265.786574] ath10k: could not register driver core (-95)
[ 5265.793191] ath10k_pci: probe of 0000:02:00.0 failed with error -95

Also add a warning if there's an unknown chip id but continue
the boot process normally anyway.

Reported-by: Zaki Bakar <zaki.bm@gmail.com>
Tested-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: add support for HTT 3.0

New firmware comes with new HTT protocol version.
In 3.0 the separate mgmt tx command has been
removed. All traffic is to be pushed through data
tx (tx_frm) command with a twist - FW seems to not
be able (yet?) to access tx fragment table so for
manamgement frames frame pointer is passed
directly.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: update supported FW build version

The latest supported and available FW build is 1.0.0.636.
Reflect this in ath10k code.

Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: Remove qca98xx hw1.0 support

Since the firmware support is no longer available for hw1.0,
drop all code (especially workarounds) for those units.

Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath10k: mac80211 driver for Qualcomm Atheros 802.11ac CQA98xx devices

Here's a new mac80211 driver for Qualcomm Atheros 802.11ac QCA98xx devices.
A major difference from ath9k is that there's now a firmware and
that's why we had to implement a new driver.

The wiki page for the driver is:

http://wireless.kernel.org/en/users/Drivers/ath10k

The driver has had many authors, they are listed here alphabetically:

Bartosz Markowski <bartosz.markowski@tieto.com>
Janusz Dziedzic <janusz.dziedzic@tieto.com>
Kalle Valo <kvalo@qca.qualcomm.com>
Marek Kwaczynski <marek.kwaczynski@tieto.com>
Marek Puzyniak <marek.puzyniak@tieto.com>
Michal Kazior <michal.kazior@tieto.com>
Sujith Manoharan <c_manoha@qca.qualcomm.com>

Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>