summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek
AgeCommit message (Collapse)Author
2024-07-11wifi: rtw89: fw: scan offload prohibit all 6 GHz channel if no 6 GHz sbandZong-Zhe Yang
[ 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 <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240412115729.8316-3-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-07-05wifi: rtw89: download firmware with five times retryChia-Yuan Li
[ 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 <leo.li@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240329015251.22762-2-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-27wifi: rtw89: 8852c: add quirk to set PCI BER for certain platformsPing-Ke Shih
[ 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 <pkshih@realtek.com> Link: https://msgid.link/20240329015251.22762-4-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-21wifi: rtlwifi: Ignore IEEE80211_CONF_CHANGE_RETRY_LIMITSBitterblue Smith
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 <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/1fabb8e4-adf3-47ae-8462-8aea963bc2a5@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-16wifi: rtlwifi: rtl8192de: Fix endianness issue in RX pathBitterblue Smith
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 <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/698463da-5ef1-40c7-b744-fa51ad847caf@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-16wifi: rtlwifi: rtl8192de: Fix low speed with WPA3-SAEBitterblue Smith
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 <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/4d600435-f0ea-46b0-bdb4-e60f173da8dd@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-16wifi: rtlwifi: rtl8192de: Fix 5 GHz TX powerBitterblue Smith
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 <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/c7653517-cf88-4f57-b79a-8edb0a8b32f0@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-16wifi: rtl8xxxu: enable MFP support with security flag of RX descriptorMartin Kaistra
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 <martin.kaistra@linutronix.de> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240418071813.1883174-3-martin.kaistra@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-16wifi: rtl8xxxu: Fix the TX power of RTL8192CU, RTL8723AUBitterblue Smith
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 <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/6ae5945b-644e-45e4-a78f-4c7d9c987910@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-16wifi: rtw89: pci: correct TX resource checking for PCI DMA channel of ↵Ping-Ke Shih
firmware command 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 <pkshih@realtek.com> Link: https://msgid.link/20240410011316.9906-1-pkshih@realtek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-16wifi: rtw89: correct aSIFSTime for 6GHz bandPing-Ke Shih
commit f506e3ee547669cd96842e03c8a772aa7df721fa upstream. 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: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240430020515.8399-1-pkshih@realtek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-30wifi: rtw89: wow: refine WoWLAN flows of HCI interrupts and low power modeChih-Kang Chang
[ Upstream commit baaf806e4632a259cc959fd1c516c2d9ed48df6d ] 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: 5c12bb66b79d ("wifi: rtw89: refine packet offload flow") Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240502022505.28966-3-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-14wifi: rtw89: coex: fix configuration for shared antenna for 8922APing-Ke Shih
WiFi 2x2 + BT combo cards can be two or three physical antenna. For two antenna case, one antenna is shared by WiFi and BT, and different configuration should be applied. Fix the typo. This problem was found by Coccicheck, and actually that is a typo instead: rtw8922a.c:2235:2-4: WARNING: possible condition with no effect (if == else) Fixes: 652c9642eda6 ("wifi: rtw89: coex: add init_info H2C command format version 7") Closes: https://lore.kernel.org/linux-wireless/20240308074539.04512f66@kernel.org/ Cc: Ching-Te Ku <ku920601@realtek.com> Cc: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240309001348.9906-1-pkshih@realtek.com
2024-03-05wifi: rtw89: wow: move release offload packet earlier for WoWLAN modeChin-Yen Lee
Now WoWLAN firmware will disable PCIE DMA after driver call cfg_wake function, and it will lead to release offload packet fail because driver can't receive completion notification from firmware. We move release offload packet earlier to avoid this error. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240302005828.13666-8-pkshih@realtek.com
2024-03-05wifi: rtw89: wow: set security engine options for 802.11ax chips onlyChin-Yen Lee
The security engine is set for management frames by default for 802.11be chips, so no need to set it in WoWLAN flow. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240302005828.13666-7-pkshih@realtek.com
2024-03-05wifi: rtw89: update suspend/resume for different generationChin-Yen Lee
The setting during suspend or resume is different between different generation, so update it. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240302005828.13666-6-pkshih@realtek.com
2024-03-05wifi: rtw89: wow: update config mac function with different generationChin-Yen Lee
The registers to configure mac function for WoWLAN mode that are different from different generation, so update them. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240302005828.13666-5-pkshih@realtek.com
2024-03-05wifi: rtw89: update DMA function with different generationChin-Yen Lee
The register of control and polling function for TX/RX DMA is different from different generation, so update them. Also rename polling_dma function to polling_dma_idle to avoid misunderstanding. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240302005828.13666-4-pkshih@realtek.com
2024-03-05wifi: rtw89: wow: update WoWLAN status register for different generationChin-Yen Lee
The statue register is for driver to check if WoWLAN mode works or stops successfully. It is changed for new generation, so update it. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240302005828.13666-3-pkshih@realtek.com
2024-03-05wifi: rtw89: wow: update WoWLAN reason register for different chipsChin-Yen Lee
The WoWLAN reason register is used for driver to get the wakeup reason for reporting to cfg80211, and it is different from chips. So put it into chip information. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240302005828.13666-2-pkshih@realtek.com
2024-03-05wifi: rtw89: coex: Add coexistence policy to decrease WiFi packet CRC-ERRChing-Te Ku
The 2 Bluetooth profiles (Hands free profile & Human interface device) have high duty transmission, it will affect the traffic of WiFi packet frequently. And once the WiFi traffic down to B/G mode, it will need a better success rate to recover the transmission rate. Add new policy option to solve the above situation. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240229074514.219276-9-pkshih@realtek.com
2024-03-05wifi: rtw89: coex: When Bluetooth not available don't set power/gainChing-Te Ku
If Bluetooth is working, it will update their info regularly. And the code will increase the counters while the info updating. Use this counter to judge is Bluetooth working or not. Don't need to set Bluetooth power or gain when it is not working. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240229074514.219276-8-pkshih@realtek.com
2024-03-05wifi: rtw89: coex: add return value to ensure H2C command is success or notChing-Te Ku
Add return value to H2C function, and only record down the value while H2C command success, this can help us to check the real time status. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240229074514.219276-7-pkshih@realtek.com
2024-03-05wifi: rtw89: coex: Reorder H2C command index to align with firmwareChing-Te Ku
Wi-Fi firmware need some driver information to do decision or do some real-time control. Driver will update these information by H2C command. The chip 8922a H2C command index is different from before chips/branch, so need to assign the correct index to let firmware parsing. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240229074514.219276-6-pkshih@realtek.com
2024-03-05wifi: rtw89: coex: add BTC ctrl_info version 7 and related logicChing-Te Ku
Change structure member from bit field to normal variable to reduce unnecessary translation. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240229074514.219276-5-pkshih@realtek.com
2024-03-05wifi: rtw89: coex: add init_info H2C command format version 7Ching-Te Ku
To avoid using bit fields for H2C command, rearrange the structure. And also patch the corresponding code for the using of this structure. No logic changes for existing chips. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240229074514.219276-4-pkshih@realtek.com
2024-03-05wifi: rtw89: 8922a: add coexistence helpers of SW grantPing-Ke Shih
Under some circumstances, coexistence mechanism want to keep grant BT or WiFi, such as inquiry and WiFi is connecting, to ensure BT or WiFi can transmit or receive data in that period. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240229074514.219276-3-pkshih@realtek.com
2024-03-05wifi: rtw89: mac: add coexistence helpers {cfg/get}_pltPing-Ke Shih
When hardware grant BT initially but transition to grant WiFi, the PLT (polluted) bit is set to assist coexistence mechanism to debug if grant signal is expected. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240229074514.219276-2-pkshih@realtek.com
2024-03-05wifi: rtlwifi: Remove rtl_intf_ops.read_efuse_byteBitterblue Smith
PCI drivers and USB drivers can both use the same function, read_efuse_byte(), and they can call it directly. rtl8192de was the only user. Tested only with the upcoming rtl8192du driver. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/4e2c968d-f25c-4a40-be97-4fdcbdde69cf@gmail.com
2024-03-05wifi: rtw88: 8821c: Fix false alarm countBitterblue Smith
total_fa_cnt is supposed to include cck_fa_cnt and ofdm_fa_cnt, not just ofdm_fa_cnt. Fixes: 960361238b86 ("rtw88: 8821c: add false alarm statistics") Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/f3cb6d17-e4e4-44a7-9c9b-72aed994b5c9@gmail.com
2024-03-05wifi: rtw88: 8821c: Fix beacon loss and disconnectBitterblue Smith
Tenda U9 V2.0, which contains RTL8811CU, is practically unusable because of frequent disconnections: Feb 23 14:46:45 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-BEACON-LOSS Feb 23 14:46:46 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-DISCONNECTED bssid=90:55:de:__:__:__ reason=4 locally_generated=1 Feb 23 14:46:52 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-CONNECTED - Connection to 90:55:de:__:__:__ completed [id=0 id_str=] Feb 23 14:46:54 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-BEACON-LOSS Feb 23 14:46:55 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-DISCONNECTED bssid=90:55:de:__:__:__ reason=4 locally_generated=1 Feb 23 14:47:01 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-CONNECTED - Connection to 90:55:de:__:__:__ completed [id=0 id_str=] Feb 23 14:47:04 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-BEACON-LOSS Feb 23 14:47:05 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-DISCONNECTED bssid=90:55:de:__:__:__ reason=4 locally_generated=1 This is caused by a mistake in the chip initialisation. This version of the chip requires loading an extra AGC table right after the main one, but the extra table is being loaded at the wrong time, in rtw_chip_board_info_setup(). Move the extra AGC table loading to the right place, in rtw_phy_load_tables(). The rtw_chip_board_info_setup() can only do "software" things, and rtw_phy_load_tables() can really do IO. Fixes: 5d6651fe8583 ("rtw88: 8821c: support RFE type2 wifi NIC") Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/276c31d8-b9a8-4e54-a3ac-09b74657aff7@gmail.com
2024-03-05wifi: rtw88: 8821cu: Fix connection failureBitterblue Smith
Clear bit 8 of REG_SYS_STATUS1 after MAC power on. Without this, some RTL8821CU and RTL8811CU cannot connect to any network: Feb 19 13:33:11 ideapad2 kernel: wlp3s0f3u2: send auth to 90:55:de:__:__:__ (try 1/3) Feb 19 13:33:13 ideapad2 kernel: wlp3s0f3u2: send auth to 90:55:de:__:__:__ (try 2/3) Feb 19 13:33:14 ideapad2 kernel: wlp3s0f3u2: send auth to 90:55:de:__:__:__ (try 3/3) Feb 19 13:33:15 ideapad2 kernel: wlp3s0f3u2: authentication with 90:55:de:__:__:__ timed out The RTL8822CU and RTL8822BU out-of-tree drivers do this as well, so do it for all three types of chips. Tested with RTL8811CU (Tenda U9 V2.0). Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/aeeefad9-27c8-4506-a510-ef9a9a8731a4@gmail.com
2024-03-05wifi: rtw88: 8821cu: Fix firmware upload failBitterblue Smith
RTL8822CU, RTL8822BU, and RTL8821CU need an extra register write after reading and writing certain addresses. Without this, the firmware upload fails approximately more than 50% of the time. Tested with RTL8811CU (Tenda U9 V2.0) which is the same as RTL8821CU but without Bluetooth. Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support") Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/f12ed39d-28e8-4b8b-8d22-447bcf295afc@gmail.com
2024-03-05wifi: rtw88: Add missing VID/PIDs for 8811CU and 8821CUNick Morrow
Add VID/PIDs that are known to be missing for this driver. Removed /* 8811CU */ and /* 8821CU */ as they are redundant since the file is specific to those chips. Removed /* TOTOLINK A650UA v3 */ as the manufacturer. It has a REALTEK VID so it may not be specific to this adapter. Verified and tested. Cc: stable@vger.kernel.org Signed-off-by: Nick Morrow <morrownr@gmail.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/4ume7mjw63u7.XlMUvUuacW2ErhOCdqlLkw2@1EHFQ.trk.elasticemail.com
2024-02-28wifi: rtl8xxxu: fix mixed declarations in rtl8xxxu_set_aifs()Shiji Yang
Moving struct ieee80211_sta *sta variable definition to the front of the code to fix the ISO C90 forbids mixed declarations and code warning. Fixes: 43532c050f8e ("wifi: rtl8xxxu: support multiple interfaces in set_aifs()") Signed-off-by: Shiji Yang <yangshiji66@outlook.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/TYAP286MB03157A408E0D69F2F6FBD88ABC552@TYAP286MB0315.JPNP286.PROD.OUTLOOK.COM
2024-02-27wifi: rtw89: pci: implement PCI CLK/ASPM/L1SS for WiFi 7 chipsChin-Yen Lee
PCI CLK/ASPM/L1SS is power management mechanism used to reduce power consumption of PCI chip. The registers for setting of these features in WiFi 7 Chip are different from WiFi 6 chip, so separate them in generation information. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240222064258.59782-4-pkshih@realtek.com
2024-02-27wifi: rtw89: Update EHT PHY beamforming capabilityKuan-Chung Chen
Adjust beamforming capabilities to accurately reflect the supported EHT features by WiFi 7 chip 8922A. It includes 1) Unset EHT CQI feedback and 16-subcarrier grouping. 2) Correct Beamformee SS value. 3) Enable partial and full bandwidth SU/MU feedback. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240222064258.59782-3-pkshih@realtek.com
2024-02-27wifi: rtw89: advertise missing extended scan featureKuan-Chung Chen
Add support for random serial number in probe request and configure channel dwell time. Advertise corresponding feature flag NL80211_EXT_FEATURE_SCAN_RANDOM_SN and NL80211_EXT_FEATURE_SET_SCAN_DWELL. Use the scan request duration as channel dwell time when it is non-zero, otherwise use the default value. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240222064258.59782-2-pkshih@realtek.com
2024-02-21wifi: rtlwifi: set initial values for unexpected cases of USB endpoint priorityPing-Ke Shih
Map USB endpoints to hardware and AC queues according to number of USB endpoints. However, original only give a warning for unexpected cases but initial values are not given. Then, smatch warns: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c:642 _rtl92cu_init_chipn_two_out_ep_priority() error: uninitialized symbol 'valuelow'. drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c:644 _rtl92cu_init_chipn_two_out_ep_priority() error: uninitialized symbol 'valuehi'. drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c:649 _rtl92cu_init_chipn_two_out_ep_priority() error: uninitialized symbol 'valuehi'. drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c:650 _rtl92cu_init_chipn_two_out_ep_priority() error: uninitialized symbol 'valuelow'. The regular selection is high and low queues, so move default (unexpected) case along with that. Compile tested only. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240216033949.34765-1-pkshih@realtek.com
2024-02-21wifi: rtl8xxxu: check vif before using in rtl8xxxu_tx()Ping-Ke Shih
The 'vif' is from tx_info of SKB, and other codes check 'vif' before using, which raises smatch warnings: drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:5656 rtl8xxxu_tx() warn: variable dereferenced before check 'vif' (see line 5553) Compile tested only. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240216033923.34683-1-pkshih@realtek.com
2024-02-21wifi: rtlwifi: rtl8192cu: Fix TX aggregationBitterblue Smith
rtl8192cu is checking rtl_mac.tids when deciding if it should enable aggregation. This is wrong because rtl_mac.tids is not initialised anywhere. Check rtl_sta_info.tids instead, which is initialised. Also, when enabling aggregation also enable RTS. The vendor driver does this, my router does this. It seems like the thing to do. Also also, it seems right to set the AMPDU density only when enabling aggregation. Also also also, delete the unused member rtl_mac.tids and the unused macros RTL_AGG_ON and RTL_AGG_OFF. Naturally, with working AMPDU the download/upload speeds are better. Before: 59/32 Mbps. After: 68/46 Mbps. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/4e936334-5f81-403f-a495-0628ebfb6903@gmail.com
2024-02-21wifi: mac80211: check beacon countdown is complete on per link basisAditya Kumar Singh
Currently, function to check if beacon countdown is complete uses deflink to fetch the beacon and check the counter. However, with MLO, there is a need to check the counter for the beacon in a particular link. Add support to use link_id in order to fetch the beacon from a particular link data. Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240216144621.514385-2-quic_adisi@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-19wifi: rtw89: 8922a: add helper of set_channelPing-Ke Shih
Reset hardware state to prevent hardware stays at abnormal state during setting channel. Besides, add preparation for MLO/DBCC before setting channel, and reconfigure registers after that. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240215055741.14148-5-pkshih@realtek.com
2024-02-19wifi: rtw89: 8922a: add set_channel RF partPing-Ke Shih
Configure RF registers according to band, channel, bandwidth. Since this chip will support MLO, it needs check the operating mode to decide paths we are going to configure. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240215055741.14148-4-pkshih@realtek.com
2024-02-19wifi: rtw89: 8922a: add set_channel BB partPing-Ke Shih
In additional to configure band, channel and bandwidth registers, it also configure CCK support on 2GHZ band, spur elimination, and RX gain. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240215055741.14148-3-pkshih@realtek.com
2024-02-19wifi: rtw89: 8922a: add set_channel MAC partPing-Ke Shih
To set channel, add a function to get TXSB (TX subband) that is hardware index to indicate primary channel. Then, configure band, channel, bandwidth and TXSB via registers. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240215055741.14148-2-pkshih@realtek.com
2024-02-15wifi: rtlwifi: rtl_usb: Store the endpoint addressesBitterblue Smith
And use the stored addresses in rtl8192cu instead of hardcoding them. This is what the vendor drivers do. Perhaps this is not strictly necessary for RTL8192CU devices. However, the dual mac version of RTL8192DU has two USB interfaces, each with its own set of endpoints. Hardcoding their addresses in the upcoming rtl8192du driver would require making some assumptions which I'm not qualified to make. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/7b6a602a-6101-4bab-958d-bcff4d565b40@gmail.com
2024-02-15wifi: rtlwifi: rtl8192cu: Fix 2T2R chip type detectionBitterblue Smith
rtl8192cu handles 1T1R devices (RTL8188CUS), 1T2R devices (RTL8191CU), and 2T2R devices (RTL8192CU). The 2T2R devices were incorrectly detected as 1T2R because of a mistake in the IS_92C_1T2R macro. The visible effect of this is that the firmware was allowed to use TX rates only up to MCS7. Fix the IS_92C_1T2R macro. Now my 2T2R device has much better upload speed. Before: 46 Mbps. After: 82 Mbps. Also fix a debug message which was printing "RF_1T1R" even for 1T2R chips. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/ed960059-5c77-422d-ac4e-fe9fc9d0d296@gmail.com
2024-02-15wifi: rtw89: fw: remove unnecessary rcu_read_unlock() for puncturedPing-Ke Shih
The rcu_read_unlock() is accidentally added, and sparse warn: drivers/net/wireless/realtek/rtw89/fw.c:2807:17: warning: context imbalance in 'rtw89_fw_h2c_assoc_cmac_tbl_g7' - unexpected unlock Fixes: b82730bf57b5 ("wifi: cfg80211/mac80211: move puncturing into chandef") Cc: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240213122556.9593-1-pkshih@realtek.com
2024-02-15wifi: rtw89: 8922a: declare to support two chanctxZong-Zhe Yang
We are going to allow MCC (multi-channel concurrency) on RTL8922A. So, increase 8922a::support_chanctx_num up to 2 first. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240213073514.23796-6-pkshih@realtek.com