In some very rare cases the init flow may fail. In many cases, this is
recoverable, so we can retry. Implement a loop to retry two more times
after the first attempt failed.
This can happen in two different situations, namely during probe and
during mac80211 start. For the first case, a simple loop is enough.
For the second case, we need to add a flag to prevent mac80211 from
trying to restart it as well, leaving full control with the driver.
Cc: <stable@vger.kernel.org>
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20211110150132.57514296ecab.I52a0411774b700bdc7dedb124d8b59bf99456eb2@changeid
When we receive an association response, a significant amount
of time might have passed since we sent the corresponding
association request (mac80211 will wait up to 500ms for the TX
and then 100ms for the response after ACK was received). But
the time event is touched only when we send the assoc request,
so it might not have much time remaining, more easily causing
the (dreaded)
No beacon heard and the session protection is over already...
message.
Refactor iwl_mvm_mac_mgd_prepare_tx() and split out a new
function iwl_mvm_protect_assoc(), and call it on successful
association to extend the time event to the minimum time if
necessary.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211024181719.411c174d9e5e.I03c701c2e9e6788f34546e538264763db0ab30ef@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
If we somehow get disassociated while still waiting for a beacon
during connection, we can end up printing the
No beacon heard and the session protection is over already...
message even if we aren't really quite waiting for it anymore.
Remove the time event, if it's running, when we get disassociated
and don't need to wait for beacons anymore.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211024181719.6192e2363784.Ie9c2bfdc30dcfff2c4dd7c393c79e3ac182840a9@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Sometimes driver fails to detect misbehaving AP since we may
miss a few beacons (AP is declared misbehaving only after the second
time CSA counter has a wrong jump).
Move the print to the start of the function to avoid doubts when
analysing this kind of issues.
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211017165728.8e6b1eb8a436.I5fd6caee968007e91d03b93d6ea84b670ce047e9@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Set BT coex high priority during the 802.1X handshake to avoid
issues where BT is active enough to kill all the big negotiation
frames that we may need to send (e.g. with a large certificate),
leading to the connection not being established correctly. Give
WiFi priority over BT during this short but critical phase.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211017165728.a1825bbba397.I10315577fb41dfcec15c92e8f6785d9655f74c6a@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When auth/assoc completes, we should remove session protection,
except when association is successful, where we need it until a
beacon is received from the AP.
In particular, in the case of assoc comeback, currently the session
protection event just times out, leading to confusing messages:
wlan0: 42:00:00:00:00:00 rejected association temporarily; comeback duration 1000 TU (1024 ms)
iwlwifi 0000:00:00.0: Not associated and the session protection is over already...
wlan0: Connection to AP 42:00:00:00:00:00 lost
wlan0: associate with 42:00:00:00:00:00 (try 2/3)
mac80211 never does anything on the "Connection ... lost" as it's
not even connected.
Removing the session protection when it's no longer needed removes
those confusing messages and lets the device do other things in the
allocated time.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211017162352.95e4bebb069b.I635280e5d26c70414ac6eb5d62b46fe4bd942818@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
As part of the new rate_n_flags, a new version of tlc_update_notif
was added in FW in order to support the new rate_n_flags.
Add support for the new version, and move the all API to use the
new rate_n_flags only (if FW supports the old one - convert it).
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211017123741.9fc0cb5d5898.I1f88e02317f79f1be7f792c01236d836045a44b3@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
We should consider the P2P interface type, which isn't in
vif->type due to mac80211's special handling of that. Use
ieee80211_vif_type_p2p() to convert appropriately.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211017113927.8e992a3beee2.I4231ac8a7ae8f844e35a1ec221baf3e2b676e765@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
There's no need for all the complicated conditions here, any
bufferable MMPDUs or MMPDUs for client interfaces are already
coming through the TXQ interface, not iwl_mvm_mac_tx().
Simplify the logic.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210802172232.3939f7c5c43a.I1d5cb5262e31a000023d79acbb897b8db50adf0d@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Since switching to mac80211 TXQs, we no longer need to
advertise more hardware queues than ACs, since we don't
even set QUEUE_CONTROL anyway, so the vif->hw_queue[]
mapping array won't be used.
All we need (at least for now) is for hw->queues to
indicate that we have enough queues to handle QoS.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210802172232.80611a3c1ee7.I8a3d2b269421b6d8bada8c12cce3e095e6cfaeed@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
The firmware SMPS request should only be honoured if the
connection is currently with HE and on 160 MHz, so check
that and then potentially reapply any request if the BW
changes.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210802172232.0cdcac5660da.I9ee7956fd4f48399855d1f97728bc58b36caf112@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
EAPOL failure results in deauthentication with various reasons, not
related to AUTH failure specifically, so we just merge AUTH failure
with failed to assoc to AP.
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210802172232.2ff350d85eab.I02c5b5d29c0d5c2e014bd1081b07ed33772ae04d@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
* aggregation handling improvements for some drivers
* hidden AP discovery on 6 GHz and other HE 6 GHz
improvements
* minstrel improvements for no-ack frames
* deferred rate control for TXQs to improve reaction
times
* virtual time-based airtime scheduler
* along with various little cleanups/fixups
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEH1e1rEeCd0AIMq6MB8qZga/fl8QFAmDWUHgACgkQB8qZga/f
l8RxXA/+KjkrFUGDHlMTIzS/i03EcB+idLYy+XBWYuO3PN4p/uCCXLzdGfiRKTxp
iCAjYp0ZP01FlN4sOIN+qqrUMoN0e8xqBEY1DFbJELBB1knV4VR0FeBPPcBMUEgE
xAjdZnIsfKO1yU2mrdQVDnkvXr4jHDALePvGwCQe+4KUbwCmVjo6nb534v17Ie3C
MDNnGq395fCvo9NW+Yvzw6s9ZLdhr28bGhSBgBrqmPBx/9vm3b7BA8qO+X6BzAny
87S2x+z40wabBujCGMvw9J5H6OJ0ZLfbT0TumNznqQbCbmwRdSUC+W/cjgRq/aQn
CA3E9T7tofIr1mk9EgcjE8ax91TB/TTX5Nh9Huki25B7rNRBM57VnuEuzmXP5qBS
xgsr60agQHp2ZAGRPBC9msPcPCbvRfdl9ckTAF8/4vI7uEXSyYViX92M0F1FEy60
Mw13B8WeRA4bH22xHpqdXsyl0x2OQHXHlLHfpzmhcUy0i2cQOQMsWbl3g6CJMTq+
/InNSaG+cqrCVse734KJLumRhOq4+MkedYJlqL7uHZJrXlLgQ9Z8ewANjJ/BjTsQ
d8I16XkKPyv8UiJEwHZ6NaHvU48LR8T/r4ym9c/rz0DTWHZyp87QMYa55iwuk4Zo
cW7G3f/N7dMk9fGRxgfIrnNwNUCMsGcBSJeJyr5qT7u8+RW0bRo=
=nFvj
-----END PGP SIGNATURE-----
Merge tag 'mac80211-next-for-net-next-2021-06-25' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
Johannes berg says:
====================
Lots of changes:
* aggregation handling improvements for some drivers
* hidden AP discovery on 6 GHz and other HE 6 GHz
improvements
* minstrel improvements for no-ack frames
* deferred rate control for TXQs to improve reaction
times
* virtual time-based airtime scheduler
* along with various little cleanups/fixups
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
We have mgd_prepare_tx(), but sometimes drivers may want/need
to take action when the exchange finishes, whether successfully
or not.
Add a notification to the driver on completion, i.e. call the
new method mgd_complete_tx().
To unify the two scenarios, and to add more information, make
both of them take a struct that has the duration (prepare only),
subtype (both) and success (complete only).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210618133832.5d94e78f6230.I6dc979606b6f28701b740d7aab725f7853a5a155@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In case of unbinding, the FW would remove the session protection time
events without sending a notification, so explicitly cancel the
session protection, so future requests for mgd_prepare_tx() would not
assume that the session protection is running.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210618105614.7c30f85ed241.Ibc19fdbefca7135f2c4ea83d0aef6b81b5033dcd@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When we have a P2P Device active, we attempt to only change the
PHY context it uses when we get a new remain-on-channel, if the
P2P Device is the only user of the PHY context.
This is fine if we're switching within a band, but if we're
switching bands then the switch implies a removal and re-add
of the PHY context, which isn't permitted by the firmware while
it's bound to an interface.
Fix the code to skip the unbind/release/... cycle only if the
band doesn't change (or we have old devices that can switch the
band on the fly as well.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210612142637.e9ac313f70f3.I713b9d109957df7e7d9ed0861d5377ce3f8fccd3@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When doing scan while 6GHz channels are not enabled, the 6GHz band
is not scanned. Thus, if there are no APs on the 2GHz and 5GHz bands
(that will allow discovery of geographic location etc. that would
allow enabling the 6GHz channels) but there are non collocated APs
on 6GHz PSC channels these would never be discovered.
To overcome this, FW added support for performing passive UHB scan
in case no APs were discovered during scan on the 2GHz and 5GHz
channels.
Add support for enabling such scan when the following conditions are
met:
- 6GHz channels are supported but not enabled by regulatory.
- Station interface is not associated or less than a defined time
interval passed from the last resume or HW reset flows.
- At least 4 channels are included in the scan request
- The scan request includes the widlcard SSID.
- At least 50 minutes passed from the last 6GHz passive scan.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210331121101.7c7bd00e0aeb.Ib226ad57e416b43a710c36a78a617d4243458b99@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When we do queue sync, it's confusing that we have the structures
declared in the FW API header files that aren't really firmware,
and the union is also confusing - especially now in the code that
checks the size on the return.
So rework this: change the type of sync and whether to do it in a
synchronous fashion to arguments, and build the data structure in
the function, so we don't need the union.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210331121101.f62833fd9893.I612d7ac1c655ec4880329360e15d207698c750bc@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
We use mvm->queue_sync_state to wait for synchronous queue sync
messages, but if an async one happens inbetween we shouldn't
clear mvm->queue_sync_state after sending the async one, that
can run concurrently (at least from the CPU POV) with another
synchronous queue sync.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210331121101.d11c9bcdb4aa.I0772171dbaec87433a11513e9586d98b5d920b5f@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
"Fully associated" means that we heard a beacon with the DTIM
information and the firmware is configured to track the beacons.
Since the firmware needs to track the beacons for the CSA, we
can't configure the firmware for CSA before it knows when the
beacons are expected otherwise we'd get ASSERT 301D.
If we are required to start CSA before we told the firmware
when the beacons are expected to arrive, just report a
failure and let mac80211 disconnect.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210330162204.9adaedeb59e4.Idaad6aaf3f9759d023b8e00b10064915c0db9aa3@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
The STA_CTXT_HE_NIC_NOT_ACK_ENABLED flag tells the firmware
whether *we* support ack-enabled.
So what should be checked is our *own* capability and not
the *peer's* capability.
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210210171218.59f44e210096.I8f31968f6f7303255e212d869ca0131becd309aa@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
* Check FW notification sizes for robustness;
* Improvements in the NAPI implementation;
* Implement a workaround for CCA-EXT;
* Add new FW API support;
* Fix a CSA bug;
* Implement PHY integration version parsing;
* A bit of refactoring;
* One more CSA bug fix, this time in the AP side;
* Support for new So devices and a bit of reorg;
* Per Platform Antenna Gain (PPAG) fixes and improvements;
* Improvements in the debug framework;
* Some other clean-ups and small fixes.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEF3LNfgb2BPWm68smoUecoho8xfoFAmAdGCUACgkQoUecoho8
xfqbGxAAlKXsYDTey4bCNbG3aimBGyNkmOBrAAcsH/zxZ4UHzUGLl0xflMZwpT9S
XXYBnR/q8lb7lZ+0zj/Jc4R2D8DKGhKwQ1Q+ZINRm7pEgJ3hZZlgvPgWeyOi+z0Y
DnCD8Ga2lJPmyqwxipMgL1wi5POKOTFjWwTe8cCQ5xy6EkGVpNi+PdZitFubq0Oj
oAOe6st6v/GgtqGHh8TNX11pWadoBhqkkdlPEnuSvx9MAxSYtrued4vs8MowNP9i
tkak8+eeEfLbfyY/sxvgClFR4T072/QvUoofPMyoCyo+cBa42EMXHRzk6fAUxZ1t
brjJFOUnuACCmU2CfzoZTdZPMDB/x4vk6UWIf2p0kL7paRt/IVMb2/DNuTo042Z1
6xPBoUXyPzL7sH2leZ/Pj9aNMxfK5mhLVMn/htedaMfjdNX52MfgVmyAR2zcq0iC
r4xtq1xi/+GFmT1AYXIYGVqkwE/aSTNqi+0oTRK8u2g5CbokRVJnWnUido0Hnlg0
yS2l0gU7UyNFj9LHOVR8UP0oD7myDkkrqTeY9Us+ncLtYXmqx0dnFbvWucIrSHvL
BVKZzgYXnFbCghSlHb2ZJN4nxKzq8rxkBBv7CZMPneK1VYEyTichUo3b4gzFTfIy
9EP0GzKPQStxaDzAfr9cju0IvvCW1O0vA6gGAe0D+bHVYhqi/TA=
=c570
-----END PGP SIGNATURE-----
Merge tag 'iwlwifi-next-for-kalle-2021-02-05' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
iwlwifi patches intended for v5.12
* Check FW notification sizes for robustness;
* Improvements in the NAPI implementation;
* Implement a workaround for CCA-EXT;
* Add new FW API support;
* Fix a CSA bug;
* Implement PHY integration version parsing;
* A bit of refactoring;
* One more CSA bug fix, this time in the AP side;
* Support for new So devices and a bit of reorg;
* Per Platform Antenna Gain (PPAG) fixes and improvements;
* Improvements in the debug framework;
* Some other clean-ups and small fixes.
# gpg: Signature made Fri 05 Feb 2021 12:04:21 PM EET using RSA key ID 1A3CC5FA
# gpg: Good signature from "Luciano Roth Coelho (Luca) <luca@coelho.fi>"
# gpg: aka "Luciano Roth Coelho (Intel) <luciano.coelho@intel.com>"
If the firmware has support, then advertise it to the stack and
send the key down. Since we re-check the protection in the host
anyway, we don't really need to do anything on RX except that we
should drop frames that the firmware _knows_ are replay errors,
since beacon filtering might otherwise result in replays being
possible.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210205110447.f5a3d53301b3.I23e84c9bb0b039d9106a07e9d6847776757f9029@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
While disconnecting from the AP due to bad channel switch
params (e.g. too long Tx block), do not send the firmware
'CSA abort' before disconnecting. That causes canceling the
immediate quiet and can cause transmitting data before the
disconnection happens.
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117164916.b9af359a675f.I996fc7eb3d94e9539f8b117017c428448c42c7ad@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When we want to stop TX'ing because we are suspending, we
have two options: either we check system_pm_mode or we
check the mvm's status that has a bit for the suspend
flow.
The latter is better because test_bit is atomic. Also
add a call to synchronize_net after we set the bit to
make sure that all the new Tx see the bit before we
actually complete the suspend flow.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117130510.243c88781302.I5c0379c5a7e5d49410569e7fcd2fff7a419c6dea@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
In the new api all the flush in the FW is done before we
get the response and in the response we only get the updated
read pointer and all queued packets don't get anymore rx_tx
per packet to free the queued packet, so driver needs to free
all queued packets on flushed queue at once after flush response.
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117130510.4bd0eca8c0ef.I1601aad2eb2cc83f6f73b8ca52be57bb9fd626ab@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
If there are frequent CCA delays due to the extension channel
as detected by the firmware, and we're on 2.4 GHz, then handle
this by disconnecting (with a reconnect hint).
When we disconnect, we'll also update our capabilities to use
only 20 MHz on the next connection (if it's on 2.4 GHz) as to
avoid the use of the extension channel that has too much noise.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210117130510.4de9c363b0b5.I709b7e6f73a7537c53f22d7418927691259de8a8@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
drivers/net/can/dev.c
b552766c87 ("can: dev: prevent potential information leak in can_fill_info()")
3e77f70e73 ("can: dev: move driver related infrastructure into separate subdir")
0a042c6ec9 ("can: dev: move netlink related code into seperate file")
Code move.
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
57ac4a31c4 ("net/mlx5e: Correctly handle changing the number of queues when the interface is down")
214baf2287 ("net/mlx5e: Support HTB offload")
Adjacent code changes
net/switchdev/switchdev.c
20776b465c ("net: switchdev: don't set port_obj_info->handled true when -EOPNOTSUPP")
ffb68fc58e ("net: switchdev: remove the transaction structure from port object notifiers")
bae33f2b5a ("net: switchdev: remove the transaction structure from port attributes")
Transaction parameter gets dropped otherwise keep the fix.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Currently, _everything_ in cfg80211 holds the RTNL, and if you
have a slow USB device (or a few) you can get some bad lock
contention on that.
Fix that by re-adding a mutex to each wiphy/rdev as we had at
some point, so we have locking for the wireless_dev lists and
all the other things in there, and also so that drivers still
don't have to worry too much about it (they still won't get
parallel calls for a single device).
Then, we can restrict the RTNL to a few cases where we add or
remove interfaces and really need the added protection. Some
of the global list management still also uses the RTNL, since
we need to have it anyway for netdev management, but we only
hold the RTNL for very short periods of time here.
Link: https://lore.kernel.org/r/20210122161942.81df9f5e047a.I4a8e1a60b18863ea8c5e6d3a0faeafb2d45b2f40@changeid
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> [marvell driver issues]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In the new CSA flow, we remain associated during CSA, but
still do a unbind-bind to the vif. However, sending the power
command right after when vif is unbound but still associated
causes FW to assert (0x3400) since it cannot tell the LMAC id.
Just skip this command, we will send it again in a bit, when
assigning the new context.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20210115130252.64a2254ac5c3.Iaa3a9050bf3d7c9cd5beaf561e932e6defc12ec3@changeid
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly using the fallthrough pseudo-keyword as a
replacement for a number of "fall through" markings.
Notice that Clang doesn't recognize "fall through" comments as
implicit fall-through.
Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201117135053.GA13248@embeddedor
If the channel switch delay that we would incur after the channel
switch actually happens is longer than the quiet time we're willing
to tolerate, disconnect as well.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20201209231352.3bc3449922da.Ib0255deb67b2fc21317e274adcacb545bb1dc669@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When we get a channel switch with a very long quiet period, we schedule
a work to disconnect after a while. This work runs in background. In the
meanwhile, we keep getting beacons and sending FW modify command for each.
This has a potential race, where we modify the CSA after we aborted it.
Protect the flow by setting csa_failed to true in case we abort, and check
it before sending the modify command.
This required a modification to the way we treat csa_failed in
iwl_mvm_post_channel_switch:
1. The variable isn't being reset anymore, so we can still look at it in
iwl_mvm_channel_switch_rx_beacon. This is fine, since we reset it when
starting a new CSA.
2. There is no more early return in case of csa_failed. This is fine,
since before this patch csa_failed was set only for GO, and for GO the
function is only resetting the power settings, which we want to restore
even in case of failure.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20201209231352.b023856bdf39.I4ed0149e0018fe5e1ae3c2a1cbc614954016063f@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
We're currently doing accounting on the queue sync with an
atomic variable that counts down the number of remaining
notifications that we still need.
As we've been hitting issues in this area, modify this to
track a bitmap of queues, not just the number of queues,
and print out the remaining bitmap in the warning.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20201209231352.0a3fa177cd6b.I7c69ff999419368266279ec27dd618eb450908b3@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
The argument type to iwl_mvm_notify_rx_queue() is currently just
a u8 *, but that's misleading because we actually need the inner
data to be of type struct iwl_mvm_internal_rxq_notif, because we
interpret it when we get it back from the device (to check the
sync bool and possibly the cookie.)
Therefore, clear up any potential confusion and require that the
data passed is of type struct iwl_mvm_internal_rxq_notif *.
Also, while at it, rename the "count" to "notif_size" as "count"
doesn't really clearly say what it's counting.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20201209231352.d28e14682bdc.I9ac366aa97db045be4daa4ba263267a3ac6a6a2f@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Add support to the 6GHz band (aka. Ultra High Band or UHB). This
allows us to scan and connect to channels in that band, including all
the relevant features, such as preferred scan channels, colocated
channels etc.
Co-developed-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Co-developed-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Co-developed-by: Tova Mussai <tova.mussai@intel.com>
Signed-off-by: Tova Mussai <tova.mussai@intel.com>
Co-developed-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Co-developed-by: Tali Levi Rovinsky <Tali.Levi-rovinsky@intel.com>
Signed-off-by: Tali Levi Rovinsky <Tali.Levi-rovinsky@intel.com>
Co-developed-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Co-developed-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20201210000657.0fdbfc3d7352.Idb648536faf21716e2ab2c6d6890d3e49f719cd3@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
During CSA, we briefly nullify the phy context, in __iwl_mvm_unassign_vif_chanctx.
In case we have a FW assert right after it, it remains NULL though.
We end up running into endless loop due to mac80211 trying repeatedly to
move us to ASSOC state, and we keep returning -EINVAL. Later down the road
we hit a kernel panic.
Detect and avoid this endless loop.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.d64de2c17bff.Iedd0d2afa20a2aacba5259a5cae31cb3a119a4eb@changeid
We use mvm->queue_sync_state to wait for synchronous queue sync
messages, but if an async one happens inbetween we shouldn't
clear mvm->queue_sync_state after sending the async one, that
can run concurrently (at least from the CPU POV) with another
synchronous queue sync.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fixes: 3c514bf831 ("iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queues")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201107104557.51a3148f2c14.I0772171dbaec87433a11513e9586d98b5d920b5f@changeid
We introduced a new flow to remove an on-going CSA but we
assumed the firwmare understands the
CHANNEL_SWITCH_TIME_EVENT_CMD. This is not true for 7265 and down.
Don't send this command for those devices, but rather use the older
command.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.2574e3e47927.Ic0c56411da1096e9a45ee5c3383edf777c5baca0@changeid
ADD_STA_CMD_API_S ver 12 was added in order to properly support
auxiliary activities in CDB NICs. In the new version we don't need
to allocate an aux station at initialization, instead we add an
aux station only when an auxiliary activity that requires a dedicated Tx
queue is needed. For now the only case we need this kind of activity is
when using hot spot 2.0
Signed-off-by: Nathan Errera <nathan.errera@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20201008180656.700e6e2e3077.Icdd807b6a3ad3fed806449ea0a13f856aa20e632@changeid
