The expiration function must not be called when
roc is explicitly cancelled by mac80211. However
since fcf98446 ("ath10k: fix hw roc
expiration") the notification was never sent when
roc actually expired.

This fixes some P2P connection setup issues.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Further testing proved that multi-channel AP+STA
on QCA6174 with RM.2.0-00088 should have powersave
force-disabled to avoid beacon misses/skipping on
either side which in turn could disrupt
communication.

Since AP never has arvif->ps don't even bother
checking it. Other combinations may be broken as
well so disallow powersave with multivif outright
unless firmware advertises otherwise.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

mac80211 already does provide complete IEs for
Probe Requests for hw scan and ath10k firmware was
appending duplicate Supported Rates IEs
unnecessarily.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

10.4 fw supports upto 16 interface in ap mode and 1 interface
in station mode, overall total interfaces supported are 16
interfaces. Populate this limit in wiphy->iface_combinations.
Signed-off-by: NRaja Mani <rmani@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

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: NRaja Mani <rmani@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

wait_event_timeout(), introduced in 'commit 5e3dd157 ("ath10k: mac80211
driver for Qualcomm Atheros 802.11ac CQA98xx devices")' never returns < 0
so the only failure condition to be checked is ==0 (timeout). Further the
return type is long not int - an appropriately named variable is added
and the assignments fixed up.
Signed-off-by: NNicholas Mc Guire <hofrat@osadl.org>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Enable VHT support for IBSS, while mac80211/cfg80211 and
wpa_supplicant already support this.

In my test env, qca988x 2x2 I get:

(udp) ath10k-1 >>>> ath10k-2 (server) -  speed: 419 Mbits/sec
(tcp) ath10k-1 >>>> ath10k-2 (server) -  speed: 404 Mbits/sec

During tests I used wpa_supplicant (latest git version), which
already support IBSS VHT, and choose highest available BW. Also tested with
qca6174.
Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

In the midst of chanctx patch review channel
switching became broken which I failed to notice
until now.

Function ath10k_mac_vif_chan() reports current
chandef which isn't updated until after
switch_vif_chanctx() is returned from.
Consequently the driver just restarted operation
on channels it was residing already instead of
switching to the new ones.

Fixes: 500ff9f9 ("ath10k: implement chanctx API")
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

In practice there's no point in having a copy of
chanctx_conf.

Most of the time the channel pointer (and band
along with it) is accessed and this can't change
after a chanctx is created because switching is
done using explicit chanctx swapping via
switch_vif_chanctx().

The only thing that can change within a
chanctx_conf and is used by the driver is
radar_enabled and channel width. These are however
always accessed in adequate mac80211 callback
context which guarantees safe access to the
chanctx data.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Channel contexts aren't iterable until after
they've been added to the driver. The code assumed
otherwise.

This problem could result in:

 * rx_channel being NULL and forcing Rx path to go
   the slow way to get channel on QCA988X,

 * report incorrect channel when running
   multi-channel on QCA61X4 hw2.1,

 * report incorrect channel after AP channel
   switch.

Fixes: 500ff9f9 ("ath10k: implement chanctx API")
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

mac80211 can update vif powersave state while
disconnected. Firmware doesn't behave nicely and
consumes more power than necessary if PS is
disabled on a non-started vdev. Hence
force-enable PS for non-running vdevs.

This reduces power drain on QCA61X4 from 88mA to
36mA when interface is up and not associated.
QCA988X wasn't measured.
Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Until now only a single fixed tx rate or nss was
allowed to be set.

The patch attempts to improve this by allowing
most bitrate masks. The limitation is VHT MCS
rates cannot be expressed separately using
existing firmware interfaces and only the
following VHT MCS ranges are supported: none, 0-7,
0-8, and 0-9.

This keeps the old behaviour when requesting
single tx rate or single nss. The new bitrate mask
logic is only applied to other cases that would
return -EINVAL until now.

Depending on firmware revisions some combinations
may crash firmware so use with care, please.

This depends on "ath10k: don't use reassoc flag".
Without it key cache would effectively be
invalidated upon bitrate change leading to
communication being no longer possible.

These work:

  iw wlan0 set bitrates legacy-5 6 12 ht-mcs-5 1 2 3
  iw wlan0 set bitrates legacy-5 ht-mcs-5 7 8 9
  iw wlan0 set bitrates legacy-5 24 ht-mcs-5 vht-mcs-5 1:0-9

These won't work:

  iw wlan0 set bitrates legacy-5 ht-mcs-5 vht-mcs-5 1:0-5
  iw wlan0 set bitrates vht-mcs-5 2:7-9

(note the invalid VHT MCS ranges)
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

This support is essentially useless as typically networks are encrypted,
frames will be filtered by hardware, and rate scaling will be done with
the intended recipient in mind. For real monitoring of the network, the
monitor mode support should be used instead.

Removing it removes a lot of corner cases.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The driver can clearly enable fast-xmit since it does rate
control in the device and thus must do duration calculation
there as well.
Acked-by: NKalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

With latest additions to the driver it seems
viable to enable support for IBSS-RSN.

It seems to work on QCA988X and 999.999.0.636 but
is a bit slow to exchange RSN keys for some
reason. This may be a firmware quirk or ath10k is
missing something. Nevertheless it makes sense to
finally enable IBSS-RSN in ath10k even if somewhat
handicapped.

QCA6174 firmware doesn't seem to be able to Tx
EAPOL frames at all now (they get stuck in hw
queues for some reason) so it never gets to set
the keys in driver. It's fairly safe to assume that
once this is fixed IBSS-RSN will work with QCA6174
firmware without any additional changes. Hence no
special handling for advertising
IEEE80211_HW_SUPPORTS_PER_STA_GTK and
WIPHY_FLAG_IBSS_RSN is done now.
Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Some time ago there was a weird issue with AP
using wrong multicast keys and generating
corrupted traffic on 10.1 firmware.

Apparently a very similar problem applies for
IBSS-RSN on 999.999.0.636.

ath10k doesn't have IBSS-RSN enabled yet. This
patch is a prerequisite to support it.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Apparently firmware requires both pairwise and
groupwise keys to be installed per-peer for static
WEP in IBSS. This wasn't necessary for AP mode
(and installing both doesn't seem to break AP
mode thus there's no special handling).

Also there seems to be some kind of issue with
mapping tx/rx keys in firmware properly which
resulted in wrong keys being used and broken
communication between devices.

It can be argued the vdev param part is more of a
workaround than a real fix. However I couldn't
figure out how to fix this differently. It works
and isn't super ugly.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Firmware actually re-creates peer entry when
reassoc flag is set. This is undesired and could
cause trouble with IBSS crypto-wise. This is also
important for upcomming bitrate mask improvement.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

mac80211 sets static WEP keys as groupwise while
firmware requires them to be installed twice as
both pairwise and groupwise.

Until now these keys were installed once as
pairwise only and, due to that special handling,
needed additional tricks to support 802.1x as
well.

Without this patch in some cases (when AP and
ath10k client use different default tx keys)
multicast communication was broken.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

This improves chances of getting onto a foreign
channel and thus makes P2P a bit more reliable.

Without scan burst it was possible for firmware to
not switch to foreign channel resulting in "failed
to switch to channel for roc scan" warning. This
would also effectively fail some offchan tx
requests and lead to P2P find/connect taking
longer. This could be observed when other vifs
were running/busy, e.g. with P2P GO.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

It is not guaranteed firmware will switch to
foreign channel immediately after starting scan
sequence. To account for that don't use duration
parameter for scan time. Instead request insanely
long scan and use timeout worker to cancel it from
driver.

This should improve P2P reliability a bit.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

The default keyidx callback may be called after
more than 1 key is installed. This led to only 1
WEP key being reinstalled only. This caused Rxed
traffic encrypted with other WEP keys to be
dropped in client mode.
Tested-by: NBartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

The variable should be cleared regardless of
whether there's a peer associated with the key or
not.

This fixes case when user first associates with 2
WEP keys and then disconnects and connects with 1
WEP key. This resulted in WEP key count being 2 in
the driver leading to default keyidx fixup
failure.
Tested-by: NBartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Firmwares that indicate BURST_SERVICE as enabled
could overwrite some wmm parameters (eg. txop).
This could lead IOT and balancing issues.
Hence disable this by default.
Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

WLAN.RM.2.0-00073 firmware requires self-peer to
be created prior to issuing scan command. Without
this wmi-tlv with qca6174 firmware crashes after
submitting a scan request.

Creating the peer as soon as add_interface()
shouldn't be a problem.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

The code was a bit convoluted. Clean it up and
prepare for future changes.

While at it this fixes incorrect verification of
'single nss' case when ss2 rates were missing
while ss1 and ss3 were requested resulting in
nss=3 being set:

  iw wlan1 set bitrates legacy-5 ht-mcs-5 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23 vht-mcs-5 1:0-9 3:0-9
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

This effectively enables multi-channel operation
on qca6174 WLAN.RM.2.0-00073 (and possibly any
newer firmware release for qca6174).

This adds appopriate interface combinations and
initializes firmware channel scheduler.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

qca6174 wmi-tlv firmware defines a new wmi event
for host tx pausing (i.e. stop/wake tx queues).

Map these events to ath10k/mac80211 tx queue
control.

This is important for multi-channel throughput
performance.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Tx queue locking was very simple until now.
Multi-channel support will require a more flexible
and fine grained control.

This introduces a per-hw and per-vif (each with a
bitmask of reasons) tx queue locking.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

The chanctx API will allow ath10k to support
multi-channel operation.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Number of channels is stored in a separate macro
in a header file and channel list is constructed
independently. The macro is used to define survey
array.

This fixes a recent regression introduced after
adding support for 144 channel. The regression
would lead to a warning and incomplete survey data
on channel 165:

  chan info: invalid frequency 5825 (idx 38 out of bounds)

Also make sure to enforce the sizes and avoid this
kind of problem in the future.

Fixes: 4a7898fe ("ath10k: enable channel 144 on 5GHz band")
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Return type of wait_for_completion_timeout is unsigned long not int.
An appropriately named unsigned long is added, respectively 'ret'
renamed, and the assignments fixed up.
Signed-off-by: NNicholas Mc Guire <hofrat@osadl.org>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

While debugging something else I noticed AID was
set to 0. This could lead to powersave issues in
station mode. Maybe this isn't really necessary
but set it properly just to be sure.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Don't use literal values for offsets. While at it
rename a function so it is more clear what it
checks for.

This finally takes care of the last magic
5GHz/OFDM offset.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

It's possible to derive rate index from bitrate
without any additional mapping structures/logic.

This should have little to none impact on
performance since this is only done for management
frames and the previous approach wasn't
particularly optimized.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Instead of using a hacky table and magic values
use supported band information advertised to
mac80211.

This may impact performance a little when dealing
with legacy rx rates depending on system
architecture. It's probably negligible.

This also fixes a highly theoretical corner case
when HT/VHT rates weren't reported correctly if
channel frequency wasn't known.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Use the existing ieee80211_rate array instead of
definining separate one. This gets rid of the ugly
4-index offset when dealing with 5GHz band.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Using raw values is discouraged. Having
defines/enums is preferred.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

It was superfluous and confusing. It's better to
define the structure explicitly.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

There's no need to store rate values in hw_value.
This frees up the hw_value for better future use.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>