Different firmware may support different numbers of
vdevs.  Use value that is always out of range for all
firmware.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

In case of A-MSDU RX we should check attention flags
correctly to be sure we report correct FCS status for
A-MSDU subframes. Without a patch we could report A-MSDU
subframes with wrong FCS as a correct to the stack, next
get a lot of DUP ACK TCP packets. Finally TP drop is seen
and this drop depends on FCS errors ratio for A-MSDU frame.

Example test case when TP drop is seen:
- ath10k configured as an AP
- used ath10k station
- forced A-MSDU (7 frames) on STA
- other traffic on channel (often FCS errors)
- monitor iface added on AP
- TCP STA -> AP traffic (iperf)

a) Iperf logs for case without the patch:

echo "1 64" > htt_max_amsdu_ampdu // disable A-MSDU
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 5.0 sec  56.6 MBytes  95.0 Mbits/sec
[  3]  5.0-10.0 sec  60.4 MBytes   101 Mbits/sec
[  3] 10.0-15.0 sec  60.2 MBytes   101 Mbits/sec
[  3] 15.0-20.0 sec  60.2 MBytes   101 Mbits/sec
[  3] 20.0-25.0 sec  63.8 MBytes   107 Mbits/sec
[  3] 25.0-30.0 sec  64.9 MBytes   109 Mbits/sec

echo "7 64" > htt_max_amsdu_ampdu  // set 7 A-MSDU subframes
[  3] 30.0-35.0 sec  40.0 MBytes  67.1 Mbits/sec
[  3] 35.0-40.0 sec  35.9 MBytes  60.2 Mbits/sec
[  3] 40.0-45.0 sec  36.9 MBytes  61.9 Mbits/sec
[  3] 45.0-50.0 sec  37.9 MBytes  63.5 Mbits/sec
[  3] 50.0-55.0 sec  34.5 MBytes  57.9 Mbits/sec
[  3] 55.0-60.0 sec  25.4 MBytes  42.6 Mbits/sec
[  3] 60.0-65.0 sec  48.2 MBytes  81.0 Mbits/sec
[  3] 65.0-70.0 sec  28.8 MBytes  48.2 Mbits/sec
[  3] 70.0-75.0 sec  29.2 MBytes  49.1 Mbits/sec
[  3] 75.0-80.0 sec  22.9 MBytes  38.4 Mbits/sec
[  3] 80.0-85.0 sec  26.4 MBytes  44.2 Mbits/sec
[  3] 85.0-90.0 sec  31.5 MBytes  52.8 Mbits/sec

b) Iperf logs for case with patch:

echo "1 64" > htt_max_amsdu_ampdu // disable A-MSDU
[  3] local 192.168.12.2 port 57512 connected with 192.168.12.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 5.0 sec  60.8 MBytes   102 Mbits/sec
[  3]  5.0-10.0 sec  62.2 MBytes   104 Mbits/sec
[  3] 10.0-15.0 sec  60.9 MBytes   102 Mbits/sec

echo "7 64" > htt_max_amsdu_ampdu  // set 7 A-MSDU subframes
[  3] 15.0-20.0 sec  68.1 MBytes   114 Mbits/sec
[  3] 20.0-25.0 sec  80.5 MBytes   135 Mbits/sec
[  3] 25.0-30.0 sec  83.0 MBytes   139 Mbits/sec
[  3] 30.0-35.0 sec  79.1 MBytes   133 Mbits/sec
[  3] 35.0-40.0 sec  77.1 MBytes   129 Mbits/sec
[  3] 40.0-45.0 sec  77.4 MBytes   130 Mbits/sec
Reported-by: Denton Gentry <denton.gentry@gmail.com>
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

The 10.x firmware does not support IBSS mode at
all. It can't beacon and it crashes when trying to
scan.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Firmware doesn't perform Rx reordering so it is
left to the host driver to do that.

Use mac80211 to perform reordering instead of
re-inventing the wheel.

This fixes TCP throughput issues in some
environments.
Reported-by: Denton Gentry <denton.gentry@gmail.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

This has been tested on 14e4:4328 (BCM4321), 14e4:432b (BCM4322),
14e4:4353 (BCM43224) and 14e4:4359 (BCM43228) which is an almost
complete list of 5 GHz capable device (only BCM43222 is missing).
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

We don't have all needed channel tables due to RE process for this
device.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This process requires sending some sample tone, so make sure we're
allowed to transmit first.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

So far we were assuming only A-PHY supports 5 GHz.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The dividend in do_div() is expected to be an unsigned 64-bit integer,
which leads to the following warning when building for 32-bit MIPS:

  drivers/net/wireless/mac80211_hwsim.c: In function 'mac80211_hwsim_set_tsf':
  drivers/net/wireless/mac80211_hwsim.c:664:98: warning: comparison of distinct pointer types lacks a cast [enabled by default]
    data->bcn_delta = do_div(delta, bcn_int);

Since we care about the signedness of delta when adjusting tsf_offset
and bcm_delta, use the absolute value for the division and compare
the two timestamps to determine the sign.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The DCM condition was not checked well for channel switch in both AP and
station scenarios. Teardown was also not done for AP/GO DCM. Add the
missing checks.
Reported-by: Peer, Ilan <ilan.peer@intel.com>
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

It was possible to enter an endless loop while
processing a single pci copy engine pipe. This
could effectively render ath10k incapable of
responding to any requests.

An example case when this could happen is when
firmware generates a lot of events, e.g. spectral
scan phyerr via WMI.
Reported-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Some radios may share the same ID and revision but differ by a version.
E.g. radio in BCM5357B0 is version 1 and requires specific handling.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Newer devices need different workarounds for cores 0 and 1.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Add some missing ops and prepare for new devices support. This patch is
a great stability improvement for BCM43217. Earlier Tenda W322E used to
disconnect every 2 minutes (16 times over 30 minutes). With this fix I
got it running for 4 hours (with iperf) without any disconnection.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This fixes handling channel 14 and adds code for BCM43217.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mmc_rescan will scan for non-removable cards only once, hence the card
will not be rediscovered.
Signed-off-by: Andreas Fenkart <afenkart@gmail.com>
Acked-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

Conflicts:
	drivers/net/wireless/iwlwifi/mvm/mac80211.c

When the firmware asserts, we restart the device and reset
the relevant data we hold in the driver. BT Coex data was
not reset and because of that, the driver wouldn't
reconfigure the firmware properly after firmware restart.
Same for beacon filtering. Fix that.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

When we associate, we may have heard the beacon before the
association. In that case, BSS_CHANGED_BEACON_INFO will be
set along with BSS_CHANGED_ASSOC in changes in
bss_info_change.

In this case, we didn't update the smart fifo nor beacon
filtering leaving those two feature disabled.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

Add the Control Status Registers to the firmware error dump
infrastructure.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

Use the fw-error-dump infrastructure to dump the periphery
registers. Only certain ranges are readable, so dump only
these.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

The mvm op_mode won't allocate the buffer for the transport
any more. The transport allocates its own buffer and mvm
is in charge of splicing the buffers in the debugfs hook.

This makes the repartition easier to handle.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

modinfo and kerneldoc disagreed on the meaning of this field.
Reported-by: Andrea Oliveri <oliveriandrea@gmail.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

Add OTP to the string: "can't parse empty OTP/NVM section"
NVM usually refers to nvm_file while the problem can be in
the OTP.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

The recent unified scan api change introduced issues
when stopping ongoing scans, since both regular and
sched scan now use same stopped notification.

When issuing a new scan right after a running one,
we get the "old" notification and handle it wrongly
as notification for the current scan.

Fix it by introducing a new function that make sure
we consume the pending notifications before issuing
a new scan.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Reviewed-by: ArikX Nemtsov <arik@wizery.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

Leave it to default instead - regardless of the BT activity.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

According to new requirements, the ACK / CTS kill mask is
not related to reduced TX power anymore. This allows to
remove the code that tracked reduced TX power enablement
across different interfaces.
The ACK / CTS kill mask is now fetch from a table. It
depends on the Activity grading (activity from BT) and on
the Look Up Table (LUT) type.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

The Remain On Channel framework added to the firmare is
a bit like time events. It allows the driver to request
the firmware to be on a certain channel for a certain time.
Unlike the time events, the ROC infrastructure doesn't need
a MAC context in the firmware - it uses a generic context
called "auxiliary framework".

This is useful for any offchannel activity that is not bound
to a specific MAC.
The flow is synchronized much like with time events:
1) The driver receives an action frame from the wpa_supplicant
   via nl80211 that requests to be sent offchannel.
2) The driver sends an Aux ROC command (0x53) to the firmware.
3) The firmware responds with the unique id of the time event.
4) When time event starts, the driver puts the frame in the
   Aux queue.

Special care needs to be taken when the time events ends:
the queue needs to be cleaned-up.
Signed-off-by: Ariej Marjieh <ariej.marjieh@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

Apparently fw/hw generates a corrupted QoS Control
Field in Qos NullFunc frames. The only way to
workaround this is to downgrade frames to
NullFunc. This should be okay since powersave is
done by fw/hw and these frames are only used for
CQM purposes (e.g. from hostapd to check if
station is still connected).

This doesn't fix any user visible bug that I know
of. It just prevents from sending out funky frames
on the air.
Reported-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

It always bugged me how tid is computed and stored
in a temporary var before written to the control
buffer. It was confusing and it made it difficult
to work with tx helpers.

While at it rename the qos workaround function as
it was misleading - it's not a workaround but
preparation for nwifi tx mode.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>