Replace the ifdef CONFIG_PM by CONFIG_PM_SLEEP. CONFIG_PM was useful
when we had CONFIG_PM_RUNTIME but that was removed long ago.
Use PM_SLEEP consistently across the driver.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240825191257.44e47ba584de.I64f985d0405345252b76b7157291b79677abd64d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When a channel ctx is assigned to a link, we set the
LINK_CONTEXT_MODIFY_RATES_INFO to indicate that the rate fields are now
valid. But then we always take the rates of 2.4 GHz regardless of actual
used band.
This is because we are getting the band from bss_conf->chanctx_conf, but
this is assigned only after drv_assign_vif_chanctx returns, so we take
the bands of 2.4 GHz.
Fix it by taking the band from the iwl_mvm_link_info::phy_ctxt instead,
as this has already assigned in this point.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20240901071542.11c2d3609609.I8fa59e29b6bb38e5d06f3536d54dfb2c5d5bab11@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When we de-activate a link because it started a CSA with mode=1, we want
to tell the firmware it can no longer transmit any frame for that link.
The firmware will do that on its own if the CSA indication (beacon /
action frame) was received on that same link, but with MLO, things got
more complex and the firmware can't track cross link CSA.
Tell the firmware if we de-activate a link because of CSA with mode=1 to
prevent it from transmitting, even if it is only an NDP PM=1 frame that
is part of the de-activation flow.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240901071542.4bef89d438d4.If7147a7a84054e67c05414c753d73f4e2e0e6e37@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This used to extract the timeout from the debug TLV
(FW_DBG_TRIGGER_TXQ_TIMERS), which is not in use.
Cleanup iwl_mvm_get_wd_timeout to not consider the debug TLV.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20240808232017.7a6944bc2e38.I532b4b5487c6be9203ff4db9742d7cc5b148d502@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Use the same handler for both types and just convert the old version to
the new. Drop the unused fields from the old one and fake the new
fields.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240808232017.a64ffc998569.I7d181052b1a69c331d07263f20c1e00cbc0bc891@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently, the driver handles SMPS decisions by tracking AP
capabilities, BT coexistence changes, sending necessary SMPS
frames to the AP, and updating firmware with RX chain info
using the RLC_CONFIG_CMD.
Starting with version 3 of the RLC_CONFIG_CMD, the firmware
takes over this responsibility. It now tracks SMPS, sends
frames, and configures the RLC.
In this patch:
1. Stop sending RLC_CONFIG_CMD when firmware supports RLC
offload (version 3), as rlc.rx_chain_info is not needed by
firmware, and no other field in the cmd is used.
2. Prevent the driver from forwarding any SMPS requests to
mac80211, i.e., the driver should not transmit SMPS frames
to the AP as firmware handles that.
3. Set NL80211_FEATURE_DYNAMIC_SMPS and NL80211_FEATURE_STATIC_SMPS
conditionally based on RLC version.
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240808232017.45da23be1f65.I0d46db82dd990a82e8a66876fe2f5310bc9513be@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We have a new notification the BT profile. It contains almost nothing,
only the wifi loss information. Copy this into mvm. We still need to
iterate over the vifs / links to use this data.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240729201718.637499f3a85a.I8bf654cf5d8aa038100273876c936845ecc338f7@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The iwl_bt_coex_profile_notif is now being obsoleted. It'll be replaced
by a new notification coming with a non-legacy group. Rename it to avoid
confusion.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240729201718.dc29fd0d7817.I5881fce86ec8b76ae98d2948265434b8e7d860c1@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The entries[] array needs to be cacheline aligned to avoid false
sharing between different queues, each queue has a set of entries
in it that it writes to.
While it is aligned in practice today given that each array entry
before it is aligned, it's still clearer to explicitly require it
to be aligned, so add the annotation for that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240703125541.3bc7a55ac867.Id3c1df6d40e92c3de9caededcbc32d0e57e4423d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We really don't need to maintain the buffer size per
queue buffer, it's the same for the whole BA session.
Also, we no longer use the mvm pointer inside each
queue's data structure. Clean that up.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240703125541.64ea1ba75379.I2a25af040061efaf82379e96a84a76c5fb65c677@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This flag is annoying because it puts a lot of logic into mac80211
that could just as well be in the driver (only iwlmvm uses it) and
the implementation is also broken for MLO.
Remove the flag in favour of calling drv_mgd_prepare_tx() without
any conditions even for the deauth-while-assoc case. The drivers
that implement it can take the appropriate actions, which for the
only user of DEAUTH_NEED_MGD_TX_PREP (iwlmvm) is a bit more tricky
than the implementation in mac80211 is anyway, and all others have
no need and can just exit if info->was_assoc is set.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240627132527.94924bcc9c9e.I328a219e45f2e2724cd52e75bb9feee3bf21a463@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fix all the prototype mismatch and "wrong kernel-doc identifier"
warnings, due to typos in or misformatting of the kernel-doc.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240625194805.6ec65cf9b88c.I7804114d7369f352e80a0e8430f7119af8e210de@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The lookup function iwl_mvm_rcu_fw_link_id_to_link_conf() is
normally called with input from the firmware, so it should use
IWL_FW_CHECK() instead of WARN_ON().
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240625194805.4ea8fb7c47d4.I1c22af213f97f69bfc14674502511c1bc504adfb@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
PLDR (product level device reset) is a Windows term, and
is something the driver triggers there, AFAICT.
Really what 'pldr_sync' here wants to capture is whether
or not the firmware will/may do a product reset during
initialization, which makes the device drop off the bus,
requiring a rescan. If this is the case, obviously the
init will fail/time out, so we don't want to report all
kinds of errors etc., hence this tracking variable.
Rename it to 'fw_product_reset' to capture the meaning
better.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240618194245.ccf849642af8.I01dded6b2393771b7baf8b4b17336784d987c7c2@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This will allow to suspend / resume the system without resetting the
firmware. This will allow to reduce the resume time.
In case the fast_resume fails, stop the device and bring it up from
scratch.
Raise the timeout for the D3_END notification since in some iterations,
it took 240ms.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240618194245.03b8d2801044.I613d17c712de7a0d611cde4e14f37ebbe0c3c964@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fix incorrect use of _tx_ valid ant data in the function.
Fixes: 4ea1ed1d14 ("wifi: iwlwifi: mvm: support set_antenna()")
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240618200104.b7c6a320c7dc.I3092eb5275056f2162b9694e583c310c38568b2a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is the first step towards removing the P2P Device MAC.
Use ROC (which uses the AUX MAC) for P2P Device
discoveribility and action frames.
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240605140556.8c90e457abbd.I8e340759ecb299e05b1809f3d8060429c6cbbd01@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If non-BSS and remain-on-channel (ROC) blocking were to occur
simultaneously, they'd step on each other's toes, unblocking
when not yet supported. Disentangle these bits, and ROC doesn't
need to use the non_bss_link() function then.
Fixes: a1efeb8230 ("wifi: iwlwifi: mvm: Block EMLSR when a p2p/softAP vif is active")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240605140556.461fcf7b95bb.Id0d21dcb739d426ff15ec068b5df8abaab58884d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The first "new features" pull request for v6.11 with changes both in
stack and in drivers. Nothing out of ordinary, except that we have two
conflicts this time:
CONFLICT (content): Merge conflict in net/mac80211/cfg.c
CONFLICT (content): Merge conflict in drivers/net/wireless/microchip/wilc1000/netdev.c
Here are Stephen's resolutions for them:
https://lore.kernel.org/all/20240531124415.05b25e7a@canb.auug.org.au/https://lore.kernel.org/all/20240603110023.23572803@canb.auug.org.au/
Major changes:
cfg80211/mac80211
* parse Transmit Power Envelope (TPE) data in mac80211 instead of in drivers
wilc1000
* read MAC address during probe to make it visible to user space
iwlwifi
* bump FW API to 91 for BZ/SC devices
* report 64-bit radiotap timestamp
* Enable P2P low latency by default
* handle Transmit Power Envelope (TPE) advertised by AP
* start using guard()
rtlwifi
* RTL8192DU support
ath12k
* remove unsupported tx monitor handling
* channel 2 in 6 GHz band support
* Spatial Multiplexing Power Save (SMPS) in 6 GHz band support
* multiple BSSID (MBSSID) and Enhanced Multi-BSSID Advertisements (EMA) support
* dynamic VLAN support
* add panic handler for resetting the firmware state
ath10k
* add qcom,no-msa-ready-indicator Device Tree property
* LED support for various chipsets
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEiBjanGPFTz4PRfLobhckVSbrbZsFAmZi07URHGt2YWxvQGtl
cm5lbC5vcmcACgkQbhckVSbrbZu3/QgAo7jyKgvpwMaNIVRLyfYCo0r3Q9wb7QPd
QeRNsftYxlWpPTJ4+Y95aZupy91Ay+RaEQXbbtl7PMIiyQrs7wb4V4Iqzedkws3t
DZsR5BitH+1BIGY0Omo0fiSB5HlWEwZGUj6inqlgKHpBtdIVTANSMjuwkdoMAV5y
ZU57axIGToySvDbRlhJQW833Nnh4KnaseA+TtyfXSaBVerzbshkjBr0d9pMBMiH9
irMQW5CW+7fbxp3OCNsKxX4eG6MFGmm/uP1hFmeYQi2qzUE4SddHMeV4I6oNKOrH
vFB+ZVmYvOjJUYsNhlCUe6Vy+EKwvmfiDWwE1egelEkgozCixJXAAQ==
=QT4C
-----END PGP SIGNATURE-----
Merge tag 'wireless-next-2024-06-07' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Kalle Valo says:
====================
wireless-next patches for v6.11
The first "new features" pull request for v6.11 with changes both in
stack and in drivers. Nothing out of ordinary, except that we have
two conflicts this time:
net/mac80211/cfg.c
https://lore.kernel.org/all/20240531124415.05b25e7a@canb.auug.org.au
drivers/net/wireless/microchip/wilc1000/netdev.c
https://lore.kernel.org/all/20240603110023.23572803@canb.auug.org.au
Major changes:
cfg80211/mac80211
* parse Transmit Power Envelope (TPE) data in mac80211 instead of in drivers
wilc1000
* read MAC address during probe to make it visible to user space
iwlwifi
* bump FW API to 91 for BZ/SC devices
* report 64-bit radiotap timestamp
* enable P2P low latency by default
* handle Transmit Power Envelope (TPE) advertised by AP
* start using guard()
rtlwifi
* RTL8192DU support
ath12k
* remove unsupported tx monitor handling
* channel 2 in 6 GHz band support
* Spatial Multiplexing Power Save (SMPS) in 6 GHz band support
* multiple BSSID (MBSSID) and Enhanced Multi-BSSID Advertisements (EMA)
support
* dynamic VLAN support
* add panic handler for resetting the firmware state
ath10k
* add qcom,no-msa-ready-indicator Device Tree property
* LED support for various chipsets
* tag 'wireless-next-2024-06-07' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (194 commits)
wifi: ath12k: add hw_link_id in ath12k_pdev
wifi: ath12k: add panic handler
wifi: rtw89: chan: Use swap() in rtw89_swap_sub_entity()
wifi: brcm80211: remove unused structs
wifi: brcm80211: use sizeof(*pointer) instead of sizeof(type)
wifi: ath12k: do not process consecutive RDDM event
dt-bindings: net: wireless: ath11k: Drop "qcom,ipq8074-wcss-pil" from example
wifi: ath12k: fix memory leak in ath12k_dp_rx_peer_frag_setup()
wifi: rtlwifi: handle return value of usb init TX/RX
wifi: rtlwifi: Enable the new rtl8192du driver
wifi: rtlwifi: Add rtl8192du/sw.c
wifi: rtlwifi: Constify rtl_hal_cfg.{ops,usb_interface_cfg} and rtl_priv.cfg
wifi: rtlwifi: Add rtl8192du/dm.{c,h}
wifi: rtlwifi: Add rtl8192du/fw.{c,h} and rtl8192du/led.{c,h}
wifi: rtlwifi: Add rtl8192du/rf.{c,h}
wifi: rtlwifi: Add rtl8192du/trx.{c,h}
wifi: rtlwifi: Add rtl8192du/phy.{c,h}
wifi: rtlwifi: Add rtl8192du/hw.{c,h}
wifi: rtlwifi: Add new members to struct rtl_priv for RTL8192DU
wifi: rtlwifi: Add rtl8192du/table.{c,h}
...
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
====================
Link: https://lore.kernel.org/r/20240607093517.41394C2BBFC@smtp.kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In beacon template version 14, make sure to always set
the TWT IE offset before sending the beacon template command,
also in the debugfs inject_beacon_ie path.
If the TWT IE does not exist, the offset will be set to zero.
Fixes: bf0212fd8f ("wifi: iwlwifi: mvm: add beacon template version 14")
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240512152312.eb27175c345a.If30ef24aba10fe47fd42a7a9703eb8903035e294@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
6 GHz BSS SP client shall respect TX power limits advertised
by the AP in TPE elements, send the data to the firmware using
the AP_TX_POWER_CONSTRAINTS_CMD command, so do that.
Co-developed-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240527190228.32f1e2e1447c.I58ac91c38585362aa42bb4a8a59c7d88e67bc40b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add a debugfs option to use the ptp clock time for rx device
timestamps. This can be useful to e.g. synchronize multiple NICs or
reporting the timestamp in the system clock instead of gp2.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240527190228.b197b4f3f9ed.I578ee916d5f517a2e3a89e890a8ea24065946427@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We track which link is using which FW link ID, so there
really isn't a need to separately track which link IDs
are in use. Remove that code and check the table when
looking for a new link ID to use.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240512072733.1a67d8af815f.Ie642c12dce3ab55c688abd9a25918569e83e558a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add an entry for setting the maximum TXOP time in microseconds.
The configured value can be read from the same entry.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240510170500.b8d17a9c1731.I57c33574a61edd68bd0ec1aa7009f31111fd7efe@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
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>