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>

New firmware versions will report statistics using a new version 10
of the API, instead of the current version 8. Add support for this.
This enables getting beacon and radio statistics.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The stats argument is always only passed as &mvm->drv_rx_stats, so
there's no point in passing it when the mvm pointer is passed.
Remove the argument entirely.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Reviewed-by: NEyal Shapira <eyal@wizery.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

If the firmware sends spontaneous DTS notfications with the
temperature (indicated in a TLV), we can ignore the temperature we get
in the RX statistics notifications.  This prevents potentially
handling the same temperature change twice.  It also ignores
notifications with temperature equal to 0 that happens from time to
time.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The firmware API structs are split differently, synchronize
the struct splits with the current firmware definitions.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When we pre-populate the skb->head for the stack, we only pull
in the 802.11 header including crypto (assuming the packet isn't
short enough to be in there completely.) This is fine, but in
ieee80211_data_to_8023() we later unconditionally pull 8 more
bytes for the SNAP header and ethertype field (except for mesh
or 4-addr, where it's even more, but we don't care as much about
them).

Avoid the additional later pull by pulling in those 8 bytes here.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Reviewed-by: NIdoX Yariv <ido@wizery.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When we pre-populate the skb->head for the stack, we only pull
in the 802.11 header (assuming the packet isn't short enough to
be in there completely.) This is fine, but in many cases we'll
pull in the crypto headers pretty much immediately afterwards,
so to avoid that pull in the crypto header early.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Reviewed-by: NIdoX Yariv <ido@wizery.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Instead of building the rx_status on the stack and then
copying it to the skb, allocate the skb a bit earlier
and then build the rx_status in place.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Reviewed-by: NIdoX Yariv <ido@wizery.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Refactor the temperature handling code so that it is easier to reuse
it with other notification flows.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Improve the initial tx rate and antenna selection to be based on
the rssi of the last rx. This avoids starting at the lowest legacy
rate always and requiring more tx traffic to "climb" up the rates.
Since this option might cause trouble in certain setups, allow to
disable it by default.
Signed-off-by: NEyal Shapira <eyalx.shapira@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The idea here is to translate a value of 0 received from
the firmware to the lowest rssi figure. As rx_status->chain_signal
is a signed byte the lowest possible value is -128 and not -256.
-256 was causing 0 to get stored in the signed byte.
Signed-off-by: NEyal Shapira <eyalx.shapira@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Our legal structure changed at some point (see wikipedia), but
we forgot to immediately switch over to the new copyright
notice.

For files that we have modified in the time since the change,
add the proper copyright notice now.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Add ability to set the NIC's temperature and ignore the actual temperature
that the FW supplies.
Signed-off-by: NMatti Gottlieb <matti.gottlieb@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

An AP/GO may perform the channel switch slightly before its stations.
This scenario may result in packet loss, since the transmission may start
before the client is actually on a new channel. In order to prevent
potential packet loss disable tx to all the stations when the channel
switch flow starts. Clear the disable_tx bit when a station is seen on a
target channel, or after IWL_MVM_CS_UNBLOCK_TX_TIMEOUT beacons on a new
channel. In addition call ieee80211_sta_block_awake in order to inform
mac80211 that the frames for this station should be buffered.
Signed-off-by: NAndrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

All the supported firmwares have this flag set.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The firmware tells us if an Rx packet was beamformed or not.
Propagate this data to mac80211's rx_status.vht_flags.
The main user of this data is the radiotap header.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

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

Use the new NAPI infrastructure added to mac80211 to get
GRO. We don't really implement NAPI since we don't have
a real poll function and we never schedule a NAPI poll.
Instead of this, we collect all the packets we got from a
single interrupt and then call napi_gro_flush().

This allows us to benefit from GRO. In half duplex medium
like WiFi, its main advantage is that it reduces the number
of TCP Acks, hence improving the TCP Rx performance.

Since we call the Rx path with a spinlock held, remove
the might_sleep mention from the op_mode's API.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Reviewed-by: NIdo Yariv <ido@wizery.com>
[Squash different patches and rewrite the commit message]
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Collect statistics regarding rates and aggregations in Rx
frames and export the data via debugfs.
Signed-off-by: NEyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This will allow to get sniffer captures with correct
settings for these HT / VHT capabilities.
Also set the corresponding HAVE_MCS / VHT_KNOWN bits in
the registration to mac80211.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

ieee80211_rx_status.flags is full. Define a new vht_flag
variable to be able to set more VHT related flags and make
room in flags.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Acked-by: Kalle Valo <kvalo@qca.qualcomm.com> [ath10k]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In iwl_mvm_calc_rssi() some values are calculated but then
never used, remove the calculations.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Happy new year!
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>