- 06 May, 2024 27 commits
-
-
Daniel Gabay authored
Firmware 0x2F7 assert observed in Dell platforms when using GL HW. This issue is mitigated by setting SCU_FORCE_ACTIVE during platform low power states. Driver shall indicate firmware to force SCU active by setting bit 29 in context info prph scratch control flags. This mitigation is limited to Dell platforms with GL HW only. Signed-off-by:
Daniel Gabay <daniel.gabay@intel.com> Reviewed-by:
Ofer Kimelman <ofer.kimelman@intel.com> Signed-off-by:
Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240506095953.3d0c56c2bb1a.I97d9da402890d2085b5698666cceffc417b6b6df@changeidSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Benjamin Berg authored
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:
-
Benjamin Berg authored
When requested, the firmware can return per-channel survey information generally used for ACS (automatic channel selection). Add the API for this, which consists of a flag and a new channel survey notification. Signed-off-by:
-
Ilan Peer authored
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: 07bf5297 ("wifi: iwlwifi: mvm: Implement new link selection algorithm") Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
-
Yedidya Benshimol authored
When validating a link pair for EMLSR, add a print for invalid link pair due to bandwidth Signed-off-by:
Yedidya Benshimol <yedidya.ben.shimol@intel.com> Signed-off-by:
-
Yedidya Benshimol authored
Add a reading for all active EMLSR blocking reasons for testing purposes. Signed-off-by:
-
Yedidya Benshimol authored
Upon adding/removing an EMLSR blocking reason add to the print the EMLSR disabling mask Signed-off-by:
-
Miri Korenblit authored
Start supporting API version 90 for new devices. Signed-off-by:
-
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:
-
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:
-
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:
-
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 2 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:
-
