- Feb 28, 2016
-
-
Emmanuel Grumbach authored
If the peer allows, we can have A-MSDU inside A-MDPU. Signed-off-by:Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Emmanuel Grumbach authored
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: -
Sara Sharon authored
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:
Sara Sharon <sara.sharon@intel.com> Signed-off-by:
-
Sara Sharon authored
Incoming hardware will support VHT MU-MIMO. Declare this capability for relevant hardware. Signed-off-by:
-
Emmanuel Grumbach authored
A curly brace was misplaced, fix this. Signed-off-by: -
Haim Dreyfuss authored
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:
Haim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
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: -
Emmanuel Grumbach authored
The driver is now ready to handle this firmware. Signed-off-by: -
Eyal Shapira authored
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:
Eyal Shapira <eyalx.shapira@intel.com> Signed-off-by:
-
Luca Coelho authored
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:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
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
-
Sara Sharon authored
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:
-
Sara Sharon authored
The 9000 series uses a diffrent sized descriptor. Update the relevant tracing field. Signed-off-by:
-
Chaya Rachel Ivgi authored
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:
Chaya Rachel Ivgi <chaya.rachel.ivgi@intel.com> Signed-off-by:
-
Chaya Rachel Ivgi authored
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:
-
Chaya Rachel Ivgi authored
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:
-
Emmanuel Grumbach authored
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
-
- Feb 24, 2016
-
-
João Paulo Rechi Vita authored
Signed-off-by:
João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
João Paulo Rechi Vita authored
Factor all assignments to rfkill_global_states[].cur into a single function rfkill_update_global_state(). Signed-off-by:
-
João Paulo Rechi Vita authored
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:
-
João Paulo Rechi Vita authored
The "claim" sysfs interface has been removed, so its documentation now lives in the "removed" folder. Signed-off-by:
-
João Paulo Rechi Vita authored
Signed-off-by:
-
João Paulo Rechi Vita authored
Signed-off-by:
-
Heikki Krogerus authored
No more users for it. Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
-
Heikki Krogerus authored
Pass the rfkill name and type to the device with properties instead of driver specific platform data. Signed-off-by:
Thierry Reding <treding@nvidia.com> Tested-by:
Marc Dietrich <marvin24@gmx.de> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Heikki Krogerus authored
This prepares the driver for removal of platform data. Signed-off-by:
-
Heikki Krogerus authored
Helper for finding the type based on name. Useful if the type needs to be determined based on device property. Signed-off-by:
-
Lorenzo Bianconi authored
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:
Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> Signed-off-by:
-
Beni Lev authored
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:
Beni Lev <beni.lev@intel.com> Signed-off-by:
-
Sara Sharon authored
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:
-
Sara Sharon authored
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:
-
Eliad Peller authored
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:Eliad Peller <eliadx.peller@intel.com> Signed-off-by:
-
Eliad Peller authored
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:
-
Eliad Peller authored
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:
-
Lorenzo Bianconi authored
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: -
Felix Fietkau authored
This massively reduces data copying and thus improves rx performance Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Felix Fietkau authored
reuse_skb is set to true if the code decides to use the last segment. Fixes a memory leak Signed-off-by:
-
Sara Sharon authored
The source and destintation addresses in the memcpy arguments are flipped. Fix that. Fixes: 23a1f8d4 ("mac80211: process and save VHT MU-MIMO group frame") Signed-off-by:
-
Henning Rogge authored
mpp_path_del() and mesh_path_del() are mostly the same function. Move common code into a new static function. Acked-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
Henning Rogge <henning.rogge@fkie.fraunhofer.de> Signed-off-by:
-
Henning Rogge authored
Remember the last time when a mpp table entry is used for rx or tx and remove them after MESH_PATH_EXPIRE time. Acked-by:
-
