summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
AgeCommit message (Collapse)Author
2024-07-03wifi: iwlwifi: mvm: check vif for NULL/ERR_PTR before dereferenceMiri Korenblit
iwl_mvm_get_bss_vif might return a NULL or ERR_PTR. Some of the callers check only the NULL case, and some doesn't check at all. Some of the callers even have a pointer to the mvmvif of the bss vif, so we don't even need to call this function, and can simply get the vif from mvmvif. Do it for those cases, and for the others - properly check if IS_ERR_OR_NULL Fixes: ec0d43d26f2c ("wifi: iwlwifi: mvm: Activate EMLSR based on traffic volume") Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240703064027.a661f8c65aac.I45cf09b01af8ee3d55828863958ead741ea43b7f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-07-03wifi: iwlwifi: mvm: don't wake up rx_sync_waitq upon RFKILLEmmanuel Grumbach
Since we now want to sync the queues even when we're in RFKILL, we shouldn't wake up the wait queue since we still expect to get all the notifications from the firmware. Fixes: 4d08c0b3357c ("wifi: iwlwifi: mvm: handle BA session teardown in RF-kill") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240703064027.be7a9dbeacde.I5586cb3ca8d6e44f79d819a48a0c22351ff720c9@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-07-03wifi: iwlwifi: properly set WIPHY_FLAG_SUPPORTS_EXT_KEK_KCKDaniel Gabay
The WIPHY_FLAG_SUPPORTS_EXT_KEK_KCK should be set based on the WOWLAN_KEK_KCK_MATERIAL command version. Currently, the command version in the firmware has advanced to 4, which prevents the flag from being set correctly, fix that. Signed-off-by: Daniel Gabay <daniel.gabay@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240703064026.a0f162108575.If1a9785727d2a1b0197a396680965df1b53d4096@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-06-28wifi: mac80211: remove DEAUTH_NEED_MGD_TX_PREPJohannes Berg
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>
2024-06-27Merge tag 'wireless-next-2024-06-27' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== Highlights this time are: - cfg80211/nl80211: * improvements for 6 GHz regulatory flexibility - mac80211: * use generic netdev stats * multi-link improvements/fixes - brcmfmac: * MFP support (to enable WPA3) - wilc1000: * suspend/resume improvements - iwlwifi: * remove support for older FW for new devices * fast resume (keeping the device configured) - wl18xx: * support newer firmware versions * tag 'wireless-next-2024-06-27' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (100 commits) wifi: brcmfmac: of: Support interrupts-extended wifi: brcmsmac: advertise MFP_CAPABLE to enable WPA3 net: rfkill: Correct return value in invalid parameter case wifi: mac80211: fix NULL dereference at band check in starting tx ba session wifi: iwlwifi: mvm: fix rs.h kernel-doc wifi: iwlwifi: fw: api: datapath: fix kernel-doc wifi: iwlwifi: fix remaining mistagged kernel-doc comments wifi: iwlwifi: fix prototype mismatch kernel-doc warnings wifi: iwlwifi: fix kernel-doc in iwl-fh.h wifi: iwlwifi: fix kernel-doc in iwl-trans.h wifi: iwlwifi: pcie: fix kernel-doc wifi: iwlwifi: dvm: fix kernel-doc warnings wifi: iwlwifi: mvm: don't log error for failed UATS table read wifi: iwlwifi: trans: make bad state warnings wifi: iwlwifi: fw: api: fix some kernel-doc wifi: iwlwifi: mvm: remove init_dbg module parameter wifi: iwlwifi: update the BA notification API wifi: iwlwifi: mvm: always unblock EMLSR on ROC end wifi: iwlwifi: mvm: use IWL_FW_CHECK for link ID check wifi: iwlwifi: mvm: don't flush BSSes on restart with MLD API ... ==================== Link: https://patch.msgid.link/20240627114135.28507-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-06-26wifi: iwlwifi: remove MVM prefix from scan APIDaniel Gabay
These are not MVM specific. Signed-off-by: Daniel Gabay <daniel.gabay@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240625194805.09f672318944.Idffeab6a4dfc12effebd1c50815ae5c540afca74@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-06-26wifi: iwlwifi: mvm: don't limit VLP/AFC to UATS-enabledJohannes Berg
When UATS isn't enabled (no VLP/AFC AP support), we need to still set the right bits in the channel/regulatory flags, so remove the uats_enabled argument to the parsing etc. Also, firmware deals just fine with getting the UATS table if it supports the command even if the bits aren't set, so always send it, since it's also needed if BIT(31) is set, but the driver need not have any knowledge of that. Remove 'uats_enabled' entirely. Fixes: 0d2fc8821a7d ("wifi: iwlwifi: nvm: parse the VLP/AFC bit from regulatory") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240618195731.a81e7234c4f6.Ic0131180d38e0f1ead2f7fa0e7583407ceaa0bd1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-06-26wifi: iwlwifi: mvm: dissolve iwl_mvm_mac_remove_interface_common()Johannes Berg
Since the function isn't actually common (any more), just dissolve it. 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.adf54ab5bc4a.I90339f152bba73b622e05063d16ae914ae20053f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-06-26wifi: iwlwifi: support fast resumeEmmanuel Grumbach
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>
2024-06-26wifi: iwlwifi: mvm: unify and fix interface combinationsJohannes Berg
AP interfaces fundamentally cannot leave the channel, so multi- channel operation with them isn't really possible. We shouldn't advertise support for such, at least not as long as we don't have full multi-radio support. Thus, remove the AP bit from the interface combinations for two channels and add another set for just one channel that has it. Also, to avoid duplicating everything even more, unify the NAN and non-NAN cases. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240618200104.3213638262ef.I2a0031b37623d7763fd0c5405477ea7206a3e923@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-06-26wifi: mac80211: inform the low level if drv_stop() is a suspendEmmanuel Grumbach
This will allow the low level driver to take different actions for different flows. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240618192529.739036208b6e.Ie18a2fe8e02bf2717549d39420b350cfdaf3d317@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-06-20Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR. Conflicts: drivers/net/ethernet/broadcom/bnxt/bnxt.c 1e7962114c10 ("bnxt_en: Restore PTP tx_avail count in case of skb_pad() error") 165f87691a89 ("bnxt_en: add timestamping statistics support") No adjacent changes. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-06-12wifi: iwlwifi: mvm: use ROC for P2P device activitiesShaul Triebitz
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>
2024-06-12wifi: iwlwifi: mvm: separate non-BSS/ROC EMLSR blockingJohannes Berg
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: a1efeb823084 ("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>
2024-06-12wifi: iwlwifi: remove struct iwl_trans_opsYedidya Benshimol
This was needed when we had multiple types of transports. Now we only have pcie, so there is no need for this ops. Cleanup the code such as the different trans APIs will call the pcie function directly, instead of calling the callback, and remove struct iwl_trans_ops. Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240605140327.8315ff64f9f3.Ifdbc1f26d49766f7de553dcb5f613885f4ee65cc@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-06-12wifi: iwlwifi: mvm: fix ROC version checkShaul Triebitz
For using the ROC command, check that the ROC version is *greater or equal* to 3, rather than *equal* to 3. The ROC version was added to the TLV starting from version 3. Fixes: 67ac248e4db0 ("wifi: iwlwifi: mvm: implement ROC version 3") Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240605140327.93d86cd188ad.Iceadef5a2f3cfa4a127e94a0405eba8342ec89c1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-06-10Merge tag 'wireless-next-2024-06-07' of ↵Jakub Kicinski
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>
2024-05-29wifi: iwlwifi: mvm: handle BA session teardown in RF-killJohannes Berg
When entering RF-kill, mac80211 tears down BA sessions, but due to RF-kill the commands aren't sent to the device. As a result, there can be frames pending on the reorder buffer or perhaps even received while doing so, leading to warnings. Avoid the warnings by doing the BA session teardown normally even in RF-kill, which also requires queue sync. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240513132416.0762cd80fb3d.I43c5877f3b546159b2db4f36d6d956b333c41cf0@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-05-29wifi: iwlwifi: mvm: remove stale STA link data during restartBenjamin Berg
If pre-recovery mac80211 tried to disable a link but this disablement failed, then there might be a mismatch between mac80211 assuming the link has been disabled and the driver still having the data around. During recover itself, that is not a problem, but should the link be activated again at a later point, iwlwifi will refuse the activation as it detects the inconsistent state. Solve this corner-case by iterating the station in the restart cleanup handler. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240513132416.d2fd60338055.I840d4fdce5fd49fe69896d928b071067e3730259@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-05-29wifi: iwlwifi: mvm: handle TPE advertised by APJohannes Berg
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>
2024-05-29wifi: iwlwifi: mvm: move a constant to constants.hMiri Korenblit
Move IWL_MVM_MIN_BEACON_INTERVAL_TU to constants.h Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240527190228.395f5b24ff82.Id78a5a404c3ae15cbbc950b1f1d7e500a8b92a43@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-05-23wifi: iwlwifi: move code from iwl-eeprom-parse to dvmEmmanuel Grumbach
Move code that is DVM only to dvm. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240512152312.9a1b6ef116e0.I217a513f544d5288a7760d265f51419e81abfd9d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-05-23wifi: iwlwifi: mvm: add mvm-specific guardJohannes Berg
Add and use an mvm-specific guard for the mvm mutex. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240512152312.7391425b3af2.I1b109f56753dd3f35602dd2c5cf6e1e35aee313d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-05-06wifi: iwlwifi: mvm: record and return channel survey informationBenjamin Berg
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>
2024-05-06wifi: iwlwifi: mvm: Fix race in scan completionIlan Peer
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: 07bf5297d392 ("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>
2024-05-06wifi: iwlwifi: mvm: don't reset link selection during restartJohannes Berg
After restart, we might want to end up with the same config as before, even for multi-link/EMLSR. Therefore, don't reset the stored link selection result in that case. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240505091420.e81db303f1dc.Ie8267082f623d14376a2052d222e18da6545f34b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-05-06wifi: iwlwifi: mvm: Block EMLSR when a p2p/softAP vif is activeYedidya Benshimol
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>
2024-05-06wifi: iwlwifi: mvm: exit EMLSR when CSA happensJohannes Berg
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>
2024-05-06wifi: iwlwifi: mvm: consider FWs recommendation for EMLSRMiri Korenblit
FW sends a notification indicating whether activating EMLSR mode is recommended or not. Support the notification and enter EMLSR only if recommended. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240505091420.2fd3387882eb.I7a8a5b24658744ed732bfc03b1872c9298483d62@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-05-06wifi: iwlwifi: mvm: Activate EMLSR based on traffic volumeMiri Korenblit
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>
2024-05-06wifi: iwlwifi: mvm: trigger link selection after exiting EMLSRMiri Korenblit
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>
2024-05-06wifi: iwlwifi: cleanup EMLSR when BT is active handlingMiri Korenblit
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>
2024-04-19wifi: iwlwifi: mvm: get periodic statistics in EMLSRMiri Korenblit
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>
2024-04-19wifi: iwlwifi: mvm: implement EMLSR prevention mechanism.Miri Korenblit
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>
2024-04-19wifi: iwlwifi: mvm: init vif works only onceJohannes Berg
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: f67806140220 ("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>
2024-04-19wifi: iwlwifi: mvm: Implement new link selection algorithmMiri Korenblit
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>
2024-04-19wifi: iwlwifi: mvm: calculate EMLSR mode after connectionMiri Korenblit
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>
2024-04-03Merge tag 'wireless-next-2024-04-03' of ↵Jakub Kicinski
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>
2024-03-25wifi: iwlwifi: mvm: set wider BW OFDMA ignore correctlyJohannes Berg
Clearly, I put this flag into the wrong place: devices using the code in mac80211.c only do not support EHT, so this isn't even relevant. Fix this by moving the code to the right function. Fixes: 32a5690e9acb ("wifi: iwlwifi: mvm: support wider-bandwidth OFDMA") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240320232419.0d5fb0e971e4.I3b67c5e0ddcbe6e58143ec0bc4e40dd6dba4f863@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-25wifi: iwlwifi: mvm: mark EMLSR disabled in cleanup iteratorBenjamin Berg
During HW restart only one link will be active initially and other links are only activated again later on. With only a single link EMLSR cannot be enabled and having it marked enabled confuses the internal state. Mark EMLSR as disabled in the cleanup iterator, it can be reenabled later one once this is possible. 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/20240320232419.71eb622d6ce3.Ic4d50695b9bb332190dc712473096083aa96074b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-25wifi: iwlwifi: mvm: don't support puncturing in 5 GHzJohannes Berg
This is simply not supported, so set the flag for it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240319100755.f61448c4a43a.Ib740b341af0ca6c3e06cc9a0b04447a6635df7a8@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-25wifi: iwlwifi: mvm: support iwl_dev_tx_power_cmd_v8Emmanuel Grumbach
This just adds a __le32 that we (currently) don't use. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240319100755.29ff7a88ddac.I39cf2ff1d1ddf0fa62722538698dc7f21aaaf39e@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-25wifi: iwlwifi: mvm: Introduce internal MLO passive scanIlan Peer
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>
2024-03-25wifi: iwlwifi: mvm: advertise IEEE80211_HW_HANDLES_QUIET_CSAJohannes Berg
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>
2024-03-25wifi: iwlwifi: mvm: fix flushing during quiet CSAJohannes Berg
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>
2024-03-25wifi: iwlwifi: mvm: Move beacon filtering to be per linkIlan Peer
As the FW statistics are per link context and not per MAC context. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240311081938.47bdecc68e73.Icc0eaebb35d119f8c538c068fbc8f874aac194c3@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-25wifi: iwlwifi: mvm: Configure the link mapping for non-MLD FWIlan Peer
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>
2024-03-25wifi: iwlwifi: mvm: disable MLO for the time beingJohannes Berg
MLO ended up not really fully stable yet, we want to make sure it works well with the ecosystem before enabling it. Thus, remove the flag, but set WIPHY_FLAG_DISABLE_WEXT so we don't get wireless extensions back until we enable MLO for this hardware. Cc: stable@vger.kernel.org Reviewed-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240314110951.d6ad146df98d.I47127e4fdbdef89e4ccf7483641570ee7871d4e6@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-03-04wifi: mac80211: pass link conf to abort_channel_switchJohannes Berg
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>
2024-02-21wifi: iwlwifi: mvm: support wider-bandwidth OFDMAJohannes Berg
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>
generated by cgit (git 2.34.1) at 2025-07-05 16:44:35 +0000