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>

Current iwlwifi_trace_dev_rx prints only the cmd without the
group, which might be misleading. Change it to print the wide
id. While at it add the DATA_PATH group and sub commands to the
trace of the command names, sine it is missing due to patches
submitted in parallel.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The A-MSDU must be smaller than the Transmit FIFO in the
device. Since the size of the TXF can change depending
on the device / firmware compilation mode, take the size
of the FIFO dynamically from the what the firmware tells us.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Allow A-MSDU only when we are not downscaling and the
initial MCS is at least 5.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

in order to be able to tune the size of the desired A-MSDU
based on link condition, add a knob to modify the length
of the A-MSDU.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

If the peer allows, we can have A-MSDU inside A-MDPU.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Now that PCIe knows how to create A-MSDUs, use this
capability and prepare SKBs that are large enough to
build an A-MSDU.
Advertise TSO support towards the network stack and
segment the packet with gso_size set to be the maximal
A-MSDU length (after having taken the headers to be added
into account) to make sure that the skb that is passed
down to the transport are not longer than the maximal
A-MSDU allowed.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The firmware handles the VHT MU-MIMO group data on its own.
However, on HW restart (and future sniffer mode) the driver
shall update the firmware on the VHT MU-MIMO group membership
status.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Incoming hardware will support VHT MU-MIMO. Declare this
capability for relevant hardware.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

A curly brace was misplaced, fix this.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Working with MSIX requires prior configuration.
This includes requesting interrupt vectors from the OS,
registering the vectors and mapping the optional causes to the
relevant interrupt. In addition add new interrupt handler
to handle MSIX interrupt.
Signed-off-by: NHaim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Instead of waking up the device each time we write a
register, wake it up once, and writes the registers
at once.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The driver is now ready to handle this firmware.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Klocwork is unhappy as ht_vht_rates might be accessed with
rate->index being set to values between 0 and 3 which will
lead to accessing uninitialized array elements. Effectively this
doesn't happen as in HT/VHT we're not using these rate indices.
Still fix this.
Signed-off-by: NEyal Shapira <eyalx.shapira@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>

These are a few fixes for the current cycle.
3 out of the 5 patches fix a bugzilla.

* fix a race that users reported when we try to load the firmware
  and the hardware rfkill interrupt triggers at the same time.
* Luca fixes a very visible bug in scheduled scan: our firmware
  doesn't support scheduled scan with no profile configured and
  the supplicant sometimes requests such scheduled scans.
* build system fix
* firmware name update for 8265
* typo fix in return value

The initialization and copying of the RSS secret key
should not use ARRAY_SIZE as we need to initialize a
dword array, and not a byte array.
Fix also the hook maximum write size to allow writing
a longer table - up to full indirection table size.

Fixes: 43413a97("iwlwifi: mvm: support rss queues configuration command")
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The 9000 series uses a diffrent sized descriptor. Update the
relevant tracing field.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Register cooling device in order to have the Thermal
Manager handle the device's power budget according to the sent
notifications.
The interface adds a new thermal cooling device to
/sys/class/thermal/ folder.
Signed-off-by: NChaya Rachel Ivgi <chaya.rachel.ivgi@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Register to thermal_zone interface and implement the
thermal ops.
The thermal handles the device throttling, and sets the
the temperature thresholds the Thermal Manager would be
notified of crossing.
The thermal interface adds a new thermal zone device sensor
under /sys/class/thermal/ folder.
Signed-off-by: NChaya Rachel Ivgi <chaya.rachel.ivgi@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Up to today the driver was notified of the temperature from the FW
and decided whether to enter CT-kill or not.
From now on, the FW will decide when to enter CT-kill and will notify
the driver.
Add support for this notification.
Signed-off-by: NChaya Rachel Ivgi <chaya.rachel.ivgi@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Here's another round of updates for -next:
 * big A-MSDU RX performance improvement (avoid linearize of paged RX)
 * rfkill changes: cleanups, documentation, platform properties
 * basic PBSS support in cfg80211
 * MU-MIMO action frame processing support
 * BlockAck reordering & duplicate detection offload support
 * various cleanups & little fixes

Signed-off-by: NJoão Paulo Rechi Vita <jprvita@endlessm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Factor all assignments to rfkill_global_states[].cur into a single
function rfkill_update_global_state().
Signed-off-by: NJoão Paulo Rechi Vita <jprvita@endlessm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There is still quite a bit of code using this interface, so we can't
just remove it. Hopefully it will be possible in the future, but since
its scheduled removal date is past 2 years already, we are better having
the documentation reflecting the current state of things.
Signed-off-by: NJoão Paulo Rechi Vita <jprvita@endlessm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The "claim" sysfs interface has been removed, so its documentation now
lives in the "removed" folder.
Signed-off-by: NJoão Paulo Rechi Vita <jprvita@endlessm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Signed-off-by: NJoão Paulo Rechi Vita <jprvita@endlessm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Signed-off-by: NJoão Paulo Rechi Vita <jprvita@endlessm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

No more users for it.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Pass the rfkill name and type to the device with properties
instead of driver specific platform data.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
CC: Alexandre Courbot <gnurou@gmail.com>
CC: Thierry Reding <thierry.reding@gmail.com>
CC: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: NThierry Reding <treding@nvidia.com>
Tested-by: NMarc Dietrich <marvin24@gmx.de>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This prepares the driver for removal of platform data.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Helper for finding the type based on name. Useful if the
type needs to be determined based on device property.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
[modify rfkill_types array and BUILD_BUG_ON to not cause errors]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add IEEE80211_RADIOTAP_VHT entry to rtap_namespace_sizes array in order to
define alignment and size of VHT info in tx radiotap
Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Today, the supplicant will add the RRM capabilities
Information Element in the association request only if
Quiet period is supported (NL80211_FEATURE_QUIET).

Quiet is one of many RRM features, and there are other RRM
features that are not related to Quiet (e.g. neighbor
report). Therefore, requiring Quiet to enable RRM is too
restrictive.
Some of the features, like neighbor report, can be
supported by user space without any help from the kernel.
Hence adding the RRM capabilities IE to association request
should be the sole user space's decision.
Removing the RRM dependency on Quiet in the driver solves
this problem, but using an old driver with a user space
tool that would not require Quiet feature would be
problematic: the user space would add NL80211_ATTR_USE_RRM
in the association request even if the kernel doesn't
advertize NL80211_FEATURE_QUIET and the association would
be denied by the kernel.

This solution adds a global RRM capability, that tells user
space that it can request RRM capabilities IE publishment
without any specific feature support in the kernel.
Signed-off-by: NBeni Lev <beni.lev@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Drivers may need to track which vif is using VHT MU-MIMO.
Move the flag indicationg the ownership of MU_MIMO to
ieee80211_vif.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Provide an interface to the lower level driver to set the VHT
MU-MIMO data. This is needed for example when there is an update
of the group data during low power state, where the management
frame will not be passed to the host at all.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since the PNs of all the tx keys are now tracked in the public
part of the key struct (with atomic counter), we no longer
need these functions.

dvm and vt665{5,6} are currently the only users of these functions,
so update them accordingly.
Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If protocol offloading is configured, the fw might generate some
frames (e.g. arp response) on its own during d3/d0i3.

On d3/d0i3 exit the driver queries the updated PN (if relevant),
and updates its keys (for the d0i3 case, this is done by
iwl_mvm_d0i3_exit_work(), which is scheduled on d0i3 exit)

While in d0i3, iwlmvm defers tx frames until d0i3 exit, and
then continues their processing.

This is problematic with TKIP, since the frame's PN has already
been set at this stage (in contrast to CCMP, where the PN is
being set only later on), so both the frame's PN and the upcoming
PN update (from d0i3 exit work) might be wrong.

Fix it by moving the TX PN assignment (for TKIP) to the driver,
similarly to CCMP.
Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Some drivers/devices might want to set the IVs by
themselves (and still let mac80211 generate MMIC).

Specifically, this is needed when the device does
offloading at certain times, and the driver has
to make sure that the IVs of new tx frames (from
the host) are synchronized with IVs that were
potentially used during the offloading.

Similarly to CCMP, move the TX IVs of TKIP keys to the
public part of the key struct, and export a function
to add the IV right into the crypto header.

The public tx_pn field is defined as atomic64, so define
TKIP_PN_TO_IV16/32 helper macros to convert it to iv16/32
when needed.

Since the iv32 used for the p1k cache is taken
directly from the frame, we can safely remove
iv16/32 from being protected by tkip.txlock.
Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Fix wiphy supported_band access in tx radiotap parsing introduced
in commit 5ec3aed9ba4c ("mac80211: Parse legacy and HT rate in
injected frames"). In particular, info->band is always set to 0
(IEEE80211_BAND_2GHZ) since it has not assigned yet.
This cause a kernel crash on 5GHz only devices.
Move ieee80211_parse_tx_radiotap() after info->band assignment
Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>