As detected by Luca during code review when I move this in the
next patch, the code here is putting the data into the wrong
field (flags1 instead of flags2). Fix that.

Fixes: e5721e3f ("iwlwifi: mvm: add radiotap data for HE")
Reported-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Remove a stray empty line, unbreak some lines that aren't
really that long, and move on variable setting into the
initializer to avoid initializing it twice.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

This is equivalent to checking he_phy_data != HE_PHY_DATA_INVAL,
which is already done in a number of places, so remove the extra
'overload' variable entirely.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The triplet of get trigger, is trigger enabled and is trigger stopped
repeats itself.  Group them in a function to avoid code duplication.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Make the adjustments for gen2 TX and RX of TKIP packets.  Strip MIC on
RX.  Don't add IV space and keep the MIC space zeroed on TX.

Devices that support gen2 data path support TKIP only in station mode.
In all other modes, fall back to SW encryption. Do this early in the
set_key() callback so that the key flags would not be incorrectly set.
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We already report the RU offset, so we'd better also
report that we know the value.

Fixes: e5721e3f ("iwlwifi: mvm: add radiotap data for HE")
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Check the actual bit (mask) in Rx notification rate_n_flags.
Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Decode the HE TB PPDU data that we get in sniffer mode
and use it to populate the HE radiotap information.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

If the bandwidth is only 20 MHz, then the second channel doesn't
exist, but the hardware reports the CRC was OK. Suppress the data
of the second channel in the HE radiotap in this case, by marking
it as not known.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

This is the same as for SU PPDUs, so it's easy to do.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The GI duration depends on the frame type in some cases,
take that into account when decoding for radiotap.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

I evidently completely confused "number of LTF symbols" and "LTF size".
Radiotap was reporting the former, while I thought it was the latter,
and we really need both.

Add the LTF symbol size into the newly defined field in radiotap.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Implement the extended HE-MU info type decoding to show the HE-SIG-B
common contents in the HE-MU radiotap field.

The DW4 data is partially overwritten by the hardware in all cases, so
only the higher 16 bits can be used.  To be able to use it for the HE
SIG-B common data anyway, move the bits around in the following way:

  SIG-B common 0: DW 4 -> DW 7
  SIG-B common 1: DW 7 -> DW 8
  SIG-B common 2: DW 8 -> DW 4 (upper half)
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The HE code is bloating the RX handling, and makes it too big.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The HE code is bloating the RX handling, and makes it too big.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Current implementation turns this bit on only for HE MU.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add BSS color to the HE radiotap.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

22560 devices use a new rx_mpdu_desc api.
Update the code to use the new api.
Signed-off-by: NGolan Ben Ami <golan.ben.ami@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add HE information to the radiotap data.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add support for the HE in the iwlwifi driver conforming with
P802.11ax_D2.0.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Initially in this code, the race didn't matter since it didn't
do anything. Latest with the commit I marked this as fixing it
started to matter as something got done here that needed other
data that got freed as soon as the queue notification wait was
returning.

In the scenario we saw, apparently the IWL_MVM_RXQ_NOTIF_DEL_BA
event was sent to all queues, but processing the last event we
returned from iwl_mvm_sync_rx_queues_internal() and then from
iwl_mvm_free_reorder() and continued some processing before
wl_mvm_del_ba() was even invoked on the other CPU. Thus, when
the latter finally ran, it found that mvm->baid_map[baid] was
no longer valid.

Correct the race by moving the counter decrement and wake_up()
to be done only after all the per-event processing completed.
Note that in the commit I marked as being fixed the wake_up()
didn't exist yet (and the code was otherwise problematic) but
this particular problem already existed in a way.

Fixes: b915c101 ("iwlwifi: mvm: add reorder buffer per queue")
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In some cases we may get from FW errored frames with
UNKNOWN security type.

This may happen in unsecured aggregation flow, where
the first packet had a CRC error in the WEP bit, which
was followed by a failure to decrypt and was dropped.

The next frames in the aggregation "inherit" the bad metadata
of the first packet.

Make sure to drop such frames since RADA and other offloads
will not operate correctly which may have unexpected results.

In case of AP it also causes to TX AMSDU frames to the peers,
resulting with assert 0x104B.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Future changes will require moving the HE radiotap data into
the SKB head, but this means we need to have the alignment
reservation done before that. To prepare, move the alignment
reservation earlier here.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

This saves some typing and is overall more readable.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Traffic condition monitor gathers data about the traffic load and
other conditions and can be used to make decisions regarding latency,
throughput etc.  This patch introduces the code and data structures to
collect this data for future use.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Hardware bug was fixed in later generation.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

A previous patch allowed the same PN for packets originating from the
same AMSDU by copying PN only for the last packet in the series.

This however is bogus since we cannot assume the last frame will be
received on the same queue, and if it is received on a different ueue
we will end up not incrementing the PN and possibly let the next
packet to have the same PN and pass through.

Change the logic instead to driver explicitly indicate for the second
sub frame and on to be allowed to have the same PN as the first
subframe. Indicate it to mac80211 as well for the fallback queue.

Fixes: f1ae02b1 ("iwlwifi: mvm: allow same PN for de-aggregated AMSDU")
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Latest firmware calculates both phases of the TKIP
field, so the TTAK ok flag is not needed and deprecated.

Support this API change.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

New devices will have rate scaling algorithm running in the firmware.
With this feature, the driver's responsiblity is to provide an initial
configuration and to handle notifications regarding recent rates and
some other parameters. Debugfs hooks will be still available for
reading the current rate/statistics and setting a fixed rate.
The old API is supported so far, though both APIs cannot be used
simultaneously.

This is the first patch in the series. It adds a new TLV specifying
FW support for the new API and updates lq_sta to support two types
of rate scaling.
Signed-off-by: NGregory Greenman <gregory.greenman@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When RADA is active, the hardware decrypts the packets and strips off
the MIC as it is useless after decryption. Indicate that to mac80211.

Cc: stable@vger.kernel.org # 4.13+
[this is needed for the 9000-series HW to work properly]
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Set the flag that indicates that ICV was stripped on if
this option was enabled in the HW.

Cc: stable@vger.kernel.org # 4.13+
[this is needed for the 9000-series HW to work properly]
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

This bit will be used in CCK to indicate short preamble.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

ieee80211_rx_status::chains was always set to zero.
That caused rate scaling to always start with the
lowest rate possible (rs_get_initial_rate).
Set it correctly according to the MPDU response.
Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In case of a hardware restart the BA session data in HW is lost
so the reorder buffer simply passes the frames to mac80211 as is
as there is no NSSN set. Instead, we will drop these frames
before they reach the reorder buffer. mac80211 drops such frames anyway,
but we shouldn't rely on that. In addition it saves some
processing time
Signed-off-by: NShahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.

The RCU lifetime on baid_data is unclear, so this adds a direct copy of the
rcu_ptr passed to the original callback. It may be possible to improve this
to just use baid_data->mvm->baid_map[baid_data->baid] instead.

Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: Luca Coelho <luciano.coelho@intel.com>
Cc: Intel Linux Wireless <linuxwifi@intel.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: Sara Sharon <sara.sharon@intel.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When there is a reorder timeout, we may get to a situation
where we have the timeout latency for all the next 64 frames.
This happens since NSSN is behind for a while, and the driver
won't release the frames, since it is not allowed by NSSN.
As a result the frame is stored in the reorder buffer although
there is no hole, and released 100 ms later.
Add a direct comparison to the reorder buffer head, and release
immediately if possible.

For example:
Frame 0 is missed. We receive frame 1, and store it in the buffer.
After 100 ms, frame 1 is released and reorder buffer head is 2.
We then receive frame 2, with NSSN 0, and store it instead of
releasing it.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

All callers of iwl_mvm_release_frames() already have the baid_data
pointer, so we don't need to (re)calculate it inside the function.
Just pass it instead.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The reason station id and tid fields are both in baid data and
in the reorder buffer per queue is that we couldn't access the
baid_data in the reorder timer functions.
Now that we do some pointer math and access it anyway, those
fields can be removed.
This save some space and some code.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Now that we may have up to 256 entries per reorder buffer, and possibly up
to 16 queues, we can use a LOT of memory for this (64k for each station).
Allocate it according to what we need, which is of course much less for HT
stations (only 16k at a max of 16 queues).

However, this comes at the expense of complicating the code a bit to
calculate the right entry structure to use for each frame.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In case there is a FW bug where the BAID value in the
metadata is not properly initialized we hit the warning for
every RX packet.
Change it to warn once and add elaborate message.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>