There are some buggy APs that keeps changing the count while forcing
us to block TX. This eventually results in queue hang, assert, and
disconnection. Detect such APs and disconnect gracefully in advance.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In case we receive channel switch announcement with immediate
quiet and unknown switching time, we will switch when FW identifies
AP left channel. However, if AP remains on channel, we will
eventually get TX queue hang. Init a work to disconnect if
switch doesn't occur within 1500 milliseconds. Do it also
for a too long channel switch.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Let FW know if quiet mode is on or not. This is needed
in order to disable it in FW when CSA is complete.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Send to FW modify command for every beacon we receive during channel
switch. FW will track the count, and make sure the event is scheduled
in time even if AP changed count.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In case we receive abort operation for CSA, clean up
our state.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Support passing to FW delayed beacon count. This
represents the delay the AP can have when moving to
the new channel.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Update element names and new fields according to D3.3 of
the HE spec.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This helps debugging when things go wrong.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

There's no point in this, we already do everything in a nested
fashion, and if we didn't we'd already crash in iwl_mvm_leds_exit()
etc. Just remove the bit.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The IWL_MVM_INIT_STATUS_REG_HW_INIT_COMPLETE bit shouldn't be set,
and realistically we should complete all setup before we call the
ieee80211_register_hw() function. Fix this.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When HW restart is requested but not started yet, commands would not
be sent to the FW, and some function calls would return an error. In
case of iwl_mvm_mac_sta_state() returning an error value when a
station is removed can lead to an unneeded warning in
__sta_info_destroy_part2().

Handle this by setting the return value to 0, in case HW restart is
in progress.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When HW restart is requested but not started yet, commands would not
be sent to the FW, and some function calls return an error. Such cases
can trigger unneeded warning messages, e.g., in iwl_mvm_mac_sta_state()
and iwl_mvm_bss_info_changed_station().

Handle a couple of these cases by also checking in the WARN_ON()
condition that HW restart is not requested.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add new API and TLV for the ability to send commands in the beginning
and end of reset flow.

The full flow of recovery is:

1. While loading FW, get address (from the TLV) of target buffer
   to read in case of reset
2. If an error/assert happens read the address data from step 1.
3. Reset the HW and load the FW.
4. Send the data read in step 2.
5. Add station keys
6. Send notification to FW that reset flow is done.

The main use of the recovery flow is for support in PN/SN recovery
when offloaded
Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add support for FTM initiator, i.e. peer measurements with FTM
if the firmware supports FTM.

Additionally, add two defines we depend on in
include/linux/ieee80211.h.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add support for FTM responder for hardware/firmware combinations
that advertise support for it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

WOWLAN images in unified firmwares should not be used, so don't require
them to support wowlan. This will allow to reduce the firmware's file
size.
Signed-off-by: NIdo Yariv <idox.yariv@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

If we have a station connecting HE, make sure that the
MAC ctxt is updated with indication of this before
setting the TLC rates via the TLC manager command.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Recently we started to send the WEP keys to the firmware so
that we could use hardware Tx encryption also on newer
devices that require the keys to be installed in the firmware
for encryption (as opposed to older devices that can get
the key in the Tx command for each Tx).

When we implemented that, we forgot to remove the key when
we remove a station leading to a situation where a station
that connects and disconnects a lot of times exhausts the
key database inside the firmware.

A fix was made for that, but we always removed the same
key: mvmvif->ap_wep_key which means that we removed the
same key entry in the firmware. This can make sense since
in WEP, the key is the same for all the stations, but the
internal implementation of iwl_mvm_set_sta_key and
iwl_mvm_remove_sta_key assumes that each station uses a
different key in the firmware's key database.

So now we got to the situation where we have a single
ieee80211_key_conf instance that means, a single
ieee80211_key_conf.hw_key_idx index for several stations
and hence for several keys.
ieee80211_key_conf.hw_key_idx is set to 0 when the first
station associates, and then it is overwritten to 1 when
the second station associates which is a buggy of course.
This led to the following message upon the removal of the
second station:

iwlwifi 0000:00:03.0: offset 1 not used in fw key table.
WARNING: CPU: 2 PID: 27883 at net/mac80211/sta_info.c:1122 __sta_info_destroy_part2+0x16b/0x180 [mac80211]
RIP: 0010:__sta_info_destroy_part2+0x16b/0x180 [mac80211]
 Call Trace:
  __sta_info_destroy+0x2a/0x40 [mac80211]
  sta_info_destroy_addr_bss+0x38/0x60 [mac80211]
  ieee80211_del_station+0x1d/0x30 [mac80211]
  nl80211_del_station+0xe0/0x1f0 [cfg80211]

Fix this by copying the ieee80211_key_conf structure for
each and every station. This is the easiest way to properly
remove the keys with the right index. Another solution
would have been to allow several stations to use the same
key offset in the firmware. That would require to change
the way we track keys in iwlmvm and not really worth it.

Also, maintain correctly fw_key_table when we add a key
for the multicast station.
Remove the key when we remove the multicast station.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Fixes: 337bfc98 ("iwlwifi: mvm: set wep key for all stations in soft ap mode")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Some switch-cases were missing a fall through comment, so the compiler
may warn.  Fix that by adding the comments where needed.  In other
cases there was more text in the comment, which the compiler doesn't
recognize, so either remove the extra text or move it to a separate
comment line as appropriate.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When we do channel switch, we used to schedule time events
ourselves. This was offloaded to FW. Support the new command
and flow.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When MU EDCA params change, resend the STA_HE_CTXT command
updating the MU EDCA params.
Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In order to make more sense out of the captured radiotap data e.g.
when the configured AID changes, add the currently configured AID
to the radiotap data as a vendor extension field.

This is made race-free by updating the included value from inside
the RX path (using a notification wait) for the command response
from the firmware, which thus means it's serialized with frame RX.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We maintain a timer for each Tx queue to detect stalls and
be able to recover / debug.
When we work in AP mode, we can freeze the Tx queue timer if
a station goes to sleep, because we don't want to warn about
stalls that are caused by faulty clients that don't wake up
on time.
This mechanism was applied to the queues of the clients, but
the management queue was omitted. Fix that.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Change iwl_fw_channel_info structure so it can have channel number
greater than 255. This is needed for 6 GHz channel numbers.
Change all relevant structs and member accesses accordingly.
The new API is indicated by a TLV capability bit.
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

TX path lock was introduced in order to prevent out of order
invocations of TX.

This can happen in the following flow:

TX path invoked from net dev
Packet dequeued
	TX path invoked from RX path
	Packet dequeued
	Packet TXed
Packet TXed

However, we don't really need a lock. If TX path is already
invoked from some location, other paths can simply abort their
execution, instead of waiting to the first path to finish, and
then discover queue is (likely) empty or stopped.

Replace the lock with an atomic variable to track TX ownership.
This simplifies the locking dependencies between RX and TX paths,
and should improve performance.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Currently whenever we get firmware notification with mac id,
we iterate over all the interfaces to find the ID. This is a
bit cumbersome. Instead, adding an array of RCU pointers, like
we have for station IDs. This is not expensive space wise
since we have only up to 4 active MACs, and not complicated
code wise, since we have a clear point to init and de-init it.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

If WEP is used, no one removes the STA key upon STA
removal, leading to a situation where after 16
connect/disconnects - the AP could no longer decrypt
incoming data frames since iwl_mvm_set_fw_key_idx()
called from iwl_mvm_set_sta_key() during association
returns STA_KEY_IDX_INVALID, thus not setting the key
for that connecting STA.

Fix this by removing the key in the driver when the
STA is removed.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

These inlines just check the module parameters, so they don't
need a configuration parameter and can move to a better place.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We have a slightly better TCP performance with GSO.
Add it back, it can co-exist with the code that builds
AMSDUs in mac80211.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Support getting mac80211 building AMSDUs for us. Remove GSO
support from mvm - we don't need it anymore.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Move to use the new mac80211 TXQs implementation. This has
quite a few benefits for us. We can get rid of the awkward
mapping of DQA to mac80211 queues. We can stop buffering
traffic while waiting for the queue to be allocated. We can
also use mac80211 AMSDUs instead of building it ourselves.

The usage is pretty simple:
Each ieee80211_txq contains iwl_mvm_txq. There is such a
queue for each TID, and one for management frames. We keep
having static AP queues for probes and non-bufferable MMPDUs,
along with broadcast and multicast queues. Those are being
used from the "old" TX invocation path - iwl_mvm_mac_tx.

When there is a new frame in a TXQ, iwl_mvm_mac_wake_tx is
being called, and either invokes the TX path, or allocates
the queue if it does not exist.

Most of the TX path is left untouched, although we can consider
cleaning it up some more, for example get rid of the duplication
of txq_id in both iwl_mvm_txq and iwl_mvm_dqa_txq_info.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We want to advertise support for TWT in the Extended
Capability IE. Since we don't want to set the bits for all
the interface types, define an interface specific
configuration.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Trivial fix to spelling mistake in debug message.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The FW expects to get the ppe value for each NSS-BW pair in the same
format as in the he phy capabilities IE, which means that a value of 0
implies ppe should be used for BPSK (mcs 0). If there are no PPE
thresholds in the IE, or if for some NSS-RU pair there's no threshold
set for it (this could happen because it's a variable-sized field), it
means no PPE should not be used for that pair, so the value sent to FW
should be 7 which corresponds to "none".

Fixes: 514c3069 ("iwlwifi: add support for IEEE802.11ax")
Signed-off-by: NNaftali Goldstein <naftali.goldstein@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Call the previously introduced apply points entry
point when reaching an apply point.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Enable the VHT extended NSS BW feature in iwlwifi/mvm.
Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In AP mode, if AP supports HE (and the STA), send the
STA_HE_CTXT command.

This is needed mainly for PPE (packet extension) params.
Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When the firmware starts, it doesn't have any regulatory
information, hence it uses the world wide limitations. The
driver can feed the firmware with previous knowledge that
was kept in the driver, but the firmware may still not
update its internal tables.

This happens when we start a BSS interface, and then the
firmware can change the regulatory tables based on our
location and it'll use more lenient, location specific
rules. Then, if the firmware is shut down (when the
interface is brought down), and then an AP interface is
created, the firmware will forget the country specific
rules.

The host will think that we are in a certain country that
may allow channels and will try to teach the firmware about
our location, but the firmware may still not allow to drop
the world wide limitations and apply country specific rules
because it was just re-started.

In this case, the firmware will reply with MCC_RESP_ILLEGAL
to the MCC_UPDATE_CMD. In that case, iwlwifi needs to let
the upper layers (cfg80211 / hostapd) know that the channel
list they know about has been updated.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201105

Cc: stable@vger.kernel.org
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The oldest firmware supported by iwlmvm do support getting
the average beacon RSSI. Enable the sta_statistics() call
from mac80211 even on older firmware versions.

Fixes: 33cef925 ("iwlwifi: mvm: support beacon statistics for BSS client")
Cc: stable@vger.kernel.org # 4.2+
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

TDLS discovery response frame is a unicast direct frame to the peer.
Since we don't have a STA for this peer, this frame goes through
iwl_tx_skb_non_sta(). As the result aux_sta and some completely
arbitrary queue would be selected for this frame, resulting in a queue
hang.  Fix that by sending such frames through AP sta instead.
Signed-off-by: NAndrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>