| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The firmware/hardware only supports checking AES-CMAC on RX, not
using it on TX. For station mode this is fine, since it's the only
thing it will ever do. For AP mode, it never receives such frames,
but must be able to transmit them. This is currently broken since
we try to enable them for hardware crypto (for RX only) and then
treat them as TX_CMD_SEC_EXT, leading to FIFO underruns during TX
so the frames never go out to the air.
To fix this, simply use software on TX in AP (and IBSS) mode.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
mac80211 advertises this feature for all its drivers.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Before authentication, we start a time event during
which we wait for a beacon in order to sync our timers.
If we didn't hear the beacon during this time - we abandon
the connection. However, in congested environment, it was
observed we might not hear beacons in that time slot.
Extend the time event to give the connection a better chance.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Leaving ucode_loaded to true after stop_device() has been called
is a recipe for problems. Flows that are not sync'ed with the
driver life cycle (like debugfs hooks and thermal hooks) must
check that the firmware is loaded before they interact with it.
Therefore we need to keep this variable updated with the real
status of the firmware.
Signed-off-by: Chaya Rachel Ivgi <chaya.rachel.ivgi@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
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.
Signed-off-by: Avri Altman <avri.altman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Older versions of the firmware don't support U-APSD for
P2P Client. Forbid U-APSD for P2P Client when an old
firmware is being used.
Signed-off-by: Avri Altman <avri.altman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
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>
|
|
* Remove uneeded includes:
iwl-csr.h and devcoredump aren't used in mac80211.c.
* Remove uneeded empty line
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
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>
|
|
If the peer allows, we can have A-MSDU inside A-MDPU.
Signed-off-by: Emmanuel 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: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Emmanuel 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
|
|
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 <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The 9000 hardware introduces the frame releaser, which
keeps track of the aggregation window and notifies host
of the window status. This requires in turn updating
the hardware with the RX BA session window size.
Firmware API was changed to enable that, update the driver
accordingly.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Currently mac80211 does not inform the driver of the session
block ack timeout when starting a rx aggregation session.
Drivers that manage the reorder buffer need to know this
parameter.
Seeing that there are now too many arguments for the
drv_ampdu_action() function, wrap them inside a structure.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
As we're working on multi-queue RX, we want to parallelise checking
the PN in order to avoid having to serialise the RX processing.
It may seem that doing parallel PN checking is insecure, but it turns
out to be OK because queue assignment is done based on the data in the
frame (IP/TCP) and thus cannot be manipulated by an attacker, since
the data is encrypted and must first have been decrypted successfully.
There are some corner cases, in particular when the peer starts using
fragmentation which redirects the packet to the default queue. However
this redirection is remembered (for the STA, per TID) and thus cannot
be exploited by an attacker either.
Leave checking on the default queue (queue 0) to mac80211, since we
get fragmented packets there and those are subject to stricter checks
during reassembly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
As the device (and parts of the driver) cannot deal with having the
same MAC address for two stations (on two virtual interfaces), add
some explicit code to prevent this case.
Note that in practice this cannot happen since the device doesn't
support operating with two AP/GO interfaces at the same time either,
and other scenarios for this are, while not impossible, not going to
happen in practice.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Since A-MPDU deaggregation is done in hardware, and A-MSDU deaggregation
is done in software, there's no reason not to support A-MSDU in A-MPDU;
set the flag to support it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
If we don't reset the scan type when the firmware is
started, we will think the firmware is still configured
after the interface has been brought down. When we will
bring it up again, we will not configure the scan type
in firmware and it will crash with the following assert:
0x0000100A | ADVANCED_SYSASSERT
Fixes: 355346ba3050 ("iwlwifi: mvm: configure scheduled scan according to traffic conditions")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
associated
Currently, the number of associated stations gets updated when adding
a new station or removing it. This is incorrect as it's possible that
a station was inserted before it was associated
Fix this by increasing/decreasing ap_assoc_sta_count whenever
a station transitions in/out the associated state.
Signed-off-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Currently when creating a new vif in monitor mode the driver doesn't
allocate a specific station. This causes that in the situation that
tx traffic is injected, the tx queues are not scheduled,
with the result of a TFD queue hang.
Fix that by allocating a station and ensuring its tx queues
are scheduled.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=104591
Signed-off-by: Chaya Rachel Ivgi <chaya.rachel.ivgi@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Instead of keeping the fw_key_table bits set when the keys are removed
(i.e. in D3 entry or HW_RESTART flows), clear them and set them again
only when the keys have been successfully re-added. This makes the
bitmask more closely tied to the actual firmware programming.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Differentiate between the cases where the skb is a large
send and the other cases.
Advertise TSO even if, at this stage, skb_gso_segment will
be called and it will do all the work.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Allow to configure the driver to pretend to have TX CSUM
offload support. This will be useful to test the TSO flows
that will come in further patches.
This configuration is disabled by default.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
ilw@linux.intel.com is not available anymore.
linuxwifi@intel.com should be used instead.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
The d0i3_mode variable is used to distinguish between transports that
handle d0i3 entry during suspend by themselves (i.e. the slave
transports) and those which rely on the op_mode layer to do it. The
reason why the former do it by themselves is that they need to
transition from d0i3 in runtime_suspend into d0i3 in system-wide
suspend and this transition needs to happen before the op_mode's
suspend flow is called.
The wowlan_d0i3 element is also a bit confusing, because it just
reflects the wowlan->any value for the trans to understand. This is a
bit unclear in the code and not generic enough for future use.
To make it clearer and to generalize the platform power mode settings,
introduce two variables to indicate the platform power management
modes used by the transport.
Additionally, in order not to take too big a step in one patch, treat
this new variables semantically in the same way as the old d0i3_mode
element, introducing a iwl_mvm_enter_d0i3_on_suspend() function to
help with that.
This commit also adds the foundation for a new concept where the
firmware configuration state (i.e. D0, D3 or D0i3) is abstracted from
the platform PM mode we are in (i.e. runtime suspend or system-wide
suspend).
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Remove the vif parameter of iwl_mvm_configure_bcast_filter()
as it's not being used.
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
iwl_mvm_restart_cleanup() calls ieee80211_remain_on_channel_expired()
on cleanup, but it doesn't clean the actual roc time
events, resulting in failure of further ROC attempts.
Refactor iwl_mvm_stop_roc() a bit, and add a new function
to only cleanup the roc time events (without sending further
commands).
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
If the transport supports it, advertise NETIF_F_SG to mac80211 to
be able to use frag SKBs. This will already improve performance by
allowing software GSO to be used.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Change scan configuration (dwell time, suspend time etc.) according
to traffic conditions. This is useful for scans that are managed by
the FW (e.g. scheduled scan).
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
There is no reason to keep a reference when the interface is down,
since we are not really doing anything. The reference is only needed
when the mac80211 start op (or a hw restart) is running, to prevent
going into runtime or system supend in the meantime. This will allow
us to support runtime PM when the interface is down (in another
patch).
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
When associated to an AP and a ROC event with a long duration is scheduled
the FW may have a hard time scheduling a consecutive time event, since it
has to remain on the connection channel to hear the AP's DTIM.
In addition, when associated and a ROC is requested with a duration
greater than the DTIM interval, the FW will not be able to schedule
the ROC event, since it needs to wake up for the DTIM.
Increasing the "max delay" duration to the DTIM period will allow the FW to
wait until after the DTIM and then schedule the ROC time event.
Limiting the ROC to be less than the DTIM interval will assure that the
time event will be scheduled for at least part of the time (instead of
automatically failing)
Extend the ROC max delay duration to min(dtim_interval * 3, 600TU),
and limit the duration to be less than the DTIM interval.
Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: Emmanuel 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: Golan Ben-Ami <golan.ben.ami@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Currently the prph registers dump is in the transport layer,
and each bus needs an additional dump implementation.
Move the prph dump outside transport, and allow a common
implementation for all of the buses.
This is possible because prph base addresses are similar for
all buses.
Signed-off-by: Golan Ben-Ami <golan.ben.ami@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
This will allow to catch different TDLS events and get the
firmware data when they occur.
Add empty TX_LATENCY trigger on the way to avoid mismatch
with trees in which this trigger is implemented.
Signed-off-by: Golan Ben-Ami <golan.ben.ami@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
|
|
Part of reorganising wireless drivers directory and Kconfig.
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|