Rates were changed to adapt to HE. Change is backward compatible.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Currently when rate isn't found (invalid rate or CCK rate in high
band) driver is assigning rate -1, which causes mac80211 to dump
it later with the cryptic rate value of 0xFF.
Instead, warn early and dump the frame in mvm.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The "invalid" label was a bit ugly and unnecessary.  Remove it.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

By moving all the code that depends on the new API
we avoid unnecessary indentation in the code.
Signed-off-by: NMordechai Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

In a000 devices we will support up to 32 stations.
The max station define is used also for invalid station marking
which makes finding usages of actual maximum station pretty hard
to sort through - change it to be a different define in order
to make future changes easier.
Use also ARRAY_SIZE intead of define when possible.
Do not move yet to 32 stations until firmware do it though.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When receiving a frame, we currently pull in sizeof(*hdr) plus
some extra (crypto/snap), which is too much, most headers aren't
actually sizeof(*hdr) since that takes into account the 4-address
format but doesn't take into account QoS. As a result, a typical
frame will have 4 bytes of the payload in the SKB header already.

Fix this by calculating the correct header length, and now that
we have that, align the end of the SKB header to a multiple of 4
so that the IP header will be aligned properly when pulled in.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Extend ieee80211_cqm_rssi_notify with a rssi_level parameter so that
this information can be passed to netlink clients in the next patch, if
available.  Most drivers will have this value at hand.  wl1251 receives
events from the firmware that only tell it whether latest measurement
is above or below threshold so we don't pass any value at this time
(parameter is 0).
Signed-off-by: NAndrew Zaborowski <andrew.zaborowski@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

For CDB arch there is another auxiliary mac.
Support statistics APIs that were changed to reflect that.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The temperature variable is set but not used in
iwl_mvm_handle_statistics().  Remove it to avoid the following
compiler warning when W=1 is used:

/home/luca/iwlwifi/stack-dev/drivers/net/wireless/intel/iwlwifi/mvm/rx.c: In function ‘iwl_mvm_handle_rx_statistics’:
/home/luca/iwlwifi/stack-dev/drivers/net/wireless/intel/iwlwifi/mvm/rx.c:759:6: warning: variable ‘temperature’ set but not used [-Wunused-but-set-variable]
  u32 temperature;
      ^
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

For 9000 family we will get extended statistics notification
with averaged data for RSSI, TCM and rogue AP detection.
Support it. Future patches will added the required algorithms.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

We never initialize ampdu_status so it causes a static checker warning
when we pass it to iwl_mvm_pass_packet_to_mac80211().  Fortunately, it's
never used so we can just remove it.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add support CSA countdown offloading. When CSA starts, the driver
specifies the offsets to the eCSA and CSA IEs in the beacon template
command and the fw performs the countdown.
The fw notifies the driver when the channel switch flow
should be performed.
Beacon sent notifications are not used anymore.
Signed-off-by: NAndrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When a data packet is received, we need to make sure that we stay
awake until it can be processed and wait a while before trying to
enter runtime_suspend os system_suspend again.  To do so, add a new
reference type for RX data and take the reference when sending the
packet to mac80211.  We only do this for data packets, all the other
RX packets sent by the firmware (e.g. notifications) are not a reason
to prevent suspend.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When we've already looked up the transmitter station, we can just
pass it to mac80211 using the new ieee80211_rx_napi(). This saves
the overhead of looking it up in mac80211 again.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

This enum is already perfectly aliased to enum nl80211_band, and
the only reason for it is that we get IEEE80211_NUM_BANDS out of
it. There's no really good reason to not declare the number of
bands in nl80211 though, so do that and remove the cfg80211 one.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Sometimes drivers already looked up, or know out-of-band
from their device, which station transmitted a given RX
frame. Allow them to pass the station pointer to mac80211
to save the extra lookup.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

During d0i3 frames might be filtered by the FW and this may
cause reordering buffer a delay - as the frames will not be
received and reorder will time out.

Introduce an API function to receive notification of filtered
frames and pass the information to the mac80211.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When forming IBSS, mac80211 scans in order to find an already
existing cell to join.
In case the scan does not find any existing cell a new IBSS
cell is formed.
When receiving the beacons of another IBSS cell we should
merge if the other IBSS cell's TSF is higher than ours.
However, currently iwlmvm does not set any timestamp flag in
rx_status so there is no valid rx timestamp to compare the
beacon's TSF to.
The reason for that is that TSF as indicated by the firmware
is at INA time, but up till now mac80211 expected the TSF at
the beginning or end of the MPDU.
Set the flag to the newly added RX_FLAG_MACTIME_PLCP_START flag.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The firmware doesn't send match found notifications when no matchsets
are passed.  This makes sense because if there are no matchsets,
nothing can be matched.  But the nl80211 API should report when there
are results available, even if no matchsets were passed.

To handle this, we can use the firmware's ITERATION_COMPLETE
reporting, which will send us notifications every time it completed a
scheduled scan iteration.  Then we can set a flag when we received
beacons and use that to report that results are available.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

ilw@linux.intel.com is not available anymore.
linuxwifi@intel.com should be used instead.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

In most cases, the firmware will already match the station that
we received a given frame from and tell us the station ID in the
RX status, so we can look up the station from that. This lets us
skip the (more expensive) hash table lookup in mac80211.

Also change the fallback case (no station info from the firmware)
to not attempt to look up a multicast source address.

While at it, also combine all the code using the station into a
single if block.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The fw debug functionality is big enough to warrant
a separate file. Move existing related functions to the new file.
Signed-off-by: NGolan Ben-Ami <golan.ben.ami@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Part of reorganising wireless drivers directory and Kconfig.
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Clean up variable initialisation slightly.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Since the driver can never configure the data here, this field
will always be reported as 0 by the firmware. Even if this was
not the case, however, it wouldn't matter since the extra data
would be added beyond the end of the phy_info structure we use
in the driver, so wouldn't harm anything in this code either.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

This message is useless - it's in the good case that always
happens so enabling it doesn't really help. Just remove it.
There are other ways to debug this (e.g. tracing) so there's
no need to add a message in the bad case.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

This flag is set in all supported firmwares.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>

This flag is set in all supported firmwares.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>

When receiving statistics notification there is a field of average energy.
This is defines as signed 8 bit, while FW refers to it as unsigned.
when the energy is higher than 127 this causes in iwl_mvm_stat_iterator
a wrong computation of the signal
     int sig = -stats->general.beacon_filter_average_energy;
resulting in incorrect CQM event (change from low to high).

While at it - update the rest of the fields to the correct type.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>

The mac80211 patch to pass the NAPI struct only changed iwlwifi to
store the NAPI struct, but we can do better: pass it directly from
the lower transport layer to the opmode during RX, and then on to
mac80211 from there.

When we add multiple RX queues, we can then pass the appropriate
NAPI struct properly.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

TCP software implementation on the host requires extensive computing
power.  Offloading even some of the TCP/IP stack to the NIC might save
a significant overhead. In order to enable this feature on our hw,
we need to configure it first. Once done, we mark this capability,
to be advertised later to the OS via ieee80211_register_hw.
The driver Rx indications for TCP Checksum is integrated within the
standard Rx status. The driver responds to those indications as follows:
If the frame was tested by hw and checksum ok report CHECKSUM_UNNECESSARY.
Otherwise, report CHECKSUM_NONE.
Signed-off-by: NAvri Altman <avri.altman@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

In the mvm driver, neither the old command nor the return value
are used, so remove them.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When introducing multiple RX queues, a single NAPI struct will not
be sufficient. Instead of trying to store multiple, simply change
the API to have the NAPI struct passed to the RX function. This of
course means that drivers using rx_irqsafe() cannot use NAPI, but
that seems a reasonable trade-off, particularly since only two of
all drivers are currently using it at all.

While at it, we can now remove the IEEE80211_RX_REORDER_TIMER flag
again since this code path cannot have a napi struct anyway.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Currently, loading the firmware fails when it has higher API or CAPA
bits than the driver supports. That's an issue with integration.

At the same time, actually using api[0] and capa[0] will become
confusing when we also have api[1] and capa[1], and it's almost
certain that we'll mix up the bits and use the bits for api[1] with
api[0] by accident.

Avoid all this by translating the API/CAPA bits to the regular kernel
test_bit() format, and also providing wrapper functions. Also use the
__bitwise__ facility of sparse to check that we're testing the right
one.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

If for some reason statistics notification received from the firmware
reports 0 in average beacon RSSI value, then skip it and avoid signal
based decisions.
Signed-off-by: NAlexander Bondar <alexander.bondar@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The current code has a lot of duplicates of printing into a buffer
(while having to make sure it's NUL-filled and -terminated) and
then passing that to the debug trigger collection.

Since that's error-prone, instead make the debug trigger collection
function take a format string and format arguments (with compiler
validity checking) and handle the buffer internally.

This makes one behavioural change -- instead of sending the whole
buffer to userspace (clearing is needed to not leak stack data) it
just passes the actual string (including NUL-terminator.)
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Lots of issues can be caught when the RSSI drops. Add the
ability to collect the firmware data at that point.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

It can be very useful to monitor the statistics and trigger
a firmware dump when a certain value hits a certain offset.
Since the statistics are huge, add a generic trigger. When
the DWORD at offset X reaches value Y.

Since there is another trigger before this one I can't add
right now because of a dependency on mac80211, add a
reserved entry to keep the enum in place.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Report the average beacon signal and the number of received beacons as
measured by the firmware.

Since the firmware just counts, and doesn't reset the counter at all,
clear it in the firmware whenever we associate. However, accumulate it
over firmware restart.

Since clearing the statistics in the firmware will also clear the ones
for the radio statistics, add those to the accumulator when cleared.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Export the radio statistics from the statistics v10 API (if the
firmware also has the capability to fill these statistics) using
the global survey data facility.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>