GCMP MIC length is not filled for GCMP/GCMP-256 cipher suites in
PMF enabled case. Due to mismatch in MIC length, deauth/disassoc frames
are unencrypted.
This patch fills proper MIC length for GCMP/GCMP-256 cipher suites.

Tested HW: QCA9984, QCA9888
Tested FW: 10.4-3.6-00104
Signed-off-by: NYingying Tang <yintang@codeaurora.org>
Co-developed-by: NSowmiya Sree Elavalagan <ssreeela@codeaurora.org>
Signed-off-by: NSowmiya Sree Elavalagan <ssreeela@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

BTCOEX feature is not supported by all QCA4019 chipsets.
Since btcoex enabled by default in firmware, host needs to
enable COEX support depends on the hardware. Enabling it
by default in unsupported hardware will cause some
feature disabled in hardware.
This patch will read btcoex_support flag and
wlan priority gpio pin number from DT. Depends on the
btcoex_support flag value host will expose BTCOEX support
and wlan priority gpio pin number to target.

Testing:
	* Tested HW : QCA4019
	* Tested FW : 10.4-3.2.1.1-00017
Signed-off-by: NTamizh Chelvam <tamizhr@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The management packets, send to firmware via WMI, are
mapped using the direction DMA_TO_DEVICE. Currently in
case of wmi cleanup, these buffers are being unmapped
using an incorrect DMA direction. This can cause unwanted
behavior when the host driver is handling a restart
of the wlan firmware.

We might see a trace like below

[<ffffff8008098b18>] __dma_inv_area+0x28/0x58
[<ffffff8001176734>] ath10k_wmi_mgmt_tx_clean_up_pending+0x60/0xb0 [ath10k_core]
[<ffffff80088c7c50>] idr_for_each+0x78/0xe4
[<ffffff80011766a4>] ath10k_wmi_detach+0x4c/0x7c [ath10k_core]
[<ffffff8001163d7c>] ath10k_core_stop+0x58/0x68 [ath10k_core]
[<ffffff800114fb74>] ath10k_halt+0xec/0x13c [ath10k_core]
[<ffffff8001165110>] ath10k_core_restart+0x11c/0x1a8 [ath10k_core]
[<ffffff80080c36bc>] process_one_work+0x16c/0x31c

Fix the incorrect DMA direction during the wmi
management tx buffer cleanup.

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

Fixes: dc405152 ("ath10k: handle mgmt tx completion event")
Signed-off-by: NRakesh Pillai <pillair@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

iw command only show rssi without each chain's rssi on sdio
iw wlan0 station dump
Station a0:40:a0:93:3e:de (on wlan0)
signal:         -82 dBm
signal avg:     -82 dBm

after this patch, it will show each chain's rssi on sdio
Station a0:40:a0:93:3e:de (on wlan0)
signal:         -82 [-84, -88] dBm
signal avg:     -82 [-84, -87] dBm

For QCA6174 PCIe, the ppdu have the correct rssi of each chain, it
indicate rssi of rx data by ath10k_htt_rx_h_signal. For sdio chip, the
rssi of each chain stored in rx management reported by firmware, the
ath10k_wmi_tlv_op_pull_mgmt_rx_ev which used for tlv wmi will get the
rssi of each chain and stored them in wmi_mgmt_rx_ev_arg, then indicate
them to mac80211. For non-tlv wmi chip, it will not get the rssi of each
chain and not indicate to mac80211, for non-tlv wmi chip, this patch will
not have impact. For tlv wmi chip, if the rssi of chain in mgmt is valid,
it will be indicate to mac80211, tested with QCA6174 PCIe/SDIO, the rssi
of 2 chain in mgmt is valid.

rssi of chains in mgmt of QCA6174 SDIO:
92096.652780: ath10k:ath10k_log_warn: ath10k_sdio mmc1:0001:1 rssi[0]:70
92096.657324: ath10k:ath10k_log_warn: ath10k_sdio mmc1:0001:1 rssi[1]:68
92096.662009: ath10k:ath10k_log_warn: ath10k_sdio mmc1:0001:1 rssi[2]:128
92096.666647: ath10k:ath10k_log_warn: ath10k_sdio mmc1:0001:1 rssi[3]:128

rssi of chains in mgmt of QCA6174 PCIe:
[ 1581.049816] ath10k_pci 0000:02:00.0: mgmt rssi[0]:17
[ 1581.049818] ath10k_pci 0000:02:00.0: mgmt rssi[1]:22
[ 1581.049821] ath10k_pci 0000:02:00.0: mgmt rssi[2]:128
[ 1581.049823] ath10k_pci 0000:02:00.0: mgmt rssi[3]:128

after apply this patch, the iw's rssi of PCIe do not changed, result is
same with before.

iw wlan0 station dump of QCA6174 PCIe:
Station 6c:e8:73:b8:92:dc (on wlan0)
        signal:         -70 [-77, -72] dBm
        signal avg:     -69 [-78, -72] dBm

iw wlan-5000mhz station dump of QCA9984 PCIe
connected with 2 client which has 2 chain:
Station 70:48:0f:1f:1a:b2 (on wlan-5000mhz)
        signal:         -47 [-55, -48, -87, -88] dBm
        signal avg:     -42 [-50, -43, -83, -86] dBm
Station ac:c1:ee:39:e3:83 (on wlan-5000mhz)
        signal:         -43 [-46, -45, -79, -84] dBm
        signal avg:     -43 [-46, -46, -82, -83] dBm

Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00017-QCARMSWP-1.
Tested with QCA6174 PCIe with firmware WLAN.RM.4.4.1-00110-QCARMSWP-1.
Tested with QCA9984 PCIe with firmware 10.4-3.9.0.2-00040.
Signed-off-by: NWen Gong <wgong@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The dev_kfree_skb() function performs also input parameter validation.
Thus the test around the shown calls is not needed.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

If firmware reports rate_max > WMI_TPC_RATE_MAX(WMI_TPC_FINAL_RATE_MAX)
or num_tx_chain > WMI_TPC_TX_N_CHAIN, it will cause array out-of-bounds
access, so print a warning and reset to avoid memory corruption.

Tested HW: QCA9984
Tested FW: 10.4-3.9.0.2-00035
Signed-off-by: NMiaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NAlan Liu <alanliu@codeaurora.org>
Signed-off-by: NWen Gong <wgong@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Software version within WMI event ready message was displayed
in a not very useful decimal format. Change this info to be shown
in a hexadecimal format instead.
Signed-off-by: NTomislav Požega <pozega.tomislav@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Add vht_supp_mcs argument to service ready structure and print
supported MCS rates in WMI service ready debug message.
Signed-off-by: NTomislav Požega <pozega.tomislav@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Displays lowest/highest supported channels for both 2ghz and 5ghz
bands as they're fetched within WMI service ready event.
These are shown in a frequency format.
Signed-off-by: NTomislav Požega <pozega.tomislav@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Add lowest/highest 2ghz channel arguments for use within WMI service
ready structure.
Signed-off-by: NTomislav Požega <pozega.tomislav@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The peer param id for PEER_PARAM_USE_FIXED_PWR
is different for tlv and non-tlv firmware. This
causes incorrect peer param to be set by the driver
to the firmware(tlv/non-tlv).

Create seperate peer param map for tlv and non-tlv
firmware and attach the peer param id based on the
firmware type during the init.

Tested HW: WCN3990
Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1
Signed-off-by: NRakesh Pillai <pillair@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Currently instant rx_duration always fetching as zero
in fw_stats debugfs entry if extended peer stats event
supports.

This patch updates instant rx_duration in fw_stats entry
based on extended peer stats and maintaining backward
compatibility for 10.2/10.x.

Tested HW: QCA9984.
Tested FW: 10.4-3.6.0.1-00004.
Signed-off-by: NBalaji Pothunoori <bpothuno@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Currently, rx_duration for each peer is not getting populated in
fw_stats debugfs entry for WCN3990.

WCN3990 firmware sends rx duration for each peer as part of
peer_extd_stats in WMI_UPDATE_STATS_EVENT. To enable peer_extd_stats,
firmware expects host to send fw_stats_req_mask with flag
WMI_TLV_PEER_STATS_EXTD set in WMI_REQUEST_STATS_CMD.

Send fw_stats_req_mask with flag WMI_TLV_PEER_STATS_EXTD set in
WMI_REQUEST_STATS_CMD and parse the peer_extd_stats in
WMI_UPDATE_STATS_EVENT to populate the rx_duration of each peer
in fw_stats debugfs entry.

Currently the driver handles 32-bit rx_duration, but the rx_duration
for WCN3990 can be upto 63 bit. The firmware sends rx_duration split
into two 32-bit fields, with the upper 32-bits being valid only if its
MSB is set. This change handles the 63-bit rx_duration obtained from
WCN3990 and maintain the backward compatibility.

To get the rx_duration of each connected peer :
cat /sys/kernel/debug/ieee80211/phyX/ath10k/fw_stats

Tested HW: WCN3990
Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1
Signed-off-by: NSurabhi Vishnoi <svishnoi@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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 "management" tx completion event. Host extracts ack
rssi values of management packets from their tx completion event.

Tested HW: WCN3990
Tested FW: WLAN.HL.2.0-01617-QCAHLSWMTPLZ-1
Signed-off-by: NAbhishek Ambure <aambure@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Use SPDX identifiers everywhere in ath10k.

Makefile was incorrectly marked in commit b2441318 ("License cleanup: add
SPDX GPL-2.0 license identifier to files with no license"), fix that as well.
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Configure fine timing measurement (FTM) responder role from the
ftm_responder bss param sent by mac80211. With FTM functionality offloaded
to firmware, adding the interface allows userspace to enable or disable
FTM responder functionality. ath10k disables it at the time of interface
creation.

Supported FW: 10.4

Tested on IPQ4019 with firmware: 10.4-3.2.1.1-00022
Signed-off-by: NPradeep Kumar Chitrapu <pradeepc@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Many integrated QCA9984 WiFis in various IPQ806x platform routers
from various vendors (Netgear R7800, ZyXEL NBG6817, TP-LINK C2600,
etc.) have either blank, bogus or non-unique MAC-addresses in
their calibration data.

As a result, OpenWrt utilizes a discouraged binary calibration data
patching method that allows to modify the device's MAC-addresses right
at the source. This is because the ath10k' firmware extracts the MAC
address from the supplied radio/calibration data and issues a response
to the ath10k linux driver. Which was designed to take the main MAC in
ath10k_wmi_event_ready().

Part of the "setting an alternate MAC" issue was already tackled by a
patch from Brian Norris:
commit 9d580466
("ath10k: retrieve MAC address from system firmware if provided")
by allowing the option to specify an alternate MAC-address with the
established device_get_mac_address() function which extracts the right
address from DeviceTree/fwnode mac-address or local-mac-address
properties and saves it for later.

However, Ben Greear noted that the Qualcomm's ath10k firmware is liable
to not properly calculate its rx-bssid mask in this case. This can cause
issues in the popluar "multiple AP with a single ath10k instance"
configurations.

To improve MAC address handling, Felix Fietkau suggested to call
pdev_set_base_macaddr_cmdid before bringing up the first vif and
use the first vif MAC address there. Which is in ath10k_core_start().

This patch implement Felix Fietkau's request to
"call pdev_set_base_macaddr_cmdid before bringing up the first vif".
The pdev_set_base_macaddr_cmdid is already declared for all devices
and version. The driver just needed the support code for this
function.

Tested on:
QCA9880/CUS223, firmwares: 10.2.4.13-2, 10.2.4.70.44, 10.2.4-1.0-00041
QCA9887/MR33 firmware:10.2.4-1.0-00033
QCA4019/RT-AC58U firmware: 10.4-3.4-00104, 10.4-3.5.3-00057
QCA9984/R7800 firmware: Candela Technologies (CT) Firmware

BugLink: https://lists.openwrt.org/pipermail/openwrt-devel/2018-November/014595.html
Fixes: 9d580466 ("ath10k: retrieve MAC address from system firmware if provided")
Cc: Brian Norris <briannorris@chromium.org>
Cc: Ben Greear <greearb@candelatech.com>
Cc: Felix Fietkau <nbd@nbd.name>
Cc: Mathias Kresin <dev@kresin.me>
Signed-off-by: NChristian Lamparter <chunkeey@gmail.com>
Tested-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

TLV based firmware ex. QCA6174, WCN3990 expects key cipher value
set to 9 while non-TLV firmware expects key cipher value set to 8
for enabling GCMP and GCMP-256 cipher suites.

To fix this problem, attach the key cipher suite values based on
wmi version.

Tested HW: WCN3990
Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1
Signed-off-by: NAbhishek Ambure <aambure@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The management frames transmitted are dma mapped with
direction TO_DEVICE, but incorrectly mapped with
direction FROM_DEVICE during tx complete and error cases.

Fix the direction of dma during dma unmap of the
transmitted management frames.

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

Fixes: 38a1390e ("ath10k: dma unmap mgmt tx buffer if wmi cmd send fails")
Signed-off-by: NRakesh Pillai <pillair@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

WCN3990 supports sending tx completion for multiple
management frames bundled together in a single event.

Add support to handle the bundled tx completion
event for WCN3990.

Tested HW: WCN3990
Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1
Signed-off-by: NRakesh Pillai <pillair@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

We already need to zero out memory for dma_alloc_coherent(), as such
using dma_zalloc_coherent() is superflous. Phase it out.

This change was generated with the following Coccinelle SmPL patch:

@ replace_dma_zalloc_coherent @
expression dev, size, data, handle, flags;
@@

-dma_zalloc_coherent(dev, size, handle, flags)
+dma_alloc_coherent(dev, size, handle, flags)
Suggested-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NLuis Chamberlain <mcgrof@kernel.org>
[hch: re-ran the script on the latest tree]
Signed-off-by: NChristoph Hellwig <hch@lst.de>

Add wmi configuration cmd to configure base band(BB) power amplifier(PA)
off timing values in hardware. The default PA off timings were fine tuned
to make proper DFS radar detection in QCA reference design. If ODM uses
different PA in their design, then the same default PA off timing values
cannot be used, it requires different settling time to detect radar pulses
very sooner and avoid radar detection problems. In that case it provides
provision to select proper PA off timing values based on the PA hardware used.
The PA component is part of FEM hardware and new device tree entry
"ext-fem-name" is used to indentify the FEM hardware. And this wmi configuration
cmd is enabled via wmi service flag "WMI_SERVICE_BB_TIMING_CONFIG_SUPPORT".

Other way is to apply these values through calibration data, but recalibration
of all boards out there might not be feasible.

This change tested on firmware ver 10.2.4-1.0-00042 in QCA988X chipset.
Signed-off-by: NBhagavathi Perumal S <bperumal@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The "survey" pointer is the address of an array element.  We know that
it can't be NULL so this check can be removed.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Currently in 10.4 FW, all the received 4addr frames are processed for
source port learning which is enabled by default. This learning can't be
disabled by default in FW since it breaks backward compatibility.

Since ath10k uses mac80211 based 4addr mode, source port learning done in
10.4 FW is redundant and also causes issues when 3addr frames are
transmitted/received for a 4addr station.

One such visible functional impact is when GTK rekey frame from
hostapd based AP to 4addr STA is dropped in AP's 10.4 FW. This is since
GTK rekey EAPOL frame is 3addr frame on AP interface and STA enabled
with 4addr is already allowed for receiving 3addr EAPOL frames.

Source port learning implementation in 10.4 FW drops this 3addr GTK rekey
frame in AP destinated for 4addr STA causing disassociation and
re-association for every GTK rekey session. GTK rekey issue is not seen
when learning is disabled in FW.

To prevent such issues without breaking backward compatibility, FW
advertises new service bit making the source port learning configurable and
this learning is being currently disabled during ath10k vdev creation.

* Tested HW: QCA9984
* Tested FW: 10.4-3.6.0.1-00004
Signed-off-by: NSathishkumar Muruganandam <murugana@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The host driver currently expects the channel info event to be
received in pairs for all the channels, i.e. the first
chan_info event for a particular channel will not have the
COMPLETE flag set and the second chan_info event for the
same channel will have the COMPLETE flag set.

The HL2.0 firmware sends only one channel info event per channel
which is scanned without the COMPLETE flag set. After sending the
chan_info_event for all the channels, the HL2.0 firmware sends a
chan_info_event with COMPLETE flag set to indicate the completion
of the channel info event.

The firmware does not indicate this behavior with any service bitmap
and hence a new firmware feature flag is used to handle the modified
parsing of the channel info events, in the host driver, for the
firmware which sends single channel info event per scanned channel.

Tested HW: WCN3990
Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1
Co-developed-by: NSurabhi Vishnoi <svishnoi@codeaurora.org>
Signed-off-by: NSurabhi Vishnoi <svishnoi@codeaurora.org>
Signed-off-by: NRakesh Pillai <pillair@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This patch helps to get the power save state change of each peer
connected to the AP. With WMI_10_4_PEER_STA_PS_STATECHG_EVENTID
event, ps state of each peer is reported to user space via
debugfs.

Use the below command to get the ps state of each sta:
cat /sys/kernel/debug/ieee80211/phyX/netdev::wlanX/stations/
XX:XX:XX:XX:XX:XX/peer_ps_state

If STA is in power save state, we get the peer_ps_state value as 1.
if STA is not in power save state, we get the peer_ps_state value as 0.
If ps_state event is disabled, we get the peer_ps_state value as 2.

We can enable/disable the ps_state events using the debugfs flag
"ps_state_enable"

echo Y > /sys/kernel/debug/ieee80211/phyX/ath10k/ps_state_enable

Y = 1 to enable and Y = 0 to disable

Tested in QCA4019 with firmware ver 10.4-3.2.1.1-00011
Signed-off-by: NMaharaja Kennadyrajan <mkenna@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The tx_status for management frames is being filled
incorrectly in the flags of skb_cb. This incorrect
flag setting causes the upper layers to consider that
the particular frame was not transmitted properly,
leading to improper behavior.

Set the IEEE80211_TX_STAT_ACK flag in the info flags
of skb_cb, to indicate the successful transmission of
the management frame.

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

Fixes: dc405152Signed-off-by: NRakesh Pillai <pillair@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The vdev-start-response message should cause the
completion to fire, even in the error case.  Otherwise,
the user still gets no useful information and everything
is blocked until the timeout period.

Add some warning text to print out the invalid status
code to aid debugging, and propagate failure code.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This is done in order not to trig the below warning in
ieee80211_rx_napi:

WARN_ON_ONCE(softirq_count() == 0);

ieee80211_rx_napi requires that softirq's are disabled during
execution.

The High latency bus drivers (SDIO and USB) sometimes call the wmi
ep_rx_complete callback from non softirq context, resulting in a trigger
of the above warning.

Calling ieee80211_rx_ni with softirq's already disabled (e.g., from
softirq context) should be safe as the local_bh_disable and
local_bh_enable functions (called from ieee80211_rx_ni) are fully
reentrant.
Signed-off-by: NErik Stromdahl <erik.stromdahl@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

array "ctl_power_table" access index "pream" is initialized with -1 and
is raised as a static analysis tool issue.
[drivers\net\wireless\ath\ath10k\wmi.c:4719] ->
[drivers\net\wireless\ath\ath10k\wmi.c:4730]: (error) Array index -1 is
out of bounds.

Since the "pream" index for accessing ctl_power_table array is initialized
with -1, there is a chance of memory access violation for the cases below.
1) wmi_pdev_tpc_final_table_event change frequency is between 2483 and 5180
2) pream_idx is out of the enumeration ranges of wmi_tpc_pream_2ghz,
wmi_tpc_pream_5ghz
Signed-off-by: NK.T.VIJAYAKUMAAR <vijay.bvb@samsung.com>
[kvalo@codeaurora.org: clean up the warning message]
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Devices may provide their own MAC address via system firmware (e.g.,
device tree), especially in the case where the device doesn't have a
useful EEPROM on which to store its MAC address (e.g., for integrated
Wifi).

Use the generic device helper to retrieve the MAC address, and (if
present) honor it above the MAC address advertised by the card.
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

When running in AP mode, ath10k sometimes suffers from TX credit
starvation. The issue is hard to reproduce and shows up once in a
few days, but has been repeatedly seen with QCA9882 and a large
range of firmwares, including 10.2.4.70.67.

Once the module is in this state, TX credits are never replenished,
which results in "SWBA overrun" errors, as no beacons can be sent.
Even worse, WMI commands run in a timeout while holding the conf
mutex for three seconds each, making any further operations slow
and the whole system unresponsive.

The firmware/driver never recovers from that state automatically,
and triggering TX flush or warm restarts won't work over WMI. So
issue a hardware restart if a WMI command times out due to missing
TX credits. This implies a connectivity outage of about 1.4s in AP
mode, but brings back the interface and the whole system to a usable
state. WMI command timeouts have not been seen in absent of this
specific issue, so taking such drastic actions seems legitimate.
Signed-off-by: NMartin Willi <martin@strongswan.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Debugfs support to do hardware warm reset with WMI command
WMI_PDEV_PARAM_PDEV_RESET for 10.4 and 10.2.4(if wmi
service is enabled in the firmware for backward compatibility).

This change is purely for debugging purpose when hardware hangs/mutes.

This hardware reset won't affect the connectivity but there will be small
pause in data traffic. Here we are doing BB/MAC level reset and hence
whenever the BB/MAC watchdog is triggered, it does a hardware_chip_reset.
So the target will be in the active state.

Below command used to warm reset the hardware.
echo 1 > /sys/kernel/debug/ieee80211/phyX/ath10k/warm_hw_reset

Tested in QCA988X with firmware ver 10.2.4.70.45
Tested in QCA4019 with firmware ver 10.4-3.2.1.1-00011
Signed-off-by: NMaharaja Kennadyrajan <mkenna@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NRakesh Pillai <pillair@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Use dma_zalloc_coherent instead of dma_alloc_coherent
followed by memset 0.
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The India regulatory domain allows CH 173, so add that to the
available channel list.  I verified basic connectivity between
a 9880 and 9984 NIC.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Currently tpc_stats is allocated and is leaked on the return
path if num_tx_chain is greater than WMI_TPC_TX_N_CHAIN. Avoid
this leak by performing the check on num_tx_chain before the
allocation of tpc_stats.

Detected by CoverityScan, CID#1469422 ("Resource Leak")
Fixes: 4b190675 ("ath10k: fix kernel panic while reading tpc_stats")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

In the 10.4-3.6 firmware branch there's a new DFS Host confirmation
feature which is advertised using WMI_SERVICE_HOST_DFS_CHECK_SUPPORT flag.

This new features enables the ath10k host to send information to the
firmware on the specifications of detected radar type. This allows the
firmware to validate if the host's radar pattern detector unit is
operational and check if the radar information shared by host matches
the radar pulses sent as phy error events from firmware. If the check
fails the firmware won't allow use of DFS channels on AP mode when using
FCC regulatory region.

Hence this patch is mandatory when using a firmware from 10.4-3.6 branch.
Else, DFS channels on FCC regions cannot be used.

Supported Chipsets : QCA9984/QCA9888/QCA4019
Firmware Version : 10.4-3.6-00104
Signed-off-by: NSriram R <srirrama@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This enables ath10k/ath9k drivers to collect the specifications of the
radar type once it is detected by the dfs pattern detector unit.
Usage of the collected info is specific to driver implementation.
For example, collected radar info could be used by the host driver
to send to co-processors for additional processing/validation.

Note: 'radar_detector_specs' data containing the specifications of
different radar types which was private within dfs_pattern_detector/
dfs_pri_detector is now shared with drivers as well for making use
of this information.
Signed-off-by: NSriram R <srirrama@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>