kernel/drivers/net/wireless/realtek, branch linux-6.9.y

wifi: rtw89: fw: scan offload prohibit all 6 GHz channel if no 6 GHz sband

2024-07-11T10:50:56Z

[ Upstream commit bb38626f3f97e16e6d368a9ff6daf320f3fe31d9 ] We have some policy via BIOS to block uses of 6 GHz. In this case, 6 GHz sband will be NULL even if it is WiFi 7 chip. So, add NULL handling here to avoid crash. Signed-off-by: Zong-Zhe Yang Signed-off-by: Ping-Ke Shih Link: https://msgid.link/20240412115729.8316-3-pkshih@realtek.com Signed-off-by: Sasha Levin

wifi: rtw89: download firmware with five times retry

2024-07-05T07:37:59Z

[ Upstream commit a9e1b0ec5bdeedcf062416af4081aa005f8bf1e7 ] After firmware boots, it reads keys info from efuse and checks secure checksum, but suddenly failed to access efuse resulting in probe failure, and driver throws messages: rtw89_8852be 0000:03:00.0: fw security fail rtw89_8852be 0000:03:00.0: download firmware fail rtw89_8852be 0000:03:00.0: [ERR]fwdl 0x1E0 = 0xe2 rtw89_8852be 0000:03:00.0: [ERR]fwdl 0x83F0 = 0x210090 Retry five times to resolve rare abnormal hardware state. Signed-off-by: Chia-Yuan Li Signed-off-by: Ping-Ke Shih Link: https://msgid.link/20240329015251.22762-2-pkshih@realtek.com Signed-off-by: Sasha Levin

wifi: rtw89: 8852c: add quirk to set PCI BER for certain platforms

2024-06-27T11:52:13Z

[ Upstream commit 5b919d726b613c78d4dc463dd9f90c55843fd1b3 ] Increase PCI BER (bit error rate) count depth setting which could increase PHY circuit fault tolerance and improve compatibility. Signed-off-by: Ping-Ke Shih Link: https://msgid.link/20240329015251.22762-4-pkshih@realtek.com Signed-off-by: Sasha Levin

wifi: rtlwifi: Ignore IEEE80211_CONF_CHANGE_RETRY_LIMITS

2024-06-21T12:40:31Z

commit 819bda58e77bb67974f94dc1aa11b0556b6f6889 upstream. Since commit 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers") ieee80211_hw_config() is no longer called with changed = ~0. rtlwifi relied on ~0 in order to ignore the default retry limits of 4/7, preferring 48/48 in station mode and 7/7 in AP/IBSS. RTL8192DU has a lot of packet loss with the default limits from mac80211. Fix it by ignoring IEEE80211_CONF_CHANGE_RETRY_LIMITS completely, because it's the simplest solution. Link: https://lore.kernel.org/linux-wireless/cedd13d7691f4692b2a2fa5a24d44a22@realtek.com/ Cc: stable@vger.kernel.org # 6.9.x Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://msgid.link/1fabb8e4-adf3-47ae-8462-8aea963bc2a5@gmail.com Signed-off-by: Greg Kroah-Hartman

wifi: rtlwifi: rtl8192de: Fix endianness issue in RX path

2024-06-16T11:50:58Z

commit 2f228d364da95ab58f63a3fedc00d5b2b7db16ab upstream. Structs rx_desc_92d and rx_fwinfo_92d will not work for big endian systems. Delete rx_desc_92d because it's big and barely used, and instead use the get_rx_desc_rxmcs and get_rx_desc_rxht functions, which work on big endian systems too. Fix rx_fwinfo_92d by duplicating four of its members in the correct order. Tested only with RTL8192DU, which will use the same code. Tested only on a little endian system. Cc: stable@vger.kernel.org Signed-off-by: Bitterblue Smith Signed-off-by: Ping-Ke Shih Link: https://msgid.link/698463da-5ef1-40c7-b744-fa51ad847caf@gmail.com Signed-off-by: Greg Kroah-Hartman

wifi: rtlwifi: rtl8192de: Fix low speed with WPA3-SAE

2024-06-16T11:50:58Z

commit a7c0f48410f546772ac94a0f7b7291a15c4fc173 upstream. Some (all?) management frames are incorrectly reported to mac80211 as decrypted when actually the hardware did not decrypt them. This results in speeds 3-5 times lower than expected, 20-30 Mbps instead of 100 Mbps. Fix this by checking the encryption type field of the RX descriptor. rtw88 does the same thing. This fix was tested only with rtl8192du, which will use the same code. Cc: stable@vger.kernel.org Signed-off-by: Bitterblue Smith Signed-off-by: Ping-Ke Shih Link: https://msgid.link/4d600435-f0ea-46b0-bdb4-e60f173da8dd@gmail.com Signed-off-by: Greg Kroah-Hartman

wifi: rtlwifi: rtl8192de: Fix 5 GHz TX power

2024-06-16T11:50:57Z

commit de4d4be4fa64ed7b4aa1c613061015bd8fa98b24 upstream. Different channels have different TX power settings. rtl8192de is using the TX power setting from the wrong channel in the 5 GHz band because _rtl92c_phy_get_rightchnlplace expects an array which includes all the channel numbers, but it's using an array which includes only the 5 GHz channel numbers. Use the array channel_all (defined in rtl8192de/phy.c) instead of the incorrect channel5g (defined in core.c). Tested only with rtl8192du, which will use the same TX power code. Cc: stable@vger.kernel.org Signed-off-by: Bitterblue Smith Signed-off-by: Ping-Ke Shih Link: https://msgid.link/c7653517-cf88-4f57-b79a-8edb0a8b32f0@gmail.com Signed-off-by: Greg Kroah-Hartman

wifi: rtl8xxxu: enable MFP support with security flag of RX descriptor

2024-06-16T11:50:57Z

commit cbfbb4ddbc8503478e0a138f9a31f61686cc5f11 upstream. In order to connect to networks which require 802.11w, add the MFP_CAPABLE flag and let mac80211 do the actual crypto in software. When a robust management frame is received, rx_dec->swdec is not set, even though the HW did not decrypt it. Extend the check and don't set RX_FLAG_DECRYPTED for these frames in order to use SW decryption. Use the security flag in the RX descriptor for this purpose, like it is done in the rtw88 driver. Cc: stable@vger.kernel.org Signed-off-by: Martin Kaistra Signed-off-by: Ping-Ke Shih Link: https://msgid.link/20240418071813.1883174-3-martin.kaistra@linutronix.de Signed-off-by: Greg Kroah-Hartman

wifi: rtl8xxxu: Fix the TX power of RTL8192CU, RTL8723AU

2024-06-16T11:50:57Z

commit 08b5d052d17a89bb8706b2888277d0b682dc1610 upstream. Don't subtract 1 from the power index. This was added in commit 2fc0b8e5a17d ("rtl8xxxu: Add TX power base values for gen1 parts") for unknown reasons. The vendor drivers don't do this. Also correct the calculations of values written to REG_OFDM0_X{C,D}_TX_IQ_IMBALANCE. According to the vendor driver, these are used for TX power training. With these changes rtl8xxxu sets the TX power of RTL8192CU the same as the vendor driver. None of this appears to have any effect on my RTL8192CU device. Cc: stable@vger.kernel.org Signed-off-by: Bitterblue Smith Reviewed-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://msgid.link/6ae5945b-644e-45e4-a78f-4c7d9c987910@gmail.com Signed-off-by: Greg Kroah-Hartman

wifi: rtw89: pci: correct TX resource checking for PCI DMA channel of firmware command

2024-06-16T11:50:57Z

commit c6330b129786e267b14129335a08fa7c331c308d upstream. The DMA channel of firmware command doesn't use TX WD (WiFi descriptor), so don't need to consider number of TX WD as factor of TX resource. Otherwise, during pause state (a transient state to switch to/from low power mode) firmware commands could be dropped and driver throws warnings suddenly: rtw89_8852ce 0000:04:00.0: no tx fwcmd resource rtw89_8852ce 0000:04:00.0: failed to send h2c The case we met is that driver sends RSSI strength of firmware command at RX path that could be running concurrently with switching low power mode. The missing of this firmware command doesn't affect user experiences, because the RSSI strength will be updated again after a while. The DMA descriptors of normal packets has three layers like: +-------+ | TX BD | (*n elements) +-------+ | | +-------+ +-> | TX WD | (*m elements) +-------+ | | +--------+ +-> | SKB | +--------+ And, firmware command queue (TXCH 12) is a special queue that has only two layers: +-------+ | TX BD | (*n elements) +-------+ | | +------------------+ +-> | firmware command | +------------------+ Fixes: 4a29213cd775 ("wifi: rtw89: pci: correct TX resource checking in low power mode") Cc: stable@vger.kernel.org Signed-off-by: Ping-Ke Shih Link: https://msgid.link/20240410011316.9906-1-pkshih@realtek.com Signed-off-by: Greg Kroah-Hartman