Golan Ben-Ami [Tue, 23 Feb 2016 08:34:48 +0000 (10:34 +0200)]
iwlwifi: support ucode with d0 unified image - regular and usniffer
Till today, the ucode consisted of two d0 images - regular,
in which the usniffer wasn't enabled, and usniffer, in which the
usniffer logs were enabled.
Lately, the two images were unified, so there is only one d0 image,
in which the usniffer logs are enabled.
Add new TLV capability for supporting the consolidated images
(set 2, bit 13).
Matti Gottlieb [Thu, 25 Feb 2016 08:18:34 +0000 (10:18 +0200)]
iwlwifi: mvm: Disable beacon storing in D3 when WOWLAN configured
Currently when entering D3 with WOWLAN configured, we enable in the
configuration flags beacon storing, and do not disable beacon
filtering, and do not wake up from a magic packet.
Having both enabled is wrong (should not have both enabled),
and causes problems in the RX queues in the FW, causing
the FW not to recognize the magic packet when it comes.
Disable beacon storing in wowlan configuration.
Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Sara Sharon [Thu, 28 Jan 2016 12:25:33 +0000 (14:25 +0200)]
iwlwifi: mvm: take care of padded packets
To ensure that the SNAP/TCP/IP headers are DW aligned, the firmware
may add 2-byte pad at the end of the mac header - after the IV, before
the SNAP.
In that case the mpdu descriptor pad bit will be turned on.
Driver should take it into consideration, and remove the padding before
passing the packet to mac80211. Do that.
Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Avri Altman [Sun, 24 Jan 2016 20:16:08 +0000 (22:16 +0200)]
iwlwifi: mvm: Send power command on BSS_CHANGED_BEACON_INFO if needed
Beacon abort (ba) is set while sending power command, but only
after at least one beacon_filter command was successfully sent.
If we heard a beacon before starting association, this order
is maintained and ba is properly set.
However, if the first beacon is received after association,
we send the power command upon association, configure the
beacon filtering when the first beacon arrives, and in that case,
beacon abort is not set.
So identify this, and send a power command post the beacon_filter
command if needed.
Beni Lev [Wed, 23 Dec 2015 14:39:57 +0000 (17:39 +0300)]
iwlwifi: mvm: Set global RRM capability
Allow to publish RRM capabilities without the need to support a minimal
capability set. Since some RRM features(e.g. neighbor report) are fw
independent, set this capability unconditionally.
Signed-off-by: Beni Lev <beni.lev@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Sara Sharon [Wed, 3 Feb 2016 13:04:49 +0000 (15:04 +0200)]
iwlwifi: mvm: support VHT MU-MIMO notification
When the device is in d0i3/d3 we will not receive the VHT
MU-MIMO group id management frame. Instead, firmware will
notify us upon exit on the current status and we can in turn
update mac80211. Support this notification.
While at it, also check as a precaution that the vif is indeed
the VHT MU-MIMO owner before updating the firmware.
Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
iwlwifi: mvm: remove unused field in iwl_mvm_tid_data
Commit 69c7fda40921c125eeeef6a827f6270ac6aa1baa removed the
users of iwl_mvm_tid_data.reduced_tpc. Due to a conflict,
I forgot to commit the hunk that removed the field itself.
Do this know.
In multi rx queue HW, without execessive locking, there is no sync
between the ctrl path (default queue) and the rest of the rx queues.
This might cause issues on certain situations. For example, in case
a delBA was processed on a default queue but out of order packets
still wait for processing on the other queue.
The solution is to introduce internal messaging between the CTRL path
and the other rx queues.
The driver will send a message to the firmware, which will echo it to
all the requested queues. The message will be in order inside the queue.
This way we can avoid CTRL path and RSS queues races.
Add support for this messaging mechanism. As the firmware is agnostic to
the data sent, add internal representation of the data as well.
Although currently only delBA flow will use it, the internal representation
will enable generic use of this infrastructure for future uses.
Next patch will utilize this messaging mechanism for the reorder buffer
delBA flow.
Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Sara Sharon [Mon, 7 Dec 2015 10:50:58 +0000 (12:50 +0200)]
iwlwifi: mvm: add duplicate packet detection per rx queue
Next hardware will direct TCP/UDP streams to different cores.
Packets belonging to the same stream will be directed to the same
core.
The result is that duplicates will be always directed to the same
rx queue were the first packet was received.
This enabled parallelizing the duplicate packet detection across
the different cores, without sharing data between the rx queues.
Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Sara Sharon [Mon, 15 Feb 2016 15:26:48 +0000 (17:26 +0200)]
iwlwifi: pcie: configure more RFH settings
Fine tune RFH registers further:
* Set default queue explicitly
* Set RFH to drop frames exceeding RB size
* Set the maximum rx transfer size to DRAM to 128 instead of 64
Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Sara Sharon [Wed, 22 Jul 2015 08:38:40 +0000 (11:38 +0300)]
iwlwifi: mvm: support filtered frames notification
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: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Sara Sharon [Sun, 10 Jan 2016 12:23:25 +0000 (14:23 +0200)]
iwlwifi: mvm: update rx_status with mactime flag
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: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Sara Sharon [Mon, 28 Dec 2015 20:37:08 +0000 (22:37 +0200)]
iwlwifi: support tracing wide commands
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: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
iwlwifi: mvm: don't send an A-MSDU that is larger than the TXF
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.
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.
Sara Sharon [Sun, 15 Nov 2015 09:11:59 +0000 (11:11 +0200)]
iwlwifi: mvm: update firmware of VHT MU-MIMO groups status on restart
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: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Haim Dreyfuss [Thu, 17 Dec 2015 10:17:58 +0000 (12:17 +0200)]
iwlwifi: pcie: Add new configuration to enable MSIX
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.
Eyal Shapira [Mon, 1 Feb 2016 07:07:05 +0000 (09:07 +0200)]
iwlwifi: mvm: rs: fix a theoretical access to uninitialized array elements
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.
Luca Coelho [Tue, 2 Feb 2016 20:58:46 +0000 (22:58 +0200)]
iwlwifi: mvm: handle pass all scan reporting
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.
Merge tag 'iwlwifi-for-kalle-2016-02-15' into HEAD
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 [Sun, 7 Feb 2016 10:50:35 +0000 (12:50 +0200)]
iwlwifi: mvm: fix RSS key sizing
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: 43413a975d06("iwlwifi: mvm: support rss queues configuration command") Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel 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.
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.
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.
Merge tag 'mac80211-next-for-davem-2016-02-26' into next2
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
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 <jprvita@endlessm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Heikki Krogerus [Mon, 25 Jan 2016 09:03:46 +0000 (12:03 +0300)]
net: rfkill: add rfkill_find_type function
Helper for finding the type based on name. Useful if the
type needs to be determined based on device property.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
[modify rfkill_types array and BUILD_BUG_ON to not cause errors] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Beni Lev [Wed, 17 Feb 2016 18:30:00 +0000 (20:30 +0200)]
cfg80211: Add global RRM capability
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: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Sara Sharon [Tue, 16 Feb 2016 10:48:17 +0000 (12:48 +0200)]
mac80211: provide interface to driver to set VHT MU-MIMO data
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: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Eliad Peller [Sun, 14 Feb 2016 11:56:36 +0000 (13:56 +0200)]
iwlwifi: mvm: move TX PN assignment for TKIP to the driver
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.
Eliad Peller [Sun, 14 Feb 2016 11:56:35 +0000 (13:56 +0200)]
mac80211: move TKIP TX IVs to public part of key struct
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.
Lorenzo Bianconi [Fri, 19 Feb 2016 11:18:01 +0000 (12:18 +0100)]
mac80211: fix wiphy supported_band access
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: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Sara Sharon [Wed, 3 Feb 2016 19:52:23 +0000 (21:52 +0200)]
mac80211: fix VHT MU-MIMO frame processing
The source and destintation addresses in the memcpy arguments
are flipped. Fix that.
Fixes: 23a1f8d44c0b("mac80211: process and save VHT MU-MIMO group frame") Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Lior David [Thu, 28 Jan 2016 08:58:25 +0000 (10:58 +0200)]
cfg80211: basic support for PBSS network type
PBSS (Personal Basic Service Set) is a new BSS type for DMG
networks. It is similar to infrastructure BSS, having an AP-like
entity called PCP (PBSS Control Point), but it has few differences.
PBSS support is mandatory for 11ad devices.
Add support for PBSS by introducing a new PBSS flag attribute.
The PBSS flag is used in the START_AP command to request starting
a PCP instead of an AP, and in the CONNECT command to request
connecting to a PCP instead of an AP.
Signed-off-by: Lior David <liord@codeaurora.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Jouni Malinen [Mon, 1 Feb 2016 09:40:55 +0000 (11:40 +0200)]
mac80211: Interoperability workaround for 80+80 and 160 MHz channels
Number of deployed 80 MHz capable VHT stations that do not support 80+80
and 160 MHz bandwidths seem to misbehave when trying to connect to an AP
that advertises 80+80 or 160 MHz channel bandwidth in the VHT Operation
element. To avoid such issues with deployed devices, modify the design
based on recently accepted IEEE 802.11 standard changes (*).
This allows poorly implemented VHT 80 MHz stations to connect with the
AP in 80 MHz mode. 80+80 and 160 MHz capable stations need to support
the new workaround mechanism to allow full bandwidth to be used.
However, there are more or less no impacted station with 80+80/160
capability deployed.
The rebased version of this patch is based on the updated version from
Johannes Berg to take the HT/VHT chandef refactoring into account.
(*) Changes in
https://mentor.ieee.org/802.11/dcn/15/11-15-1530-04-000m-vht160-operation-signaling-through-non-zero-ccfs1.docx
were accepted during the IEEE 802.11 January 2016 meeting.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Sara Sharon [Thu, 28 Jan 2016 14:19:25 +0000 (16:19 +0200)]
mac80211: add API to allow filtering frames in BA sessions
If any frames are dropped that are part of a BA session, the reorder
buffer will "indefinitely" (until the timeout) wait for them to come
in (or a BAR moving the window) and won't release frames after them.
This means it isn't possible to filter frames within a BA session in
firmware.
Introduce an API function that allows such filtering. Calling this
function will move the BA window forward to the new SSN, and allows
marking frames after the SSN as having been filtered, so any future
reordering activity will release frames while skipping the holes.
Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Clean up ieee80211_rx_reorder_ready() callers by passing the RX
TID struct and the index, instead of the frames list. This will
make it more extensible as well.
While at it, move the inline to rx.c as it's only used there.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Michal Kazior [Wed, 27 Jan 2016 14:26:12 +0000 (15:26 +0100)]
mac80211: expose txq queue depth and size to drivers
This will allow drivers to make more educated
decisions whether to defer transmission or not.
Relying on wake_tx_queue() call count implicitly
was not possible because it could be called
without queued frame count actually changing on
software tx aggregation start/stop code paths.
It was also not possible to know how long
byte-wise queue was without dequeueing.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Sven Eckelmann [Tue, 26 Jan 2016 16:11:13 +0000 (17:11 +0100)]
mac80211: Parse legacy and HT rate in injected frames
Drivers/devices without their own rate control algorithm can get the
information what rates they should use from either the radiotap header of
injected frames or from the rate control algorithm. But the parsing of the
legacy rate information from the radiotap header was removed in commit e6a9854b05c1 ("mac80211/drivers: rewrite the rate control API").
The removal of this feature heavily reduced the usefulness of frame
injection when wanting to simulate specific transmission behavior. Having
rate parsing together with MCS rates and retry support allows a fine
grained selection of the tx behavior of injected frames for these kind of
tests.
Signed-off-by: Sven Eckelmann <sven@narfation.org> Cc: Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bob Copeland [Sat, 30 Jan 2016 18:17:03 +0000 (13:17 -0500)]
mac80211: mesh: drop constant field mean_chain_len
The mean_chain_len field in struct mesh_table is copied whenever a
new mesh table is allocated, but only ever has the value 2 and is
never otherwise updated, so just remove it and use the related
define instead.
Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Arnd Bergmann [Tue, 26 Jan 2016 22:05:31 +0000 (23:05 +0100)]
mac80211: avoid excessive stack usage in sta_info
When CONFIG_OPTIMIZE_INLINING is set, the sta_info_insert_finish
function consumes more stack than normally, exceeding the
1024 byte limit on ARM:
net/mac80211/sta_info.c: In function 'sta_info_insert_finish':
net/mac80211/sta_info.c:561:1: error: the frame size of 1080 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
It turns out that there are two functions that put a 'struct station_info'
on the stack: __sta_info_destroy_part2 and sta_info_insert_finish, and
this structure alone requires up to 792 bytes.
Hoping that both are called rarely enough, this replaces the
on-stack structure with a dynamic allocation, which unfortunately
requires some suboptimal error handling for out-of-memory.
The __sta_info_destroy_part2 function is actually affected by the
stack usage twice because it calls cfg80211_del_sta_sinfo(), which
has another instance of struct station_info on its stack.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 98b6218388e3 ("mac80211/cfg80211: add station events") Fixes: 6f7a8d26e266 ("mac80211: send statistics with delete station event") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Sara Sharon [Mon, 25 Jan 2016 13:46:35 +0000 (15:46 +0200)]
mac80211: fix ibss scan parameters
When joining IBSS a full scan should be initiated in order to search
for existing cell, unless the fixed_channel parameter was set.
A default channel to create the IBSS on if no cell was found is
provided as well.
However - a scan is initiated only on the default channel provided
regardless of whether ifibss->fixed_channel is set or not, with the
obvious result of the cell not joining existing IBSS cell that is
on another channel.
Fixes: 76bed0f43b27 ("mac80211: IBSS fix scan request") Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Mon, 25 Jan 2016 13:46:34 +0000 (15:46 +0200)]
mac80211: add RX_FLAG_MACTIME_PLCP_START
The timestamp given by iwlwifi is at the beginning of the
frame over the air, at (or during) the SYNC field. Allow
such timestamps to be given to mac80211, at least (for now)
for frames with non-HT/VHT preambles.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Michal Kazior [Mon, 25 Jan 2016 13:43:24 +0000 (14:43 +0100)]
mac80211: fix unnecessary frame drops in mesh fwding
The ieee80211_queue_stopped() expects hw queue
number but it was given raw WMM AC number instead.
This could cause frame drops and problems with
traffic in some cases - most notably if driver
doesn't map AC numbers to queue numbers 1:1 and
uses ieee80211_stop_queues() and
ieee80211_wake_queue() only without ever calling
ieee80211_wake_queues().
On ath10k it was possible to hit this problem in
the following case:
1. wlan0 uses queue 0
(ath10k maps queues per vif)
2. offchannel uses queue 15
3. queues 1-14 are unused
4. ieee80211_stop_queues()
5. ieee80211_wake_queue(q=0)
6. ieee80211_wake_queue(q=15)
(other queues are not woken up because both
driver and mac80211 know other queues are
unused)
7. ieee80211_rx_h_mesh_fwding()
8. ieee80211_select_queue_80211() returns 2
9. ieee80211_queue_stopped(q=2) returns true
10. frame is dropped (oops!)
Fixes: d3c1597b8d1b ("mac80211: fix forwarded mesh frame queue mapping") Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Michal Kazior [Thu, 21 Jan 2016 13:23:07 +0000 (14:23 +0100)]
mac80211: fix txq queue related crashes
The driver can access the queue simultanously
while mac80211 tears down the interface. Without
spinlock protection this could lead to corrupting
sk_buff_head and subsequently to an invalid
pointer dereference.
Fixes: ba8c3d6f16a1 ("mac80211: add an intermediate software queue implementation") Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This moves sysfs ABI info from Documentation/rfkill.txt to the
ABI subfolder and reformats it.
This also schedules the deprecated sysfs parts to be removed in
2012 (claim file) and 2014 (state file).
Signed-off-by: Florian Mickler <florian@mickler.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
__rfkill_set_hw_state() is only one used in rfkill_set_hw_state(), and
none of them are long or complicated, so merging the two makes the code
easier to read.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Wed, 20 Jan 2016 09:39:23 +0000 (10:39 +0100)]
rfkill: disentangle polling pause and suspend
When suspended while polling is paused, polling will erroneously
resume at resume time. Fix this by tracking pause and suspend in
separate state variable and adding the necessary checks.
Clarify the documentation on this as well.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Wed, 13 Jan 2016 13:21:01 +0000 (14:21 +0100)]
mac80211_hwsim: remove shadowing variable
The function here already has a variable hdr that even
contains the right thing, so the inner scope's hdr variable
that's shadowing the outer one can just be removed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Fri, 18 Dec 2015 14:08:34 +0000 (15:08 +0100)]
mac80211: refactor HT/VHT to chandef code
The station MLME and IBSS/mesh ones use entirely different
code for interpreting HT and VHT operation elements. Change
the code that interprets them a bit - it now modifies an
existing chandef - and use it also in the MLME code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211: limit the A-MSDU Tx based on peer's capabilities
In VHT, the specification allows to limit the number of
MSDUs in an A-MSDU in the Extended Capabilities IE. There
is also a limitation on the byte size in the VHT IE.
In HT, the only limitation is on the byte size.
Parse the capabilities from the peer and make them
available to the driver.
In HT, there is another limitation when a BA agreement
is active: the byte size can't be greater than 4095.
This is not enforced here.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Ilan Peer [Sun, 13 Dec 2015 11:41:43 +0000 (13:41 +0200)]
mac80211: Recalc min chandef when station is associated
The minimum chandef bandwidth calculation was done only in case
a new station was inserted (or when an existing station was removed).
However, it is possible that stations are inserted before they are
associated, e.g., when FULL_AP_CLIENT_STATE is supported and user
space adds stations unassociated.
Fix this by calling ieee80211_recalc_min_chandef() whenever
a station transitions in/out the associated state, and only
consider station marked as associated.
Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211: allow drivers to report (non-)monitor frames
Some drivers offload some frames internally (e.g.
AddBa). Reporting such frames to mac80211 would
only confuse MLME. However it would be useful to
be able to pass such frames to monitor interfaces
for sniffing purposes, e.g. when running AP +
monitor.
To do that allow drivers to tell mac80211 whether
a given frame should be:
- processed but not delivered to any monitor vif
- not processed but delievered to monitor vifs
only
Signed-off-by: Grzegorz Bajorski <grzegorz.bajorski@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When we load the firmware, we hold trans_pcie->mutex to
avoid nested flows. We also rely on the ISR to wake up the
thread when the DMA has finished copying a chunk. During
this flow, we enable the RF-Kill interrupt.
The problem is that the RF-Kill interrupt handler can take
the mutex and bring the device down. This means that if
we load the firmware while the RF-Kill switch is enabled
(which will happen when we load the INIT firmware to read
the device's capabilities and register to mac80211), we
may get an RF-Kill interrupt immediately and the ISR will
be waiting for the mutex held by the thread that is
currently loading the firmware. At this stage, the ISR
won't be able to service the DMA's interrupt needed to
wake up the thread that load the firmware. We are in a
deadlock situation which ends when the thread that loads
the firmware fails on timeout and releases the mutex.
To fix this, take the mutex later in the flow, disable
the interrupts and synchronize_irq() to give a chance to
the RF-Kill interrupt to run and complete.
After that, mask all the interrupts besides the DMA
interrupt and proceed with firmware load. Make sure to
check that there was no RF-Kill interrupt when the
interrupts were disabled.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=111361
Luca Coelho [Tue, 2 Feb 2016 13:11:15 +0000 (15:11 +0200)]
iwlwifi: mvm: don't allow sched scans without matches to be started
The firmware can perform a scheduled scan with not matchsets passed,
but it can't send notification that results were found. Since the
userspace then cannot know when we got new results and the firmware
wouldn't trigger a wake in case we are sleeping, it's better not to
allow scans without matchsets.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=110831
iwlwifi: mvm: allow to disable beacon filtering for AP/GO interface
When in AP mode we need to filter in beacons from other APs to update HT
operation mode. As a power optimization the beacons are filtered out when
there are no associated stations. As a result, when there are no
associated stations, we will not update the HT operation mode until a
station connects.
Add a debugfs parameter that allows to disable this optimization.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Sara Sharon [Tue, 26 Jan 2016 10:35:13 +0000 (12:35 +0200)]
iwlwifi: pcie: update iwl_mpdu_desc fields
Final API of iwl_mpdu_desc has a change in the order of
the fields and does not include energy from the third
antenna (which is perfectly fine, since we don't have one).
Update the structure accordingly.
Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
projects / linux-beck.git / log