While doing a passive scan, the firmware will report per-channel survey
information. This information is primarily useful for hostapd when doing
an ACS (Automatic Channel Selection). Collect this information and add
it to the result set when getting the survey information.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240506095953.9287591a5999.I54a3f9f6480d3694e67eea1cb4f5853beace2780@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The move of the scan complete notification handling to the wiphy worker
introduced a race between scan complete notification and scan abort:
- The wiphy lock is held, e.g., for rfkill handling etc.
- Scan complete notification is received but not handled yet.
- Scan abort is triggered, and scan abort is sent to the FW. Once the
scan abort command is sent successfully, the flow synchronously waits
for the scan complete notification. However, as the scan complete
notification was already received but not processed yet, this hangs for
a second and continues leaving the scan status in an inconsistent
state.
- Once scan complete handling is started (when the wiphy lock is not held)
since the scan status is not an inconsistent state, a warning is issued
and the scan complete notification is not handled.
To fix this issue, switch back the scan complete notification to be
asynchronously handling, and only move the link selection logic to
a worker (which was the original reason for the move to use wiphy lock).
While at it, refactor some prints to improve debug data.
Fixes: 07bf5297d3 ("wifi: iwlwifi: mvm: Implement new link selection algorithm")
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240506095953.1f484a86324b.I63ed445a47f144546948c74ae6df85587fdb4ce3@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add a reading for all active EMLSR blocking reasons for testing
purposes.
Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240506095953.6d494a335e81.Ic0fa6a9636e3c1a3b1420e85e704a19d4a56e8d9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When there's an active link in a non-station vif, the station vif is
not allowed to enter EMLSR
Note that blocking EMLSR by calling iwl_mvm_block_esr() we will schedule
an exit from EMLSR worker, but the worker cannot run before the
activation of the non-BSS link, as ieee80211_remain_on_channel already
holds the wiphy mutex.
Handle that by explicitly calling ieee80211_set_active_links()
to leave EMLSR, and then doing iwl_mvm_block_esr() only for
consistency and to avoid re-entering it before ready.
Note that a call to ieee80211_set_active_links requires to release the
mvm mutex, but that's ok since we still hold the wiphy lock. The only
thing that might race here is the ESR_MODE_NOTIF, so this changes its
handler to run under the wiphy lock.
Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
Co-developed-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240505091420.916193759f8a.Idf3a3caf5cdc3e69c81710b7ceb57e87f2de87e4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If CSA is happening, then exit EMLSR to keep the better link,
which is the primary link unless that's doing the CSA with
quiet. This is done because we can't transmit the OMN frame
on a quiet link, but want to exit EMLSR during CSA for better
beacon reception, so we can follow the switch accurately.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240505091420.3ffff9577f08.I2620971fa5aef789e0d4a588def4c2621e8bed5b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Adjust EMLSR activation to account for traffic levels. By
tracking the number of RX/TX MPDUs, EMLSR will be activated only when
traffic volume meets the required threshold.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240505091420.9480f99ac8fc.If9eb946e929a39e10fe5f4638bc8bc3f8976edf1@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
EMLSR can't be activated from mac80211. Except for the debugfs, which is
intended for testing purposes. Currently we don't allow entering EMLSR
from debugfs if EMLSR is blocked, i.e. if mvmvif::esr_disable_reason is
not 0. But we need a way to activate EMLSR regardless of the vif being
blocked, for testing. Remove the check of esr_disable_reason
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240505091420.bc3c24d9e0e6.Iad60e22a0d7e2b2b989051e1140b6dc98bef7bcc@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If the reason for exiting EMLSR was a blocking reason, wait for the
corresponding unblocking event:
- if there is an ongoing scan - do nothing. Link selection will be
triggered at the end of it.
- If more than 30 seconds passed since the exit, trigger MLO scan, which
will trigger link selection
- If less then 30 seconds passed since exit, reuse the latest link
selection result
If the reason for exiting EMLSR was an exit reason (IWL_MVM_EXIT_*),
schedule MLO scan in 30 seconds.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Link: https://msgid.link/20240505091420.6a808c4ae8f5.Ia79605838eb6deee9358bec633ef537f2653db92@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
BT Coex disables EMLSR only for a 2.4 GHz link, but doesn't block the
vif from using EMLSR with a different link pair. In addition, storing it
in mvmvif:disable_esr_reason requires extracting the BT Coex bit before
checking if EMLSR is blocked or not for a specific vif.
Therefore, change the BT Coex bit to be an exit reason and not a
blocker. On link selection, EMLSR mode will be re-calculated for the 2.4
GHz link instead of checking that bit.
While at it, move the relevant function declarations to the EMLSR
functions area in mvm.h
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240505091420.a2e93b67c895.I183a0039ef076613144648cc46fbe9ab3d47c574@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If the RSSI of a link is low enough, don't use it for EMLSR.
If EMLSR is already active and the RSSI of one of the links gets low,
exit EMLSR by deactivating that link.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240416134215.73263c000263.Ieb2b18855a2719b5e18ad2fa8a3e855ca4e23938@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We can't be an EMLSR while suspended with wowlan. De-activate the
secondary link upon wowlan entring.
Set the blocking reason upon suspension and clear it upon resume.
Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240416134215.6ea884b3f095.I84233cb1c79ba538defafb8ddb983c47f04a400a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In EMLSR we need to track the RSSI of both links, and exit if the RSSI of
one of the links got too low.
For that request the FW to send statistics every 5 seconds when in EMLSR.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240416134215.6e19d596d77f.Ica2a75a031b1bced0dc2e18c5d365b5eb0d3ec07@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211 invokes the driver callback drv_can_activate_links() from
ieee80211_set_active_links to verify it can activate the desired link
combination.
However, ieee80211_set_active_links is called with more than one link in
2 cases:
- After driver's link selection decided to enter EMLSR
- From debugfs, for testing purposes.
For both cases there is no need to recompute all the considerations
determining whether to activate EMLSR.
Instead, only check if the vif is not blocked for EMLSR.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240416134215.202cf5a9ef2c.I65e4698b730a8652ad8d1c01420aabb41a1d04fd@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Address scenarios where repeated entry and exit from EMLSR occur, such as
encountering missed beacons on a specific link,
while still discovering that link during a scan.
To mitigate this, introduce the EMLSR prevention mechanism, which operates
as follows:
- On each exit from EMLSR event, record the timestamp and the exit
reason.
- If two consecutive exits happen for the same reason within a
400-second window, enforce a 300-second EMLSR prevention.
- If a third exit for the same reason occurs within 400 seconds from the
second exit, enforce an extended EMLSR prevention of 600 seconds.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240416134215.d820ee98b300.I6406db40cf25eabdba602afd783466473b909216@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
It's dangerous to re-initialize works repeatedly, especially
delayed ones that have an associated timer, and even more so
if they're not necessarily canceled inbetween. This can be
the case for these workers here during FW restart scenarios,
so make sure to initialize it only once.
While at it, also ensure it is cancelled correctly.
Fixes: f678061402 ("iwlwifi: mvm: disconnect in case of bad channel switch parameters")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240416134215.ddf8eece5eac.I4164f5c9c444b64a9abbaab14c23858713778e35@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There are reasons for which we need to exit EMLSR, but not to block it
completely, and there are reasons for which we need to block EMLSR.
For both reason types we have the enum iwl_mvm_esr_state, when the
blocking reasons are stored in the `mvmvif::esr_disable_reason` bitmap.
This change introduces the APIs to use in the different cases:
- iwl_mvm_exit_esr - will exit from EMLSR mode.
- iwl_mvm_block_esr - will update the bitmap and exit EMLSR, to
be used for the blocking reasons only.
- iwl_mvm_unblock_esr - will update the bitmap. To be used for the
blocking reasons only.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240416134215.d54142a75876.I552926065521f5f848c37b0bd845494bd7865fb7@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Replaces the current logic with a new algorithm based on the link
grading introduced in a previous patch.
The new selection algorithm will be invoked upon successful scan to ensure
it has the necessary updated data it needs.
This update delegates the selection logic as the primary link
determiner in EMLSR mode, storing it in mvmvif to avoid repeated
calculations, as the result may vary.
Additionally, includes tests for iwl_mvm_valid_link_pair to validate
link pairs for EMLSR.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240416134215.309fb1b3fe44.I5baf0c293c89a5a28bd1a6386bf9ca6d2bf61ab8@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The functions that are link related, so they should be in link.c and
not in mld-mac80211.c. Move them.
Also move the different prototypes to the right place in mvm.h
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240416134215.e7c368256fa0.I6b15805a7c8a75d1814f1a829601daf4d3788731@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currenty iwl_mvm_mld_select_links() doesn't fully check that
EMLSR is allowed before selecting the 2 best links.
Although it will fail in ieee80211_set_active_links(), it is preferred
to avoid the redundent calculations.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240416134215.3578a93feb1a.I1cd91608bb73fbe19b8dfdf90e14ce40b98c3430@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2.4 GHz/LB (low band) link can't be used in an EMLSR links pair when
BT is on. But EMLSR is still allowed for a pair of links which none of
them operates in LB.
In the existing code, EMLSR will always be disabled if one of the
usable links is in LB (and BT is on).
Move this check to the code that verifies a specific pair of links,
and only if one of these links operates on LB - disable EMLSR.
Fixes: 10159a4566 ("wifi: iwlwifi: disable eSR when BT is active")
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240416134215.2841006b5cc4.I45ffd583f593daa950322852ceb9454cbf497e24@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The function iwl_mvm_can_enter_esr() is (among others) calculating
if EMLSR mode is disabled due to BT coex by calling
iwl_mvm_bt_coex_calculate_esr_mode(), then stores the decision in
mvmvif::esr_disable_reason.
But there is no need to calculate this every time iwl_mvm_can_enter_esr
is called. Fix this by calculating it once after authorization,
and in iwl_mvm_can_enter_esr only check mvmvif::esr_disable_reason.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240416134215.a767e243366e.I3b32d36cda23f67dc103a28a9bdccb0039d22574@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
For selecting what link(s) out of the usable ones
to activate, calculate a grade for a given link.
Calculation of a link grade is done as follows:
1. get the estimated throughput according to the RSSI of the link, this
will be the base grade
2. get the channel load from the BSS Load Element, subtracting the load
caused by us. Apply the factor on the grade.
3. puncturing factor: calculate the percentage of the punctured
subchannels (out of the total subchannels). Apply this on the grade.
The link grading will be used by the link selection mechanism in a later
patch.
Also add KUnit tests for it.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240416134215.a6799dbd5643.If137ca6dc443606c7d8c99ec1fc38b325003a7c1@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This will maintain a bitmap of reasons for which we want to avoid
enabling EMLSR.
For now, we have a single reason: BT coexistence, but we will add soon
more reasons. Make it a bitmap to make it easier to manage.
Since we'll impact the parameters that impact the enablement /
disablement of EMLSR from several places, introduce a generic function
that takes into account the current state and execute the decision that
must be taken.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240416134215.94c3590c6f27.I6a190da5025d0523ef483ffac0c64e26675041e6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This function is useful in other places, so move it in order to share
it.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240415114847.8e456d6c599e.Ibaa76864b30c990bfc35d886ec1344d513a96d14@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The first "new features" pull request for v6.10 with changes both in
stack and in drivers. The big thing in this pull request is that
wireless subsystem is now almost free of sparse warnings. There's only
one warning left in ath11k which was introduced in v6.9-rc1 and will
be fixed via the wireless tree.
Realtek drivers continue to improve, now we have support for RTL8922AE
and RTL8723CS devices. ath11k also has long waited support for P2P.
This time we have a small conflict in iwlwifi as we didn't consider it
as major enough to justify merging wireless tree to wireless-next. But
Stephen has an example merge resolution which should help with fixing
the conflict:
https://lore.kernel.org/all/20240326100945.765b8caf@canb.auug.org.au/
Major changes:
rtw89
* RTL8922AE Wi-Fi 7 PCI device support
rtw88
* RTL8723CS SDIO device support
iwlwifi
* don't support puncturing in 5 GHz
* support monitor mode on passive channels
* BZ-W device support
* P2P with HE/EHT support
ath11k
* P2P support for QCA6390, WCN6855 and QCA2066
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEiBjanGPFTz4PRfLobhckVSbrbZsFAmYNIqIRHGt2YWxvQGtl
cm5lbC5vcmcACgkQbhckVSbrbZt8jAf9H+o91boD34/qVdI5LWEcFhVKEkHpNtwm
Y1sTKNBEtN1Gs2zcljjO6PqN9N4v2+lA42KSpzP5M42FfpI2aATI2v8jYsKTXOl2
YVwF+8pDiAsi0YtQTxIthygjzTpsePCfj8z0xJaKGm195T+fMm9UebYETrfxxOp/
z5StsJIPI0twgSLKKUWvLpX4ESt0l0HLJY1ok99sk4Cj36EKn6b9LbBinDKr6GcQ
mGNtPyq0j4l0kS5qae9BbXZUohO54o8wiFnApdwGfA7S/kLY7eUtwZy7T050b62P
zbNafwZbIjrH7dNcGfe6Fdr7PjQYFeI5Nh7dXxqM2LJOQsYXU/tcWQ==
=WrPE
-----END PGP SIGNATURE-----
Merge tag 'wireless-next-2024-04-03' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Kalle Valo says:
====================
wireless-next patches for v6.10
The first "new features" pull request for v6.10 with changes both in
stack and in drivers. The big thing in this pull request is that
wireless subsystem is now almost free of sparse warnings. There's only
one warning left in ath11k which was introduced in v6.9-rc1 and will
be fixed via the wireless tree.
Realtek drivers continue to improve, now we have support for RTL8922AE
and RTL8723CS devices. ath11k also has long waited support for P2P.
This time we have a small conflict in iwlwifi, Stephen has an example
merge resolution which should help with fixing the conflict:
https://lore.kernel.org/all/20240326100945.765b8caf@canb.auug.org.au/
Major changes:
rtw89
* RTL8922AE Wi-Fi 7 PCI device support
rtw88
* RTL8723CS SDIO device support
iwlwifi
* don't support puncturing in 5 GHz
* support monitor mode on passive channels
* BZ-W device support
* P2P with HE/EHT support
ath11k
* P2P support for QCA6390, WCN6855 and QCA2066
* tag 'wireless-next-2024-04-03' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (122 commits)
wifi: mt76: mt7915: workaround dubious x | !y warning
wifi: mwl8k: Avoid -Wflex-array-member-not-at-end warnings
wifi: ti: Avoid a hundred -Wflex-array-member-not-at-end warnings
wifi: iwlwifi: mvm: fix check in iwl_mvm_sta_fw_id_mask
net: rfkill: gpio: Convert to platform remove callback returning void
wifi: mac80211: use kvcalloc() for codel vars
wifi: iwlwifi: reconfigure TLC during HW restart
wifi: iwlwifi: mvm: don't change BA sessions during restart
wifi: iwlwifi: mvm: select STA mask only for active links
wifi: iwlwifi: mvm: set wider BW OFDMA ignore correctly
wifi: iwlwifi: Add support for LARI_CONFIG_CHANGE_CMD cmd v9
wifi: iwlwifi: mvm: Declare HE/EHT capabilities support for P2P interfaces
wifi: iwlwifi: mvm: Remove outdated comment
wifi: iwlwifi: add support for BZ_W
wifi: iwlwifi: Print a specific device name.
wifi: iwlwifi: remove wrong CRF_IDs
wifi: iwlwifi: remove devices that never came out
wifi: iwlwifi: mvm: mark EMLSR disabled in cleanup iterator
wifi: iwlwifi: mvm: fix active link counting during recovery
wifi: iwlwifi: mvm: assign link STA ID lookups during restart
...
====================
Link: https://lore.kernel.org/r/20240403093625.CF515C433C7@smtp.kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The first fixes for v6.9. Ping-Ke Shih now maintains a separate tree
for Realtek drivers, document that in the MAINTAINERS. Plenty of fixes
for both to stack and iwlwifi. Our kunit tests were working only on um
architecture but that's fixed now.
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEiBjanGPFTz4PRfLobhckVSbrbZsFAmYEbzoRHGt2YWxvQGtl
cm5lbC5vcmcACgkQbhckVSbrbZsjZwgApoOcTn/mkX7DEViByMUpOrdNYqkJh+Tv
RkDDqhbA97i+zlxWp1dwtdfn0CYEcCW2XBucrfDNZMcR/cfXy2Wgdr6BD/FG9S2D
oQX6QQijO7g9uqNgDfIVAC0ftJEeWkM7YUhqNDVR751gjy2WOOJqPtSgNGd873By
P0rbHyfykHMzyYbwlzMLosO3RigefD1p1qkkODPf2OMo5A4tL1gL9AfEk3Kef9sf
9JHHWCLR378sm2sMpGw2Lxw4ypazl08ABu1yAWJk6Xipn80D/b08YUH/1yiKuq22
JrxhllJu2nqaHxXOzje2WEapTBz9tpTAwigOUQJiVZWm6ii19giGng==
=89Ft
-----END PGP SIGNATURE-----
Merge tag 'wireless-2024-03-27' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless
Kalle Valo says:
====================
wireless fixes for v6.9-rc2
The first fixes for v6.9. Ping-Ke Shih now maintains a separate tree
for Realtek drivers, document that in the MAINTAINERS. Plenty of fixes
for both to stack and iwlwifi. Our kunit tests were working only on um
architecture but that's fixed now.
* tag 'wireless-2024-03-27' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: (21 commits)
MAINTAINERS: wifi: mwifiex: add Francesco as reviewer
kunit: fix wireless test dependencies
wifi: iwlwifi: mvm: include link ID when releasing frames
wifi: iwlwifi: mvm: handle debugfs names more carefully
wifi: iwlwifi: mvm: guard against invalid STA ID on removal
wifi: iwlwifi: read txq->read_ptr under lock
wifi: iwlwifi: fw: don't always use FW dump trig
wifi: iwlwifi: mvm: rfi: fix potential response leaks
wifi: mac80211: correctly set active links upon TTLM
wifi: iwlwifi: mvm: Configure the link mapping for non-MLD FW
wifi: iwlwifi: mvm: consider having one active link
wifi: iwlwifi: mvm: pick the version of SESSION_PROTECTION_NOTIF
wifi: mac80211: fix prep_connection error path
wifi: cfg80211: fix rdev_dump_mpp() arguments order
wifi: iwlwifi: mvm: disable MLO for the time being
wifi: cfg80211: add a flag to disable wireless extensions
wifi: mac80211: fix ieee80211_bss_*_flags kernel-doc
wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes
wifi: mac80211: fix mlme_link_id_dbg()
MAINTAINERS: wifi: add git tree for Realtek WiFi drivers
...
====================
Link: https://lore.kernel.org/r/20240327191346.1A1EAC433C7@smtp.kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add an option to force sending unprotected ranging request even if the
station is associated to the responder or a PASN keys are configured.
This is used for testing.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240319100755.8523150148ec.I7ab6c547513717e69ec385f72a8f43ea00bd9e0a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add a new scan type that can be used for internal MLO purposes, i.e.,
in case updated BSS information is required. Currently only passive
scanning is supported.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240319100755.5ce3e756cf8f.I4a41065f6b3a6ec6c6e44e83bc97c277ff7c599e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The firmware has handled quiet in CSA for a long time now, but
it didn't really matter much. However, now with quiet CSA on a
perhaps secondary link, we don't want mac80211 to stop queues,
we can continue using a link that's not requiring quiet. Set
the feature flag for MLO-capable devices indicating that we'll
handle the quiet entirely in the driver/device.
However, the firmware doesn't handle quiet in AP mode since we
don't really expect to really be needing that (without radar
detection), but - even for testing - make that work properly
by simply not pulling from TXQs in this scenario.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240311081938.fa75403b5eaa.Ie3ff02215f810fcfefd6a22c481567f94f61c0c6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If, for any reason, we're going to attempt to flush the queues
while quiet CSA is happening, this cannot succeed. This could
be the case if for example mac80211 were to flush after TXing
e.g. a deauth frame due to disconnecting during the CSA.
In this case, drop the frames instead, the firmware won't let
us do any transmissions and may also become unhappy if we're
not going to disconnect quickly enough.
Currently this doesn't happen as mac80211 stops queues, but
we'll want to let mac80211 know not to stop queues for proper
multi-link support during CSA, so we need to handle this case.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240311081938.d5d629f32ea8.I86d9b849d92273542bfc2d9c671b66179e7ebb72@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
With MLO, the station id in wowlan can be other than 0.
Set the correct station in the protocol offload command.
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240311081938.ace4f793872d.Id984110576a72acc84493217ca95564c3cd362bd@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In the non MLD firmware flows, although the deflink is used, the mapping
of link ID to BSS configuration was missing, which causes flows that need
this mapping to crash.
Fix this by adding the link ID to BSS configuration mapping to non MLD
flows as well.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240311081938.0b5c361e8f0c.Ib11f41815d2efa5d1ec57f855de4c8563142987b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
- Store zone trips table and zone operations directly in struct
thermal_zone_device (Rafael Wysocki).
- Fix up flex array initialization during thermal zone device
registration (Nathan Chancellor).
- Rework writable trip points handling in the thermal core and
several drivers (Rafael Wysocki).
- Thermal core code cleanups (Dan Carpenter, Flavio Suligoi).
- Use thermal zone accessor functions in the int340x Intel thermal
driver (Rafael Wysocki).
- Add Lunar Lake-M PCI ID to the int340x Intel thermal driver (Srinivas
Pandruvada).
- Minor fixes for thermal governors (Rafael Wysocki, Di Shen).
- Trip point handling fixes for the iwlwifi wireless driver (Rafael
Wysocki).
- Code cleanups (Rafael J. Wysocki, AngeloGioacchino Del Regno).
-----BEGIN PGP SIGNATURE-----
iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAmXvJ0oSHHJqd0Byand5
c29ja2kubmV0AAoJEILEb/54YlRx63MQAIAzLFMzDqbG5bFq096tREuwtYhkQMq/
n3ZW+FhMfSr5MnGiTCelk/6auYvijMweylxrnfQM8ilIrSWVc2fNks6PTjI/hTe6
OUfF+nEAu+fv6I68p3evlI+IL7cncU1kygYhDRr6yxh5AFDn/BED/Klv8Ms0CkOi
YVk6+ZCsvkcC74Tvjm9+wDJZ7XHBqKXsYCyBKqxSBmMePc0FOqDGgji2d6Q8O9Ka
uITT9W4IhF9GNEV/ujUIrHVbfkUqJHn1sfJTOynG1Zp/MopA8mXAB2fWvkl4Kfd9
UvgHXZnBM4jFONlqHNlaV9mTiigMaKsgU1wfaSj7fgj8DELWGII0MQfC9kcUgvlJ
+qqmZ52tc8DKU3Lj6Wg58wgMTrI4XVAJjXwg9CTo65y6KyMuT1dkypnH95TdVtWl
qZJ9WdxAmAbCJqZzj10kn44HrF565/t0hShrjKvv+inzDyZ5jXMttK3TQS20REsC
MzoIxahlSUkN32OjiKhebrTNShzqFM6dxTDJLktMiInpgnnZJ/VG4Bao+NkSlLIJ
ZwTV1xOqZZarkPVMlrOijE1bs6HbomZ7ZEsDSxvtwp+MZ06G4ICY11/KbTw9IZFv
lCZiFNEzzxzrgqcz+5gS9y8/alknqiU5DSKCxfhbnNTW+Tk09mYPK5N0umUGwaTA
gQ4fWsBoTpZF
=Is/Y
-----END PGP SIGNATURE-----
Merge tag 'thermal-6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull thermal control updates from Rafael Wysocki:
"These mostly change the thermal core in a few ways allowing thermal
drivers to be simplified, in particular in their removal and failing
probe handling parts that are notoriously prone to errors, and
propagate the changes to several drivers.
Apart from that, support for a new platform is added (Intel Lunar
Lake-M), some bugs are fixed and some code is cleaned up, as usual.
Specifics:
- Store zone trips table and zone operations directly in struct
thermal_zone_device (Rafael Wysocki)
- Fix up flex array initialization during thermal zone device
registration (Nathan Chancellor)
- Rework writable trip points handling in the thermal core and
several drivers (Rafael Wysocki)
- Thermal core code cleanups (Dan Carpenter, Flavio Suligoi)
- Use thermal zone accessor functions in the int340x Intel thermal
driver (Rafael Wysocki)
- Add Lunar Lake-M PCI ID to the int340x Intel thermal driver
(Srinivas Pandruvada)
- Minor fixes for thermal governors (Rafael Wysocki, Di Shen)
- Trip point handling fixes for the iwlwifi wireless driver (Rafael
Wysocki)
- Code cleanups (Rafael J. Wysocki, AngeloGioacchino Del Regno)"
* tag 'thermal-6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (29 commits)
thermal: core: remove unnecessary check in trip_point_hyst_store()
thermal: intel: int340x_thermal: Use thermal zone accessor functions
thermal: core: Remove excess empty line from a comment
thermal: int340x: processor_thermal: Add Lunar Lake-M PCI ID
thermal: core: Eliminate writable trip points masks
thermal: of: Set THERMAL_TRIP_FLAG_RW_TEMP directly
thermal: imx: Set THERMAL_TRIP_FLAG_RW_TEMP directly
wifi: iwlwifi: mvm: Set THERMAL_TRIP_FLAG_RW_TEMP directly
mlxsw: core_thermal: Set THERMAL_TRIP_FLAG_RW_TEMP directly
thermal: intel: Set THERMAL_TRIP_FLAG_RW_TEMP directly
thermal: core: Drop the .set_trip_hyst() thermal zone operation
thermal: core: Add flags to struct thermal_trip
thermal: core: Move initial num_trips assignment before memcpy()
thermal: Get rid of CONFIG_THERMAL_WRITABLE_TRIPS
thermal: intel: Adjust ops handling during thermal zone registration
thermal: ACPI: Constify acpi_thermal_zone_ops
thermal: core: Store zone ops in struct thermal_zone_device
thermal: intel: Discard trip tables after zone registration
thermal: ACPI: Discard trips table after zone registration
thermal: core: Store zone trips table in struct thermal_zone_device
...
The fourth "new features" pull request for v6.9 with changes both in
stack and in drivers. The theme in this pull request is to fix sparse
warnings but we still have some left in wireless subsystem. Otherwise
quite normal.
Major changes:
rtw89
* NL80211_EXT_FEATURE_SCAN_RANDOM_SN support
* NL80211_EXT_FEATURE_SET_SCAN_DWELL support
rtw88
* support for more rtw8811cu and rtw8821cu devices
mt76
* mt76x2u: add Netgear WNDA3100v3 USB
* mt7915: newer ADIE version support
* mt7925: radio temperature sensor support
* mt7996: remove GCMP IGTK offload
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEiBjanGPFTz4PRfLobhckVSbrbZsFAmXq4hARHGt2YWxvQGtl
cm5lbC5vcmcACgkQbhckVSbrbZtOawf9Gf2FAi56zA/4vKJPE/mZzRvNodj/u9WL
mEX3KERw744IEmWY0yXEAyvzKkkNqUUtmdUbbsnXnnEtzsVZ2oRmOZdXsvEW3vOD
IEsjWY/405MBWyuBttAa6orBSgelr99k86HzoLN86s52HmliVDhr2EUnYIf2O++9
SVhHFKE4BMVCO6hlyEg419K9M2VhWtBDNYweoXAfn8Y1byAw6Pt6WunjRuGwJG5n
qvcrZcFCFSa3daPpx0uIA/yiSjZlq0hwVC3r/PnoX/r1FDR8tS2ecvC2rP3MaZJ+
1x3IcNvwC97D80wvdW+f+qKtV4OXZefsZpzJJpvREH8FbAgYLDef0Q==
=gln7
-----END PGP SIGNATURE-----
Merge tag 'wireless-next-2024-03-08' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Kalle Valo says:
====================
wireless-next patches for v6.9
The fourth "new features" pull request for v6.9 with changes both in
stack and in drivers. The theme in this pull request is to fix sparse
warnings but we still have some left in wireless subsystem. Otherwise
quite normal.
Major changes:
rtw89
* NL80211_EXT_FEATURE_SCAN_RANDOM_SN support
* NL80211_EXT_FEATURE_SET_SCAN_DWELL support
rtw88
* support for more rtw8811cu and rtw8821cu devices
mt76
* mt76x2u: add Netgear WNDA3100v3 USB
* mt7915: newer ADIE version support
* mt7925: radio temperature sensor support
* mt7996: remove GCMP IGTK offload
* tag 'wireless-next-2024-03-08' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (125 commits)
wifi: rtw89: wow: move release offload packet earlier for WoWLAN mode
wifi: rtw89: wow: set security engine options for 802.11ax chips only
wifi: rtw89: update suspend/resume for different generation
wifi: rtw89: wow: update config mac function with different generation
wifi: rtw89: update DMA function with different generation
wifi: rtw89: wow: update WoWLAN status register for different generation
wifi: rtw89: wow: update WoWLAN reason register for different chips
wifi: brcm80211: handle pmk_op allocation failure
wifi: rtw89: coex: Add coexistence policy to decrease WiFi packet CRC-ERR
wifi: rtw89: coex: When Bluetooth not available don't set power/gain
wifi: rtw89: coex: add return value to ensure H2C command is success or not
wifi: rtw89: coex: Reorder H2C command index to align with firmware
wifi: rtw89: coex: add BTC ctrl_info version 7 and related logic
wifi: rtw89: coex: add init_info H2C command format version 7
wifi: rtw89: 8922a: add coexistence helpers of SW grant
wifi: rtw89: mac: add coexistence helpers {cfg/get}_plt
wifi: cw1200: restore endian swapping
wifi: wlcore: sdio: Rate limit wl12xx_sdio_raw_{read,write}() failures warns
wifi: rtlwifi: Remove rtl_intf_ops.read_efuse_byte
wifi: rtw88: 8821c: Fix false alarm count
...
====================
Link: https://lore.kernel.org/r/20240308100429.B8EA2C433F1@smtp.kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Pass the link conf to the abort_channel_switch driver
method so the driver can handle things correctly.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240228095718.27f621106ddd.Iadd3d69b722ffe5934779a32a0e4e596a4e33ed4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In the operational statistics notifications (both old and new
API) the driver receives the statistics per phy.
currently this statistics wasn't handled because they wasn't needed.
Now the channel_load_by_us parameter in these statistics will be used
for the link grading calculation (implemented in another patch),
so store its value in phy_ctxt.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240218194912.e84f975b69ee.Ibbc7817135827e45adaaa47b796be165f9f1ca48@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
To support wider-bandwidth OFDMA we need to configure the
PHY context in the firmware, which will in turn configure
the DSP accordingly. Pass the relevant information down.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240218194912.ca666ede5dd6.I357972823d20e9045e2c97dbb7ac24fe9f5a6e41@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Those devices' fifos are numbered differently.
Because of that, we were looking at the size of the VO fifo size to
determine the size of the A-MSDU which led to a lower throughput.
Note that for those devices the only user of the AC -> fifo mapping is
the size limitation of A-MSDU.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240218194912.da336ca2fa0a.I73e44d5fc474ebb6f275b9008950e59c012f33b2@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is set when a P2P ROC ends, and uses as an indication inside
iwl_mvm_roc_done_wk that the resources used for this ROC (sta/link)
needs to be flushed/deactivated (respectively).
But we also have IWL_MVM_STATUS_ROC_RUNNING, which is set whenever
P2P ROC starts, and is not even used in iwl_mvm_roc_done_wk.
Use IWL_MVM_STATUS_ROC_RUNNING as an indicator, and remove the redundant
bit.
While at it, add a call to synchronize_net also for the
AUX ROC case, which is missing in the existing code.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240205211151.0494f75de311.Ic4aacacf7581a5c9046c4f1df87cbb67470853e7@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The flags argument to enable/disable beacon filtering functions
is unused and always zero, so just remove it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240206175739.2c739c1034a5.I8619949ad4ebd31593d10ece371ebdc6c48db98f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The client needs to disconnect from AP in case of more than 19 missed
beacons only if no data is coming from that AP, otherwise it needs to
stay connected.
Signed-off-by: Daniel Amosi <amosi.daniel@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240205211151.080195242c18.Ib166fc4e46666165a88e673a4a196cb8f18fdec4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In much of the PHY context handling code the chandef
coming from mac80211 is read-only, mark them const
to make that clearer.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240204235836.e7fbd3e26d85.I72d72e61dc5f5fc76c53e32cb60b66237eaedec3@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
