- 06 May, 2024 20 commits
-
-
Miri Korenblit authored
Start supporting API version 90 for new devices. Signed-off-by:
Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240506095953.4e4b19128b56.I2f9196191f1ea78e96e92f9db8ecb3cc9bbfd9b3@changeidSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Miri Korenblit authored
mvmvif::primary link holds the ID and not a bitmap. Fix this Fixes: 07bf5297 ("wifi: iwlwifi: mvm: Implement new link selection algorithm") Signed-off-by:
-
Johannes Berg authored
In iwl_mvm_rs_fw_rate_init() we have a variable cmd_id that holds the command ID, so we can just use that instead of the various calculations of it. Signed-off-by:
-
Johannes Berg authored
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:
-
Daniel Gabay authored
This is useful for debug instead of looking for the hex value. Signed-off-by:
Daniel Gabay <daniel.gabay@intel.com> Signed-off-by:
-
Yedidya Benshimol authored
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 authored
Change EMSLR to EMLSR Fixes: 6cf7df9f ("wifi: iwlwifi: mvm: Add helper functions to update EMLSR status") Signed-off-by:
-
Johannes Berg authored
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:
-
Yedidya Benshimol authored
Enable EMLSR when bandwidth settings meet the criteria in both band and width, otherwise disable. Signed-off-by:
-
Miri Korenblit authored
The new link selection algorithm uses defaults values for BSS load if the BSS Load element was not published by the AP. For 6 GHz, that value is 0. So if the best link is 6 GHz, the EMLSR grade to always be equal to the grade of the best link, and then the best link grade is getting a bonus of 10 percent, meaning that we will never activate EMLSR. Change the logic to not give a bonus for the best link. Signed-off-by:
-
Miri Korenblit authored
When non default TTLM is applied, mac80211 may force us to use a specific link (For example, if the only active link becomes a dormant link, mac80211 will pick the first usable link and set it as active). When default TTLM is applied, we have new usable links that we might want to select. Therefore, trigger MLO scan and link selection upon change in TTLM. Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Link: https://msgid.link/20240505091420.ed2b386566a8.I0168e61da86b2027633743aaf5d97e483991f0dc@changeidSigned-off-by:
-
Miri Korenblit authored
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 authored
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 authored
When an event occurs to unblock EMLSR, the code attempts to re-enable EMLSR. However, the current implementation always tries to activate EMLSR, regardless of whether the blocker was set before the unblocking event or not. If EMLSR was already unblocked, there is no need to re-activate it. Fixes: 6cf7df9f ("wifi: iwlwifi: mvm: Add helper functions to update EMLSR status") Signed-off-by:
-
Miri Korenblit authored
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 authored
This is needed for testing purposes. Signed-off-by:
-
Miri Korenblit authored
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 authored
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:
-
Johannes Berg authored
Given how late we are in the cycle, merge the two fixes from wireless into wireless-next as they don't see that urgent. This way, the wireless tree won't need rebasing later. Signed-off-by: -
https://github.com/pkshih/rtwKalle Valo authored
rtw-next patches for v6.10 Major changes are listed as below rtl8xxxu: - remove rtl8xxxu_ prefix from filename - cleanup includes of header files rtlwifi: - adjust code to share with coming support of rtl8192du rtw89: - complete features of new WiFi 7 chip 8922AE including BT-coexistence and WoWLAN - use BIOS ACPI settings to set TX power and channels
-
- 04 May, 2024 11 commits
-
-
Ping-Ke Shih authored
le32p_replace_bits() only updates partial bits of rate_mask, and GCC warns below. Set initial value to avoid warnings, and prevent random value of missed bits (bit 6 of rate_mask.macid_and_short_gi). In file included from ./include/linux/fortify-string.h:5, from ./include/linux/string.h:369, from ./include/linux/bitmap.h:13, from ./include/linux/cpumask.h:13, from ./include/linux/sched.h:16, from drivers/net/wireless/realtek/rtlwifi/rtl8192d/../wifi.h:9, from drivers/net/wireless/realtek/rtlwifi/rtl8192d/hw_common.c:4: In function 'le32p_replace_bits', inlined from 'rtl92de_update_hal_rate_mask.isra' at drivers/net/wireless/realtek/rtlwifi/rtl8192d/hw_common.c:986:2: ./include/linux/bitfield.h:189:15: warning: 'rate_mask' is used uninitialized [-Wuninitialized] 189 | *p = (*p & ~to(field)) | type##_encode_bits(val, field); \ | ^~ ./include/linux/bitfield.h:196:9: note: in expansion of macro '____MAKE_OP' 196 | ____MAKE_OP(le##size,u##size,cpu_to_le##size,le##size##_to_cpu) \ | ^~~~~~~~~~~ ./include/linux/bitfield.h:201:1: note: in expansion of macro '__MAKE_OP' 201 | __MAKE_OP(32) | ^~~~~~~~~ drivers/net/wireless/realtek/rtlwifi/rtl8192d/hw_common.c: In function 'rtl92de_update_hal_rate_mask.isra': drivers/net/wireless/realtek/rtlwifi/rtl8192d/hw_common.c:863:37: note: 'rate_mask' declared here 863 | struct rtl92d_rate_mask_h2c rate_mask; | ^~~~~~~~~ Compile tested only. Fixes: 014bba73 ("wifi: rtlwifi: Adjust rtl8192d-common for USB") Cc: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by:Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240504111916.31445-1-pkshih@realtek.com
-
Gustavo A. R. Silva authored
Wflex-array-member-not-at-end is coming in GCC-14, and we are getting ready to enable it globally. So, remove unused structs and fix the following -Wflex-array-member-not-at-end warnings: drivers/net/wireless/realtek/rtlwifi/btcoexist/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/rtl8188ee/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/rtl8192c/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/rtl8192ce/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/rtl8192cu/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/rtl8192de/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/rtl8192ee/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/rtl8192se/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/rtl8723ae/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/rtl8723be/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/rtl8723com/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/rtl8821ae/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Acked-by:
-
Ping-Ke Shih authored
aSIFSTime is 10us for 2GHz band and 16us for 5GHz and 6GHz bands. Originally, it doesn't consider 6GHz band and use wrong value, so correct it accordingly. Cc: stable@vger.kernel.org Signed-off-by:
-
Chin-Yen Lee authored
Add H2C command and offload template packet to allow firmware send ARP response in WoWLAN mode. Then, firmware in WoWLAN mode can interactive with peer that issue ARP request to query MAC address. Signed-off-by:
Chin-Yen Lee <timlee@realtek.com> Signed-off-by:
-
Chih-Kang Chang authored
When using the WEP cipher, we need to add the address cam type as all unicast mode to let firmware to work. Although WEP only set GTK in mac80211, but we need to set both PTK and GTK information to firmware. Signed-off-by:
Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by:
-
Chih-Kang Chang authored
Once we connect to AP with 802.11w enabled, IGTK rekey happen during GTK happen. We get IGTK IPN from mac80211 and set to firmware, and get latest IGTK IPN from AOAC report then update to mac80211 after resume. When rekey happen, also update new IGTK key info to mac80211. Furthermore, We construct SA query reply packet to firmware. If firmware received SA query request from AP can transmit reply back when suspend. Signed-off-by:
-
Chih-Kang Chang authored
When resume we parse AOAC report from firmware using H2C and C2H registers before enable interrupt, then update PTK RX PN and GTK RX PN. After enable interrupt, we parse AOAC report using H2C and C2H commands, then update PTK TX PN and update new GTK key info if GTK rekey during suspend. Furthermore, We update pattern match index if wakeup by pattern. Signed-off-by:
-
Chih-Kang Chang authored
Add PTK TRX IV, GTK RX IV, key encryption algorithm to H2C command to enable GTK rekey feature. Signed-off-by:
-
Chih-Kang Chang authored
We construct EAPoL packet with various encryption method, and download to firmware. Also we add Key Encryption Key (KEK) and Key Confirmation Key (KCK) to H2C command. Once firmware received EAPoL group rekey packet(1/2) can TX EAPoL group rekey packet(2/2) when suspend. Signed-off-by:
-
Chih-Kang Chang authored
This H2C command is used to set WoWLAN global config, and we correct the H2C format by enlarging the H2C size to fill GTK and PTK info. This fix is compatible with old firmware. Signed-off-by:
-
Chih-Kang Chang authored
This H2C command set key information into security CAM including key index, entry index and valid map. No logic is changed. Signed-off-by:
-
- 03 May, 2024 9 commits
-
-
Chih-Kang Chang authored
Get the PTK and PTK TRX PN value and transfer to IV value, these values will used by firmware to generate packets with correct IV value. Signed-off-by:
-
Chih-Kang Chang authored
Need Auth Key Management(AKM) to let firmware to generate appropriate EAPoL packet for GTK rekey. The AKM is present in the association request RSN IE to indicate which cipher that station selected. Signed-off-by:
-
Chih-Kang Chang authored
After enabling packet offload, the TX will be stuck after resume from WoWLAN mode. And the 8852c gets error messages like rtw89_8852ce 0000:04:00.0: No busy txwd pages available rtw89_8852ce 0000:04:00.0: queue 0 txwd 100 is not idle rtw89_8852ce 0000:04:00.0: queue 0 txwd 101 is not idle rtw89_8852ce 0000:04:00.0: queue 0 txwd 102 is not idle rtw89_8852ce 0000:04:00.0: queue 0 txwd 103 is not idle If suspend/resume many times that firmware will download failed and disconnection. To fix these issues, We removed the rtw89_hci_disable_intr() and rtw89_hci_enable_intr() during rtw89_wow_swap_fw() to prevent add packet offload can't receive c2h back due to interrupt disable. Only 8852C and 8922A needs to disable interrupt before downloading fw. Furthermore, we avoid using low power HCI mode on WoWLAN mode, to prevent interrupt enabled, then get interrupt and calculate RXBD mismatched due to software RXBD index already reset but hardware RXBD index not yet. Fixes: 5c12bb66 ("wifi: rtw89: refine packet offload flow") Signed-off-by:
-
Chin-Yen Lee authored
802.11be WiFi chips need a RFK (RF calibration) notify H2C command after downloading WoWLAN firmware to make sure RF TX/RX work fine when leaving power save mode, so add it to correct RF TX/RX in WoWLAN mode. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/athKalle Valo authored
ath.git patches for v6.10 ath12k * debugfs support * dfs_simulate_radar debugfs file * disable Wireless Extensions * suspend and hibernation support * ACPI support * refactoring in preparation of multi-link support ath11k * support hibernation (required changes in qrtr and MHI subsystems) * ieee80211-freq-limit Device Tree property support ath10k * firmware-name Device Tree property support
-
https://github.com/nbd168/wirelessKalle Valo authored
mt76 patches for 6.10 - fixes - mt7603 stability improvements - mt7921 LED control - mt7925 EHT radiotap support
-
Aditya Kumar Singh authored
Advertise support for BSS color and then once the countdown reaches 0, call color change finish. Signed-off-by:
Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240422053412.2024075-8-quic_adisi@quicinc.comSigned-off-by:
-
Aditya Kumar Singh authored
In order to support color change with MLO, handle the link ID now passed from cfg80211, adjust the code to do everything per link and call the notifications to cfg80211 correctly. Signed-off-by:
-
Aditya Kumar Singh authored
Currently, during color change, no link id information is passed down. In order to support color change during Multi Link Operation, it is required to pass link id as well. Additionally, update notification APIs to allow drivers/mac80211 to pass the link ID. Signed-off-by:
-
