The removed ATH9K_SLOT_TIME_X constants simply map the value in microseconds
to the same integer. These constants were not used consistently, so fix the
inconsistency issue by replacing all occurances with the integer equivalent.
Signed-off-by: Benjamin Berg <benjamin.berg@open-mesh.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

The ath9k driver modifies the TSF for VIFs for the purpose of sending
beacons in a staggered fashion. This patch exposes this VIF specific
adjustment of the TSF value to mac80211. Without the change the TSF
routines handle the hardware TSF value instead of the actual TSF value as
seen on the air.
Signed-off-by: Benjamin Berg <benjamin.berg@open-mesh.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

These changes make ath9k_hw_reset more consistent with other places that
handle the TSF value by using the same helper routine.

A slight improvement is to not assume that a fixed time of 1.5ms has
passed for the initval writes when compared to the first write attempt.
Instead the TSF value is re-calculated which will yield a higher accuracy
of the restored TSF timer.
Signed-off-by: Benjamin Berg <benjamin.berg@open-mesh.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

The ath9k TSF handling routines need to be aware of the channel context that
is being modified. With this change the TSF related values that are stored
in each channel context will be correctly tracked and the harware will only
be updated if the modified context is currently the active one.

Without this change the TSF modifications done using these routines would
for example be lost during a hardware reset as done by ath_complete_reset.
Signed-off-by: Benjamin Berg <benjamin.berg@open-mesh.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Beacons were not send out at (timestamp % beacon_time == 0) for interfaces
other than the primary one. To send out beacons with the correct timestamp
according to 10.1.3.2 of the 802.11 standard the tsf_adjustment has to be
set to the negative time difference instead of positive. This way the
later beacons get corrected to have a lower (and similar) timestamp with
regard to the beacon from slot 0.

I am not aware about any issues that have been caused by this.
Signed-off-by: Benjamin Berg <benjamin.berg@open-mesh.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

No functional changes, this simply makes the code easier to understand
because all initialization based on ath9k_platform_data is now within
one function.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath9k_hw_init_macaddr unconditionally returns 0 in all cases, making the
return value unnecessary.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Currently setting the MAC address via ath9k_platform_data works only due
to the order in which init.c sets common->macaddr, which is done after
ath9k_hw_init_macaddr was executed. It would be better if the latter
was independent of the order in which it's being called.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

No functional changes - this only removes a variable which is set but
never read.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Some devices running OpenWrt need this and it makes sense to add this
to ath9k_platform_data as the next patches will add a devicetree
(boolean) property for it as well.
Suggested-by: Vittorio Gambaletta <openwrt@vittgam.net>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Fix up the wcn36xx_smd_update_scan_params() to work with non-ancient
versions of the firmware and support actually specifying the list of
channels.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

The CCU block in WCNSS is configured for appropriate routing of
interrupts from the DXE to the application cpu, this is not dependant on
the iris version (wcn3660 vs wcn3680), but rather if the SoC has a riva
or pronto built in.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Split the wcnss mmio space into explicit regions for ccu and dxe and
acquire these from the node referenced by the qcom,mmio phandle.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

In preparation for handling incoming messages from IRQ context, change
the indication list lock to a spinlock
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Merge the two allocation instead of separately allocating room for the
indication payload.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Print an ath10k error message rather a call trace when HTT op version is
not found from firmware META data (IE). This should be sufficient to figure
out what went wrong.
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

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>

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>

If WMI and/or firmware has issues removing the peer object,
then we still need to clean up the peer object in the driver.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Not sure this can happen, but seems like a reasonable sanity
check.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

just to comply to coding style.
Signed-off-by: Eduardo Abinader <eduardo.abinader@riverbed.com>
Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

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>

<linux/semaphore.h> is not used anymore, so just remove the include.
Signed-off-by: Chaehyun Lim <chaehyun.lim@gmail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

While debugging OS crashes due to firmware crashes, I enabled
kasan, and it noticed that peer objects were being used-after-freed.

Looks like there are two places we could be leaving stale references
in the peer-map, so clean that up.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Otherwise, the txrx-compl-task may access some bad memory?
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

cfg80211/nl80211 interface changes for per STA total rx-duration and
very basic 'ath10k_sta_statistics'  mac80211 callback is implemented
to extend support for per station statistics from the driver.

Also provision in 'iw dev wlan#N station dump' to parse rx-duration
is supported. So its safer to remove the debugfs entry for per STA
rx-duration
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Enable support for 'drv_sta_statistics' callback.
Export rx_duration support if available to cfg80211/nl80211

This can also act as a placeholder for any new per STA stats support
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

10.4 'extended peer stats' will be not be appended with normal peer stats
data and they shall be coming in separate chunks. Fix this by maintaining
a separate linked list 'extender peer stats' for 10.4 and update
rx_duration for per station statistics. Also parse through beacon filter
(if enabled), to make sure we parse the extended peer stats properly.
This issue was exposed when more than one client is connected and
extended peer stats for 10.4 is enabled

The order for the stats is as below
S - standard peer stats, E- extended peer stats, B - beacon filter stats

{S1, S2, S3..} -> {B1, B2, B3..}(if available) -> {E1, E2, E3..}

Fixes: f9575793 ("ath10k: enable parsing per station rx duration for 10.4")
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

The function ar9003_hw_apply_minccapwr_thresh takes as second parameter not
a pointer to the channel but a boolean value describing whether the channel
is 2.4GHz or not. This broke (according to the origin commit) the ETSI
regulatory compliance on 5GHz channels.

Fixes: 3533bf6b ("ath9k: Fix regulatory compliance")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Cc: Simon Wunderlich <sw@simonwunderlich.de>
Cc: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Just setting the proper return for reading beyond the eeprom data.
Signed-off-by: Eduardo Abinader <eduardo.abinader@riverbed.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Found this obvious typo while going through the spectral
code design in ath10k
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Disable TX_STBC for both HT and VHT if the devices tx chainmask is '1'
TX_STBC is required only for devices with tx_chainmask > 1. This fixes
a ping failure for QCA9887 (1x1) in HT/VHT mode
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Enable beacon loss detection support for 10.4 by handling
roam event. With this change QCA99X0 station is able to
detect beacon loss when the AP is powered off
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Smatch warns about a number of cases in ath10k where a pointer is
null-checked after it has already been dereferenced, in code involving
ath10k private virtual interface pointers.

Fix these by making the dereference happen later.

Addresses the following smatch warnings:

drivers/net/wireless/ath/ath10k/mac.c:3651 ath10k_mac_txq_init() warn: variable dereferenced before check 'txq' (see line 3649)
drivers/net/wireless/ath/ath10k/mac.c:3664 ath10k_mac_txq_unref() warn: variable dereferenced before check 'txq' (see line 3659)
drivers/net/wireless/ath/ath10k/htt_tx.c:70 __ath10k_htt_tx_txq_recalc() warn: variable dereferenced before check 'txq->sta' (see line 52)
drivers/net/wireless/ath/ath10k/htt_tx.c:740 ath10k_htt_tx_get_vdev_id() warn: variable dereferenced before check 'cb->vif' (see line 736)
drivers/net/wireless/ath/ath10k/txrx.c:86 ath10k_txrx_tx_unref() warn: variable dereferenced before check 'txq' (see line 84)
drivers/net/wireless/ath/ath10k/wmi.c:1837 ath10k_wmi_op_gen_mgmt_tx() warn: variable dereferenced before check 'cb->vif' (see line 1825)
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

The below warning message seems to hit occasionally with the following
combination (IPQ4019 + ACS scan) where we receive packets as a self peer
when hostapd does ACS when we bring up AP mode . ath10k has the below
fall back mechanism to fetch current operating channel in rx (it will
check for the next channel tracking variable if the current one is NULL)

	[scan channel] --> [rx channel] --> [peer channel] -->
	[vdev channel] -->  [any vdev channel] --> [target oper channel]

'scan channel' and 'target operating channel' are directly fetched from
firmware events. All the others should be updated by mac80211.

During ACS scan we wouldn't have a valid channel context
assigned from mac80211 ('ar->rx_channel'), and also relying on
('ar->scan_channel') is not helpful (it becomes NULL when it goes to
BSS channel and also when the scan event is completed). In short we
cannot always rely on these two channel tracking variables.

'Target Operating Channel' (ar->tgt_oper_chan) seems to keep track of
the current operating even while we are doing ACS scan and etc. Hence
remove this un-necessary warning message and continue with
target_operating channel. At the worst case scenario when the target
operating channel is invalid (NULL) we already have an ath10k warning
message to notify we really don't have a proper channel configured in
rx to update the rx status("no channel configured; ignoring frame(s)!")

    WARNING: CPU: 0 PID: 0 at ath/ath10k/htt_rx.c:803
    [<c0318838>] (warn_slowpath_null) from [<bf4a0104>]
    (ath10k_htt_rx_h_channel+0xe0/0x1b8 [ath10k_core])
    [<bf4a0104>] (ath10k_htt_rx_h_channel [ath10k_core]) from
    [<bf4a025c>] (ath10k_htt_rx_h_ppdu+0x80/0x288 [ath10k_core])
    [<bf4a025c>] (ath10k_htt_rx_h_ppdu [ath10k_core]) from
    [<bf4a1a9c>] (ath10k_htt_txrx_compl_task+0x724/0x9d4 [ath10k_core])
    [<bf4a1a9c>] (ath10k_htt_txrx_compl_task [ath10k_core])

Fixes:3b0499e9 ("ath10k: reduce warning messages during rx without proper channel context")
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Usually when the firmware crashes we check for the value
'FW_IND_EVENT_PENDING' in 'FW_INDICATOR_ADDRESS' and proceed with
disabling the irq and dumping firmware 'crash dump'. Now
when the PCI card is unplugged from the device the PCI controller
seems to generate a spurious interrupt after some time which
was as treated a firmware crash and resulting in the below race
condition (and eventually crashing the system)

	ath10k_core_unregister -> ath10k_core_free_board_files

	...... device unplug spurious interrupt .........

	ath10k_pci_taklet -> ath10k_pci_fw_crashed_dump  ...etc

Clearly even after the firmware board files related data structure
is freed up we are getting a spurious interrupt from PCI with 0xfffffff
in the 'FW_INDICATOR_ADDRESS' resulting in scheduling of the pci tasklet
and doing a crash dump, printing f/w board related info resulting in the
below crash. Fix this by detecting this spurious interrupt in ath10k PCI
irq handler itself and return IRQ_NONE. Thanks to Michal Kazior for
helping us conclude the most appropriate fix.

Call trace:

 EIP is at ath10k_debug_print_board_info+0x39/0xb0
[ath10k_core]
EAX: 00000000 EBX: d4de15a0 ECX: 00000000 EDX: 00000064
ESI: f615ddd0 EDI: f8530000 EBP: f615de3c ESP: f615ddbc
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
CR0: 80050033 CR2: 00000004 CR3: 01c0a000 CR4: 000006f0
Stack:
 f615ddd0 00000064 f8b4ecdd 00000000 00000000 00412f4e
00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Call Trace:
  [<f8b1f517>] ath10k_print_driver_info+0x17/0x30
[ath10k_core]
[<f875463a>] ath10k_pci_fw_crashed_dump+0x7a/0xe0
[ath10k_pci]
[<f87549d0>] ath10k_pci_tasklet+0x70/0x90 [ath10k_pci]
[<c106151e>] tasklet_action+0x9e/0xb0

Cc: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Since stations can now be added before association
(NL80211_FEATURE_FULL_AP_CLIENT_STATE support),
no supported rates are set when the station is added
to the fw, resulting in fw recovery.

Fix it by first configuring the AP basic rates as
the station configured rates (when the station is
first added to the driver), and after the station
was authorized re-configure it, now with the actual
supported rates.
Signed-off-by: Guy Mishol <guym@ti.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

We obviously don't want to fall through in that switch. With this change
1) We wait for event (triggered by p2p_disc) as expected
2) We remove interface manually on timeout
3) We return 0 on success instead of -ENOTSUPP
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

This header provides two inline functions using struct brcmf_if so we
need core.h to avoid:

drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h: In function ‘ndev_to_prof’:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h:368:13: error: dereferencing pointer to incomplete type
  return &ifp->vif->profile;
             ^
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h: In function ‘ndev_to_vif’:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h:374:12: error: dereferencing pointer to incomplete type
  return ifp->vif;
            ^
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

This function can work just fine with const pointer, it only calls
alloc_netdev which take const as well. Moreover it makes this function
more flexible as some cfg80211 callback may provide const char * as
well, e.g. add_virtual_intf. This will be needed for more advanced
interface management.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>