[PATCH AUTOSEL 6.6 19/62] wifi: rtw89: leave idle mode when setting WEP encryption for AP mode

[Sasha Levin <sashal@kernel.org>]

From: Dian-Syuan Yang <dian_syuan0116@realtek.com>

[ Upstream commit d105652b33245162867ac769bea336976e67efb8 ]

Due to mac80211 triggering the hardware to enter idle mode, it fails
to install WEP key causing connected station can't ping successfully.
Currently, it forces the hardware to leave idle mode before driver
adding WEP keys.

Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250507031203.8256-1-pkshih@realtek.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

**YES** This commit should be backported to stable kernel trees. Here's
my extensive analysis: ## Bug Fix Analysis **Real User-Affecting Bug**:
The commit fixes a clear functional issue where WEP encryption key
installation fails in AP mode when the rtw89 wireless device is in idle
mode. This directly impacts users trying to establish WEP-encrypted
connections to an AP, causing authentication failures and preventing
network connectivity. **Specific Technical Problem**: When mac80211 puts
the hardware into idle mode (IPS - Idle Power Save), the rtw89
firmware/hardware enters a low-power state where key installation
operations fail. This is particularly problematic for WEP encryption
which appears to have specific hardware state requirements. ## Code
Change Analysis **Minimal and Targeted**: The fix adds exactly two lines
of code: ```c case WLAN_CIPHER_SUITE_WEP40:
rtw89_leave_ips_by_hwflags(rtwdev); // NEW hw_key_type =
RTW89_SEC_KEY_TYPE_WEP40; break; case WLAN_CIPHER_SUITE_WEP104:
rtw89_leave_ips_by_hwflags(rtwdev); // NEW hw_key_type =
RTW89_SEC_KEY_TYPE_WEP104; break; ``` **Uses Existing Infrastructure**:
The fix leverages the existing `rtw89_leave_ips_by_hwflags()` function,
which is a well-tested mechanism already used throughout the driver for
similar power management scenarios. **WEP-Specific Requirement**:
Notably, other cipher types (TKIP, CCMP, GCMP) don't require this call,
indicating WEP has unique hardware state dependencies - likely due to
its legacy implementation requiring specific firmware states. ## Risk
Assessment **Very Low Risk**: - The `rtw89_leave_ips_by_hwflags()`
function only acts when the hardware is actually in idle mode
(`IEEE80211_CONF_IDLE` flag set) - It's a conditional safety mechanism
that doesn't affect normal operation - Limited scope - only affects
WEP40/WEP104 cipher types - Follows established patterns already present
in the driver **No Architectural Changes**: This is purely a bug fix
that ensures hardware is in the correct state before performing WEP key
operations. ## Stable Tree Criteria Compliance **Meets All Stable
Requirements**: 1. ✅ **Important bug fix**: Resolves WEP authentication
failures in AP mode 2. ✅ **Small and contained**: Two identical function
calls in a switch statement 3. ✅ **Obviously correct**: Uses existing,
proven power management infrastructure 4. ✅ **Low regression risk**:
Conservative fix affecting only legacy WEP encryption 5. ✅ **User-
visible impact**: Fixes network connectivity issues ## Comparison with
Historical Commits Looking at the similar commits provided, this follows
the same pattern as other rtw88/rtw89 power management fixes that were
marked as "NO" for backporting. However, those commits were primarily
optimizations or behavior changes during scanning operations, not fixes
for broken functionality. This commit differs because: - It fixes a
**broken feature** (WEP key installation failure) - It's not an
optimization or behavioral change - It has direct user-visible impact
(connection failures) - It's a minimal, surgical fix for a specific
failure mode ## Conclusion This is a textbook example of a commit
suitable for stable backporting: it fixes a real bug affecting users,
uses minimal and safe code changes, and follows established driver
patterns. The fix ensures WEP encryption works properly in AP mode by
guaranteeing the hardware is powered up during key installation
operations.

 drivers/net/wireless/realtek/rtw89/cam.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtw89/cam.c b/drivers/net/wireless/realtek/rtw89/cam.c
index f5301c2bbf133..9a0ffaddb8360 100644
--- a/drivers/net/wireless/realtek/rtw89/cam.c
+++ b/drivers/net/wireless/realtek/rtw89/cam.c
@@ -6,6 +6,7 @@
 #include "debug.h"
 #include "fw.h"
 #include "mac.h"
+#include "ps.h"
 
 static struct sk_buff *
 rtw89_cam_get_sec_key_cmd(struct rtw89_dev *rtwdev,
@@ -333,9 +334,11 @@ int rtw89_cam_sec_key_add(struct rtw89_dev *rtwdev,
 
 	switch (key->cipher) {
 	case WLAN_CIPHER_SUITE_WEP40:
+		rtw89_leave_ips_by_hwflags(rtwdev);
 		hw_key_type = RTW89_SEC_KEY_TYPE_WEP40;
 		break;
 	case WLAN_CIPHER_SUITE_WEP104:
+		rtw89_leave_ips_by_hwflags(rtwdev);
 		hw_key_type = RTW89_SEC_KEY_TYPE_WEP104;
 		break;
 	case WLAN_CIPHER_SUITE_CCMP:
-- 
2.39.5