Most likely the last set of patches for 5.1. WPA3 support to ath10k
and qtnfmac. FTM support to iwlwifi and ath10k. And of course other
new features and bugfixes.
wireless-drivers was merged due to dependency in mt76.
Major changes:
iwlwifi
* HE radiotap
* FTM (Fine Timing Measurement) initiator and responder implementation
* bump supported firmware API to 46
* VHT extended NSS support
* new PCI IDs for 9260 and 22000 series
ath10k
* change QMI interface to support the new (and backwards incompatible)
interface from HL3.1 and used in recent HL2.0 branch firmware
releases
* support WPA3 with WCN3990
* support for mac80211 airtime fairness based on transmit rate
estimation, the firmware needs to support WMI_SERVICE_PEER_STATS to
enable this
* report transmit airtime to mac80211 with firmwares having
WMI_SERVICE_REPORT_AIRTIME feature, this to have more accurate
airtime fairness based on real transmit time (instead of just
estimated from transmit rate)
* support Fine Timing Measurement (FTM) responder role
* add dynamic VLAN support with firmware having WMI_SERVICE_PER_PACKET_SW_ENCRYPT
* switch to use SPDX license identifiers
ath
* add new country codes for US
brcmfmac
* support monitor frames with the hardware/ucode header
qtnfmac
* enable WPA3 SAE and OWE support
mt76
* beacon support for USB devices (mesh+ad-hoc only)
rtlwifi
* convert to use SPDX license identifiers
libertas_tf
* get the MAC address before registering the device
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJccAnlAAoJEG4XJFUm622bxxMH/2cz2GEuDQXOwfYLnCUwFES8
vqTdMWnlfqGQvsTyvtSp91KqsL3hE2FB1Cu3n6/vzND3C7afT0V2/QlU7Pmgr8sR
1gnJnu0NJT5SZfzcTsqwt8rFw9lQZ3HcvEcfNo6T5KUyyY7FGCNGR5H27nvoKOP3
ea1h7U80loPV40sGTI8jj963wa9LNHUrjHTK4wY+KMWECgZuD/fHeE9YPB9MTdff
lJ5bWCoQmuJddvTtC+X0tOAsCkxgdbbw6ieKqzep8H4gtUjerZD+V8uUdbtpr7IL
sWPoaqrrADMv9cZtDVj+pEtNIJ3mpfuHYFKSON9jy/uxygeFTfVzLu43RFreDp8=
=D15/
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2019-02-22' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 5.1
Most likely the last set of patches for 5.1. WPA3 support to ath10k
and qtnfmac. FTM support to iwlwifi and ath10k. And of course other
new features and bugfixes.
wireless-drivers was merged due to dependency in mt76.
Major changes:
iwlwifi
* HE radiotap
* FTM (Fine Timing Measurement) initiator and responder implementation
* bump supported firmware API to 46
* VHT extended NSS support
* new PCI IDs for 9260 and 22000 series
ath10k
* change QMI interface to support the new (and backwards incompatible)
interface from HL3.1 and used in recent HL2.0 branch firmware
releases
* support WPA3 with WCN3990
* support for mac80211 airtime fairness based on transmit rate
estimation, the firmware needs to support WMI_SERVICE_PEER_STATS to
enable this
* report transmit airtime to mac80211 with firmwares having
WMI_SERVICE_REPORT_AIRTIME feature, this to have more accurate
airtime fairness based on real transmit time (instead of just
estimated from transmit rate)
* support Fine Timing Measurement (FTM) responder role
* add dynamic VLAN support with firmware having WMI_SERVICE_PER_PACKET_SW_ENCRYPT
* switch to use SPDX license identifiers
ath
* add new country codes for US
brcmfmac
* support monitor frames with the hardware/ucode header
qtnfmac
* enable WPA3 SAE and OWE support
mt76
* beacon support for USB devices (mesh+ad-hoc only)
rtlwifi
* convert to use SPDX license identifiers
libertas_tf
* get the MAC address before registering the device
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Merge net-next to resolve a conflict and to get the mac80211
rhashtable fixes so further patches can be applied on top.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Update element names and new fields according to D3.3 of
the HE spec.
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's no point in this, we already do everything in a nested
fashion, and if we didn't we'd already crash in iwl_mvm_leds_exit()
etc. Just remove the bit.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
The IWL_MVM_INIT_STATUS_REG_HW_INIT_COMPLETE bit shouldn't be set,
and realistically we should complete all setup before we call the
ieee80211_register_hw() function. Fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When HW restart is requested but not started yet, commands would not
be sent to the FW, and some function calls would return an error. In
case of iwl_mvm_mac_sta_state() returning an error value when a
station is removed can lead to an unneeded warning in
__sta_info_destroy_part2().
Handle this by setting the return value to 0, in case HW restart is
in progress.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When HW restart is requested but not started yet, commands would not
be sent to the FW, and some function calls return an error. Such cases
can trigger unneeded warning messages, e.g., in iwl_mvm_mac_sta_state()
and iwl_mvm_bss_info_changed_station().
Handle a couple of these cases by also checking in the WARN_ON()
condition that HW restart is not requested.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Add new API and TLV for the ability to send commands in the beginning
and end of reset flow.
The full flow of recovery is:
1. While loading FW, get address (from the TLV) of target buffer
to read in case of reset
2. If an error/assert happens read the address data from step 1.
3. Reset the HW and load the FW.
4. Send the data read in step 2.
5. Add station keys
6. Send notification to FW that reset flow is done.
The main use of the recovery flow is for support in PN/SN recovery
when offloaded
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Add support for FTM initiator, i.e. peer measurements with FTM
if the firmware supports FTM.
Additionally, add two defines we depend on in
include/linux/ieee80211.h.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Add support for FTM responder for hardware/firmware combinations
that advertise support for it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
WOWLAN images in unified firmwares should not be used, so don't require
them to support wowlan. This will allow to reduce the firmware's file
size.
Signed-off-by: Ido Yariv <idox.yariv@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
If we have a station connecting HE, make sure that the
MAC ctxt is updated with indication of this before
setting the TLC rates via the TLC manager command.
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Recently we started to send the WEP keys to the firmware so
that we could use hardware Tx encryption also on newer
devices that require the keys to be installed in the firmware
for encryption (as opposed to older devices that can get
the key in the Tx command for each Tx).
When we implemented that, we forgot to remove the key when
we remove a station leading to a situation where a station
that connects and disconnects a lot of times exhausts the
key database inside the firmware.
A fix was made for that, but we always removed the same
key: mvmvif->ap_wep_key which means that we removed the
same key entry in the firmware. This can make sense since
in WEP, the key is the same for all the stations, but the
internal implementation of iwl_mvm_set_sta_key and
iwl_mvm_remove_sta_key assumes that each station uses a
different key in the firmware's key database.
So now we got to the situation where we have a single
ieee80211_key_conf instance that means, a single
ieee80211_key_conf.hw_key_idx index for several stations
and hence for several keys.
ieee80211_key_conf.hw_key_idx is set to 0 when the first
station associates, and then it is overwritten to 1 when
the second station associates which is a buggy of course.
This led to the following message upon the removal of the
second station:
iwlwifi 0000:00:03.0: offset 1 not used in fw key table.
WARNING: CPU: 2 PID: 27883 at net/mac80211/sta_info.c:1122 __sta_info_destroy_part2+0x16b/0x180 [mac80211]
RIP: 0010:__sta_info_destroy_part2+0x16b/0x180 [mac80211]
Call Trace:
__sta_info_destroy+0x2a/0x40 [mac80211]
sta_info_destroy_addr_bss+0x38/0x60 [mac80211]
ieee80211_del_station+0x1d/0x30 [mac80211]
nl80211_del_station+0xe0/0x1f0 [cfg80211]
Fix this by copying the ieee80211_key_conf structure for
each and every station. This is the easiest way to properly
remove the keys with the right index. Another solution
would have been to allow several stations to use the same
key offset in the firmware. That would require to change
the way we track keys in iwlmvm and not really worth it.
Also, maintain correctly fw_key_table when we add a key
for the multicast station.
Remove the key when we remove the multicast station.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Fixes: 337bfc9881 ("iwlwifi: mvm: set wep key for all stations in soft ap mode")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Some switch-cases were missing a fall through comment, so the compiler
may warn. Fix that by adding the comments where needed. In other
cases there was more text in the comment, which the compiler doesn't
recognize, so either remove the extra text or move it to a separate
comment line as appropriate.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When we do channel switch, we used to schedule time events
ourselves. This was offloaded to FW. Support the new command
and flow.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When MU EDCA params change, resend the STA_HE_CTXT command
updating the MU EDCA params.
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
In order to make more sense out of the captured radiotap data e.g.
when the configured AID changes, add the currently configured AID
to the radiotap data as a vendor extension field.
This is made race-free by updating the included value from inside
the RX path (using a notification wait) for the command response
from the firmware, which thus means it's serialized with frame RX.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
We maintain a timer for each Tx queue to detect stalls and
be able to recover / debug.
When we work in AP mode, we can freeze the Tx queue timer if
a station goes to sleep, because we don't want to warn about
stalls that are caused by faulty clients that don't wake up
on time.
This mechanism was applied to the queues of the clients, but
the management queue was omitted. Fix that.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Change iwl_fw_channel_info structure so it can have channel number
greater than 255. This is needed for 6 GHz channel numbers.
Change all relevant structs and member accesses accordingly.
The new API is indicated by a TLV capability bit.
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
TX path lock was introduced in order to prevent out of order
invocations of TX.
This can happen in the following flow:
TX path invoked from net dev
Packet dequeued
TX path invoked from RX path
Packet dequeued
Packet TXed
Packet TXed
However, we don't really need a lock. If TX path is already
invoked from some location, other paths can simply abort their
execution, instead of waiting to the first path to finish, and
then discover queue is (likely) empty or stopped.
Replace the lock with an atomic variable to track TX ownership.
This simplifies the locking dependencies between RX and TX paths,
and should improve performance.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Currently whenever we get firmware notification with mac id,
we iterate over all the interfaces to find the ID. This is a
bit cumbersome. Instead, adding an array of RCU pointers, like
we have for station IDs. This is not expensive space wise
since we have only up to 4 active MACs, and not complicated
code wise, since we have a clear point to init and de-init it.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
If WEP is used, no one removes the STA key upon STA
removal, leading to a situation where after 16
connect/disconnects - the AP could no longer decrypt
incoming data frames since iwl_mvm_set_fw_key_idx()
called from iwl_mvm_set_sta_key() during association
returns STA_KEY_IDX_INVALID, thus not setting the key
for that connecting STA.
Fix this by removing the key in the driver when the
STA is removed.
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
These inlines just check the module parameters, so they don't
need a configuration parameter and can move to a better place.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
We have a slightly better TCP performance with GSO.
Add it back, it can co-exist with the code that builds
AMSDUs in mac80211.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Support getting mac80211 building AMSDUs for us. Remove GSO
support from mvm - we don't need it anymore.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Move to use the new mac80211 TXQs implementation. This has
quite a few benefits for us. We can get rid of the awkward
mapping of DQA to mac80211 queues. We can stop buffering
traffic while waiting for the queue to be allocated. We can
also use mac80211 AMSDUs instead of building it ourselves.
The usage is pretty simple:
Each ieee80211_txq contains iwl_mvm_txq. There is such a
queue for each TID, and one for management frames. We keep
having static AP queues for probes and non-bufferable MMPDUs,
along with broadcast and multicast queues. Those are being
used from the "old" TX invocation path - iwl_mvm_mac_tx.
When there is a new frame in a TXQ, iwl_mvm_mac_wake_tx is
being called, and either invokes the TX path, or allocates
the queue if it does not exist.
Most of the TX path is left untouched, although we can consider
cleaning it up some more, for example get rid of the duplication
of txq_id in both iwl_mvm_txq and iwl_mvm_dqa_txq_info.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
We want to advertise support for TWT in the Extended
Capability IE. Since we don't want to set the bits for all
the interface types, define an interface specific
configuration.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Trivial fix to spelling mistake in debug message.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The FW expects to get the ppe value for each NSS-BW pair in the same
format as in the he phy capabilities IE, which means that a value of 0
implies ppe should be used for BPSK (mcs 0). If there are no PPE
thresholds in the IE, or if for some NSS-RU pair there's no threshold
set for it (this could happen because it's a variable-sized field), it
means no PPE should not be used for that pair, so the value sent to FW
should be 7 which corresponds to "none".
Fixes: 514c30696f ("iwlwifi: add support for IEEE802.11ax")
Signed-off-by: Naftali Goldstein <naftali.goldstein@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Call the previously introduced apply points entry
point when reaching an apply point.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
First set of patches for 4.21. Most notable here is support for
Quantenna's QSR1000/QSR2000 chipsets and more flexible ways to provide
nvram files for brcmfmac.
Major changes:
brcmfmac
* add support for first trying to get a board specific nvram file
* add support for getting nvram contents from EFI variables
qtnfmac
* use single PCIe driver for all platforms and rename
Kconfig option CONFIG_QTNFMAC_PEARL_PCIE to CONFIG_QTNFMAC_PCIE
* add support for QSR1000/QSR2000 (Topaz) family of chipsets
ath10k
* add support for WCN3990 firmware crash recovery
* add firmware memory dump support for QCA4019
wil6210
* add firmware error recovery while in AP mode
ath9k
* remove experimental notice from dynack feature
iwlwifi
* PCI IDs for some new 9000-series cards
* improve antenna usage on connection problems
* new firmware debugging infrastructure
* some more work on 802.11ax
* improve support for multiple RF modules with 22000 devices
cordic
* move cordic macros and defines to a public header file
* convert brcmsmac and b43 to fully use cordic library
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJcATmGAAoJEG4XJFUm622bk9kH/1RWa2z7Gmjr2wBSLHryvRAH
3FAUSJ4GJPH6MJ5X824srkcVsx2Y1RVt2i+bLXRXLq35aZkrFswohTXVM2h5dU7T
Uy2SL+q9pBUcS7fyv9bE7XV7KsFBJly/5p/wciVRZMnEK6X/w6KkBx/vGvlm5I/C
q196KazbVAYcl6s7KMrfFOYt0Wsto/gdEeesSVBkmcCTEkiKUjjJ4WEDVvAKK+qB
AiwgSdioqYmmEiUuredm6bhVqZG3K2mScoCy95N3jXkiDaKkaYgVtBuAU4Cdju/t
WgLIc9EnUYxXZtwnt889X62P1OkDOtKlj/mjdsGyF0Vrs1W+kErDO0NocOvu2Tk=
=9bL7
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2018-11-30' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 4.21
First set of patches for 4.21. Most notable here is support for
Quantenna's QSR1000/QSR2000 chipsets and more flexible ways to provide
nvram files for brcmfmac.
Major changes:
brcmfmac
* add support for first trying to get a board specific nvram file
* add support for getting nvram contents from EFI variables
qtnfmac
* use single PCIe driver for all platforms and rename
Kconfig option CONFIG_QTNFMAC_PEARL_PCIE to CONFIG_QTNFMAC_PCIE
* add support for QSR1000/QSR2000 (Topaz) family of chipsets
ath10k
* add support for WCN3990 firmware crash recovery
* add firmware memory dump support for QCA4019
wil6210
* add firmware error recovery while in AP mode
ath9k
* remove experimental notice from dynack feature
iwlwifi
* PCI IDs for some new 9000-series cards
* improve antenna usage on connection problems
* new firmware debugging infrastructure
* some more work on 802.11ax
* improve support for multiple RF modules with 22000 devices
cordic
* move cordic macros and defines to a public header file
* convert brcmsmac and b43 to fully use cordic library
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
In AP mode, if AP supports HE (and the STA), send the
STA_HE_CTXT command.
This is needed mainly for PPE (packet extension) params.
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When the firmware starts, it doesn't have any regulatory
information, hence it uses the world wide limitations. The
driver can feed the firmware with previous knowledge that
was kept in the driver, but the firmware may still not
update its internal tables.
This happens when we start a BSS interface, and then the
firmware can change the regulatory tables based on our
location and it'll use more lenient, location specific
rules. Then, if the firmware is shut down (when the
interface is brought down), and then an AP interface is
created, the firmware will forget the country specific
rules.
The host will think that we are in a certain country that
may allow channels and will try to teach the firmware about
our location, but the firmware may still not allow to drop
the world wide limitations and apply country specific rules
because it was just re-started.
In this case, the firmware will reply with MCC_RESP_ILLEGAL
to the MCC_UPDATE_CMD. In that case, iwlwifi needs to let
the upper layers (cfg80211 / hostapd) know that the channel
list they know about has been updated.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201105
Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
The oldest firmware supported by iwlmvm do support getting
the average beacon RSSI. Enable the sta_statistics() call
from mac80211 even on older firmware versions.
Fixes: 33cef92563 ("iwlwifi: mvm: support beacon statistics for BSS client")
Cc: stable@vger.kernel.org # 4.2+
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
TDLS discovery response frame is a unicast direct frame to the peer.
Since we don't have a STA for this peer, this frame goes through
iwl_tx_skb_non_sta(). As the result aux_sta and some completely
arbitrary queue would be selected for this frame, resulting in a queue
hang. Fix that by sending such frames through AP sta instead.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Enable low latency for softAP in all modes (standalone, SCM
and DCM).
This is in order to minimize the time the softAP leaves the channel for
other operations
Signed-off-by: Tova Mussai <tova.mussai@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Fix a bug that happens in the following scenario:
1) suspend without WoWLAN
2) mac80211 calls drv_stop because of the suspend
3) __iwl_mvm_mac_stop deallocates the aux station
4) during drv_stop the firmware crashes
5) iwlmvm:
* sets IWL_MVM_STATUS_HW_RESTART_REQUESTED
* asks mac80211 to kick the restart flow
6) mac80211 puts the restart worker into a freezable
queue which means that the worker will not run for now
since the workqueue is already frozen
7) ...
8) resume
9) mac80211 runs ieee80211_reconfig as part of the resume
10) mac80211 detects that a restart flow has been requested
and that we are now resuming from suspend and cancels
the restart worker
11) mac80211 calls drv_start()
12) __iwl_mvm_mac_start checks that IWL_MVM_STATUS_HW_RESTART_REQUESTED
clears it, sets IWL_MVM_STATUS_IN_HW_RESTART and calls
iwl_mvm_restart_cleanup()
13) iwl_fw_error_dump gets called and accesses the device
to get debug data
14) iwl_mvm_up adds the aux station
15) iwl_mvm_add_aux_sta() allocates an internal station for
the aux station
16) iwl_mvm_allocate_int_sta() tests IWL_MVM_STATUS_IN_HW_RESTART
and doesn't really allocate a station ID for the aux
station
17) a new queue is added for the aux station
Note that steps from 5 to 9 aren't really part of the
problem but were described for the sake of completeness.
Once the iwl_mvm_mac_stop() is called, the device is not
accessible, meaning that step 12) can't succeed and we'll
see the following:
drivers/net/wireless/intel/iwlwifi/pcie/trans.c:2122 iwl_trans_pcie_grab_nic_access+0xc0/0x1d6 [iwlwifi]()
Timeout waiting for hardware access (CSR_GP_CNTRL 0x080403d8)
Call Trace:
[<ffffffffc03e6ad3>] iwl_trans_pcie_grab_nic_access+0xc0/0x1d6 [iwlwifi]
[<ffffffffc03e6a13>] iwl_trans_pcie_dump_regs+0x3fd/0x3fd [iwlwifi]
[<ffffffffc03dad42>] iwl_fw_error_dump+0x4f5/0xe8b [iwlwifi]
[<ffffffffc04bd43e>] __iwl_mvm_mac_start+0x5a/0x21a [iwlmvm]
[<ffffffffc04bd6d2>] iwl_mvm_mac_start+0xd4/0x103 [iwlmvm]
[<ffffffffc042d378>] drv_start+0xa1/0xc5 [iwl7000_mac80211]
[<ffffffffc045a339>] ieee80211_reconfig+0x145/0xf50 [mac80211]
[<ffffffffc044788b>] ieee80211_resume+0x62/0x66 [mac80211]
[<ffffffffc0366c5b>] wiphy_resume+0xa9/0xc6 [cfg80211]
The station id of the aux station is set to 0xff in step 3
and because we don't really allocate a new station id for
the auxliary station (as explained in 16), we end up sending
a command to the firmware asking to connect the queue
to station id 0xff. This makes the firmware crash with the
following information:
0x00002093 | ADVANCED_SYSASSERT
0x000002F0 | trm_hw_status0
0x00000000 | trm_hw_status1
0x00000B38 | branchlink2
0x0001978C | interruptlink1
0x00000000 | interruptlink2
0xFF080501 | data1
0xDEADBEEF | data2
0xDEADBEEF | data3
Firmware error during reconfiguration - reprobe!
FW error in SYNC CMD SCD_QUEUE_CFG
Fix this by clearing IWL_MVM_STATUS_HW_RESTART_REQUESTED
in iwl_mvm_mac_stop(). We won't be able to collect debug
data anyway and when we will brought up again, we will
have a clean state from the firmware perspective.
Since we won't have IWL_MVM_STATUS_IN_HW_RESTART set in
step 12) we won't get to the 2093 ASSERT either.
Fixes: bf8b286f86 ("iwlwifi: mvm: defer setting IWL_MVM_STATUS_IN_HW_RESTART")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
The triplet of get trigger, is trigger enabled and is trigger stopped
repeats itself. Group them in a function to avoid code duplication.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
First set of new features for 4.20. mt76 driver is going through major
refactoring and that's why there are so many mt76 patches. iwlwifi is
also under heavy development and smaller changes to other drivers.
Also wireless-drivers was merged to fix a conflict between the two trees.
Major changes:
ath10k
* limit available channels via DT ieee80211-freq-limit
wil6210
* add 802.11r Fast Roaming support for AP and station modes
* add support for channel 4
iwlwifi
* new FW API handling
* some improvements in the PCI recovery mechanism
* enable a new scanning feature;
* continued work on HE (mostly radiotap)
* TKIP implementation in new devices
* work continues for new 22560 hardware
mt76
* add support for Alfa AWUS036ACM
* lots of refactoring to make it easier to add new hardware support
* prepare for adding mt76x0e (pci-e variant) support
* add CONFIG_MT76x0E kconfig symbol
brcmfmac
* add support CYW89342 mini-PCIe device
* add 4-way handshake offload detection for FT-802.1X
* enable NL80211_EXT_FEATURE_CQM_RSSI_LIST
* fix for proper support of 160MHz bandwidth
rtl8xxxu
* add rtl8188ctv support
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJbs6LVAAoJEG4XJFUm622b0sAH/1WLU433ZipgULs6PLULDz3/
cFS4CSu9+Hewx9MKvdr+vgMoru70CkiFIZMJeo/oNqAtFb6TQhXPFz2Ci3K4Y6jK
yZKATh9PvzQrOGQ1iy4p8QK6bQ9WRUNY5+elJuNQH62oB/SZ0XqCMU8ujUQRSaTC
xVqfIRnAtKcchAm/nqxx+EwlGCiUmlyt2pw2IUXXABLW7Fkj3Z3ISlOd8xVW6tca
XyWlx9pjZOrFrgOzyORB/B4TNI5q5CdcYPg2DEpqOs6LQeGXEq4BSxfxCe2de4ku
St6417K0OFTbUTZS7kJaxJnQFd1ZWhDtj5cJUzdNsSVzqeYeJoTnR4FBqDWLlec=
=7Nmq
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2018-10-02' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 4.20
First set of new features for 4.20. mt76 driver is going through major
refactoring and that's why there are so many mt76 patches. iwlwifi is
also under heavy development and smaller changes to other drivers.
Also wireless-drivers was merged to fix a conflict between the two trees.
Major changes:
ath10k
* limit available channels via DT ieee80211-freq-limit
wil6210
* add 802.11r Fast Roaming support for AP and station modes
* add support for channel 4
iwlwifi
* new FW API handling
* some improvements in the PCI recovery mechanism
* enable a new scanning feature;
* continued work on HE (mostly radiotap)
* TKIP implementation in new devices
* work continues for new 22560 hardware
mt76
* add support for Alfa AWUS036ACM
* lots of refactoring to make it easier to add new hardware support
* prepare for adding mt76x0e (pci-e variant) support
* add CONFIG_MT76x0E kconfig symbol
brcmfmac
* add support CYW89342 mini-PCIe device
* add 4-way handshake offload detection for FT-802.1X
* enable NL80211_EXT_FEATURE_CQM_RSSI_LIST
* fix for proper support of 160MHz bandwidth
rtl8xxxu
* add rtl8188ctv support
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
We no longer want to consider the RSSI if the beacon / probe
has been heard on an adjacent channel.
This was based on a firmware capability that is now
unavailable.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When operating as a soft ap with wep security, the key was not
configured to the fw for the stations, based on the fact that the
key will be specified in the tx command.
However, in the new tx api the tx command does not include the key,
which resulted in all data frames going out un-encrypted.
Fix it by configuring the key for all the stations as they are added.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Make the adjustments for gen2 TX and RX of TKIP packets. Strip MIC on
RX. Don't add IV space and keep the MIC space zeroed on TX.
Devices that support gen2 data path support TKIP only in station mode.
In all other modes, fall back to SW encryption. Do this early in the
set_key() callback so that the key flags would not be incorrectly set.
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Align to new 11ax draft D3.0. Change/add new MAC and PHY capabilities
and update drivers' 11ax capabilities and mac80211's debugfs
accordingly.
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The Free Software Foundation address is superfluous and causes
checkpatch to issue a warning when present. Remove all paragraphs
with FSF's address to prevent that.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
The parameter that indicated whether the LQ command should be sent
as sync or async was removed, causing the LQ command to be sent as
sync from interrupt context (e.g. from the RX path). This resulted
in a kernel warning: "scheduling while atomic" and failing to send
the LQ command, which ultimately leads to a queue hang.
Fix it by adding back the required parameter to send the command as
sync only when it is allowed.
Fixes: d94c5a820d ("iwlwifi: mvm: open BA session only when sta is authorized")
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Update reduce tx power command API to be compatible with new FW API.
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
A probe response built by a P2P GO should contain:
1. CSA/eCSA IE when relevant
2. If the corresponding probe request had P2P IE, then
need to add P2P IE with NOA attributes.
However, the NOA attributes and the updated channel switch
counter are known only to the FW. The solution is that FW
will send a notification with the relevant probe response
data and the driver will save it and update the probe
response accordingly.
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Runtime PM can only be used if CONFIG_PM is set. Move all the d0i3
code (which is essentially runtime PM) behind the CONFIG_PM flag.
This prevents undefined usage of some functions when CONFIG_PM is not
defined.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
