summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek/rtw88/rtw8822b.c
AgeCommit message (Collapse)Author
2025-04-09wifi: rtw88: Don't set SUPPORTS_AMSDU_IN_AMPDU for RTL8814AUBitterblue Smith
RTL8814AU doesn't work well with SUPPORTS_AMSDU_IN_AMPDU. The RX speed is noticeably lower and the VHT RX statistics are strange. Typical values with SUPPORTS_AMSDU_IN_AMPDU: Reverse mode, remote host 192.168.0.1 is sending [ 5] local 192.168.0.50 port 60710 connected to 192.168.0.1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 74.6 MBytes 626 Mbits/sec [ 5] 1.00-2.00 sec 79.2 MBytes 665 Mbits/sec [ 5] 2.00-3.00 sec 84.9 MBytes 712 Mbits/sec [ 5] 3.00-4.00 sec 83.8 MBytes 703 Mbits/sec [ 5] 4.00-5.00 sec 85.9 MBytes 720 Mbits/sec [ 5] 5.00-6.00 sec 78.9 MBytes 662 Mbits/sec [ 5] 6.00-7.00 sec 81.2 MBytes 682 Mbits/sec [ 5] 7.00-8.00 sec 80.5 MBytes 675 Mbits/sec [ 5] 8.00-9.00 sec 79.4 MBytes 666 Mbits/sec [ 5] 9.00-10.00 sec 82.2 MBytes 689 Mbits/sec [ 5] 10.00-11.00 sec 82.0 MBytes 688 Mbits/sec [ 5] 11.00-12.00 sec 84.2 MBytes 707 Mbits/sec [ 5] 12.00-13.00 sec 71.0 MBytes 596 Mbits/sec [ 5] 13.00-14.00 sec 69.4 MBytes 582 Mbits/sec [ 5] 14.00-15.00 sec 80.2 MBytes 673 Mbits/sec [ 5] 15.00-16.00 sec 74.5 MBytes 625 Mbits/sec [Rx Counter]: * CCA (CCK, OFDM, Total) = (0, 2455, 2455) * False Alarm (CCK, OFDM, Total) = (0, 69, 69) * CCK cnt (ok, err) = (0, 0) * OFDM cnt (ok, err) = (1239, 2) * HT cnt (ok, err) = (0, 0) * VHT cnt (ok, err) = (21, 12109) The "VHT ok" number is not believable. And without SUPPORTS_AMSDU_IN_AMPDU: Reverse mode, remote host 192.168.0.1 is sending [ 5] local 192.168.0.50 port 50030 connected to 192.168.0.1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 70.5 MBytes 591 Mbits/sec [ 5] 1.00-2.00 sec 86.9 MBytes 729 Mbits/sec [ 5] 2.00-3.00 sec 98.6 MBytes 827 Mbits/sec [ 5] 3.00-4.00 sec 97.4 MBytes 817 Mbits/sec [ 5] 4.00-5.00 sec 98.6 MBytes 827 Mbits/sec [ 5] 5.00-6.00 sec 96.9 MBytes 813 Mbits/sec [ 5] 6.00-7.00 sec 98.2 MBytes 824 Mbits/sec [ 5] 7.00-8.00 sec 98.0 MBytes 822 Mbits/sec [ 5] 8.00-9.00 sec 99.9 MBytes 838 Mbits/sec [ 5] 9.00-10.00 sec 99.2 MBytes 833 Mbits/sec [ 5] 10.00-11.00 sec 98.0 MBytes 822 Mbits/sec [ 5] 11.00-12.00 sec 98.1 MBytes 823 Mbits/sec [ 5] 12.00-13.00 sec 97.0 MBytes 814 Mbits/sec [ 5] 13.00-14.00 sec 98.2 MBytes 824 Mbits/sec [ 5] 14.00-15.00 sec 98.5 MBytes 826 Mbits/sec [ 5] 15.00-16.00 sec 97.4 MBytes 817 Mbits/sec [Rx Counter]: * CCA (CCK, OFDM, Total) = (0, 3860, 3860) * False Alarm (CCK, OFDM, Total) = (0, 2, 2) * CCK cnt (ok, err) = (0, 0) * OFDM cnt (ok, err) = (1486, 0) * HT cnt (ok, err) = (0, 0) * VHT cnt (ok, err) = (7399, 9118) Add a new member "amsdu_in_ampdu" in struct rtw_chip_info and use it to set SUPPORTS_AMSDU_IN_AMPDU only for the other chips. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/6202ccfb-feb0-4107-a08d-db2699e179f0@gmail.com
2025-04-09wifi: rtw88: Set AMPDU factor to hardware for RTL8814ABitterblue Smith
Tell the chip the maximum AMPDU size supported by the AP. This greatly improves the TX speed of RTL8814AU in the 2.4 GHz band. Before: ~90 Mbps. After: ~300 Mbps. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/4edc2a63-81b3-431c-9a37-5a7d899a6cc2@gmail.com
2025-02-10wifi: rtw88: Extend TX power stuff for 3-4 spatial streamsBitterblue Smith
Although the RTL8814AU only has 3 spatial streams, maybe some other chip has 4. Correct the TX power index and TX power limit calculations for 3SS and 4SS HT/VHT rates. With this the RTL8814AU can set the TX power correctly. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/d0c0e126-0794-4c4e-9203-ea39a707b673@gmail.com
2025-02-10wifi: rtw88: Rename RTW_RATE_SECTION_MAX to RTW_RATE_SECTION_NUMBitterblue Smith
It fits the meaning of the enum better. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/5a1c5a46-8ebb-43b0-9ab1-b78e2a22b3d2@gmail.com
2025-02-03wifi: rtw88: Don't use static local variable in ↵Bitterblue Smith
rtw8822b_set_tx_power_index_by_rate Some users want to plug two identical USB devices at the same time. This static variable could theoretically cause them to use incorrect TX power values. Move the variable to the caller and pass a pointer to it to rtw8822b_set_tx_power_index_by_rate(). Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/8a60f581-0ab5-4d98-a97d-dd83b605008f@gmail.com
2025-01-12wifi: rtw88: Add support for LED blinkingBitterblue Smith
Register a struct led_classdev with the kernel's LED subsystem and create a throughput-based trigger for it. Then mac80211 makes the LED blink. Tested with Tenda U12 (RTL8812AU), Tenda U9 (RTL8811CU), TP-Link Archer T2U Nano (RTL8811AU), TP-Link Archer T3U Plus (RTL8812BU), Edimax EW-7611UCB (RTL8821AU), LM842 (RTL8822CU). Also tested with devices which don't have LEDs: the laptop's internal RTL8822CE and a no-name RTL8723DU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/6c43451f-ab2f-4e76-ac6e-ff5a18dd981d@gmail.com
2024-10-29wifi: rtw88: Move pwr_track_tbl to struct rtw_rfe_defBitterblue Smith
RTL8812AU uses one set of TX power tracking tables for RFE 3, and another set for everything else. Move pwr_track_tbl from struct rtw_chip_info to struct rtw_rfe_def in order to load the right set of tables for each RFE (RF front end) type. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/904d0ab1-c046-40cd-a3a3-d4fdcf663c9d@gmail.com
2024-10-29wifi: rtw88: Enable data rate fallback for older chipsBitterblue Smith
RTL8811AU fails to perform the 4-way handshake when the AP is too far because it transmits the EAPOL frames at MCS9 and when that doesn't work it retries 48 times with the same rate, to no avail. Retrying 48 times with the same rate seems pointless. Set the appropriate field in the TX descriptor to allow it to use lower rates when retrying. Set it for RTL8723D and RTL8703B because they interpret this field the same way as RTL8811A. The newer RTL8822C, RTL8822B, RTL8821C seem to interpret this field in the TX descriptor differently, so leave it alone for those chips. Tested with RTL8811AU and RTL8723DU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/2b3e3e6f-541b-4a3b-8ca3-65b267e6a95a@gmail.com
2024-10-29wifi: rtw88: Let each driver control the power on/off processBitterblue Smith
RTL8821AU and RTL8812AU have to do some things differently, so let them have full control. The other chips use the same functions as before. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/98ab839f-9100-44ae-9551-9af743a4aa3a@gmail.com
2024-10-29wifi: rtw88: Allow different C2H RA report sizesBitterblue Smith
The RTL8821AU and RTL8812AU have smaller RA report size, only 4 bytes. Avoid the "invalid ra report c2h length" error. Also, use a struct and u8_get_bits() to access the RA report C2H. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/c3e73c3a-fb2f-4013-9f06-d5274211e282@gmail.com
2024-10-29wifi: rtw88: Dump the HW features only for some chipsBitterblue Smith
RTL8821AU and RTL8812AU don't support this. They hit the "failed to read hw feature report" error. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/8becd851-8760-4480-8e8c-c4869ce72507@gmail.com
2024-09-26wifi: rtw88: Parse the RX descriptor with a single functionBitterblue Smith
rtw8703b_query_rx_desc(), rtw8723d_query_rx_desc(), rtw8821c_query_rx_desc(), rtw8822b_query_rx_desc(), and rtw8822c_query_rx_desc() are almost identical, so replace them all with a single function, rtw_rx_query_rx_desc(). Also, access the RX descriptor using a struct with __le32 members and le32_get_bits(). Tested with RTL8811CU, RTL8811AU, and RTL8812AU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Tested-by: Ping-Ke Shih <pkshih@realtek.com> # RTL8723DE and RTL8822CE Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/913f1747-38fc-4409-85a4-57bb9cee506b@gmail.com
2024-09-20wifi: rtw88: Constify some arrays and structsBitterblue Smith
These are never modified, so make them const: card_enable_flow_8703b card_disable_flow_8703b rtw8703b_ops rtw8723d_ops card_enable_flow_8723d card_disable_flow_8723d trans_carddis_to_cardemu_8821c trans_cardemu_to_act_8821c trans_act_to_cardemu_8821c trans_cardemu_to_carddis_8821c card_enable_flow_8821c card_disable_flow_8821c rtw8821c_dig page_table_8821c rqpn_table_8821c prioq_addrs_8821c rtw8821c_ops card_enable_flow_8822b card_disable_flow_8822b prioq_addrs_8822b rtw8822b_ops rtw8822b_edcca_th card_enable_flow_8822c card_disable_flow_8822c prioq_addrs_8822c rtw8822c_ops rtw8822c_edcca_th Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/dae7994f-3491-40de-b537-ebf68df084bb@gmail.com
2024-07-17wifi: rtw88: usb: Support USB 3 with RTL8822CU/RTL8822BUBitterblue Smith
The Realtek wifi 5 devices which support USB 3 are weird: when first plugged in, they pretend to be USB 2. The driver needs to send some commands to the device, which make it disappear and come back as a USB 3 device. Implement the required commands in rtw88. When a USB 3 device is plugged into a USB 2 port, rtw88 will try to switch it to USB 3 mode only once. The device will disappear and come back still in USB 2 mode, of course. Some people experience heavy interference in the 2.4 GHz band in USB 3 mode, so add a module parameter switch_usb_mode with the default value 1 to let people disable the switching. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/77906c62-5674-426f-bde1-1b2a12a0339d@gmail.com
2024-06-21wifi: rtw88: usb: Further limit the TX aggregationBitterblue Smith
Currently the number of frames sent to the chip in a single USB Request Block is limited only by the size of the TX buffer, which is 20 KiB. Testing reveals that as many as 13 frames get aggregated. This is more than what any of the chips would like to receive. RTL8822CU, RTL8822BU, and RTL8821CU want at most 3 frames, and RTL8723DU wants only 1 frame per URB. RTL8723DU in particular reliably malfunctions during a speed test if it receives more than 1 frame per URB. All traffic seems to stop. Pinging the AP no longer works. Fix this problem by limiting the number of frames sent to the chip in a single URB according to what each chip likes. Also configure RTL8822CU, RTL8822BU, and RTL8821CU to expect 3 frames per URB. RTL8703B may or may not be found in USB devices. Declare that it wants only 1 frame per URB, just in case. Tested with RTL8723DU and RTL8811CU. Cc: stable@vger.kernel.org Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/cb46ea35-7e59-4742-9c1f-01ceeaad36fb@gmail.com
2023-04-20wifi: rtw88: 8822c: extend reserved page numberPo-Hao Huang
Extend 8822c's reserved page number to accommodate additional required pages. Reserved page is an area of memory in the FIFO dedicated for special purposes. Previously only one interface is supported so 8 pages should suffice, extend it so we can support 2 interfaces concurrently. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230414121135.17828-4-pkshih@realtek.com
2023-02-22wifi: rtw88: rtw8822b: Implement RTL8822BS (SDIO) efuse parsingMartin Blumenstingl
The efuse of the SDIO RTL8822BS chip has only one known member: the mac address is at offset 0x11a. Add a struct rtw8822bs_efuse describing this and use it for copying the mac address when the SDIO bus is used. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230218152944.48842-5-martin.blumenstingl@googlemail.com
2022-12-08wifi: rtw88: Add rtw8822bu chipset supportSascha Hauer
Add support for the rtw8822bu chipset based on https://github.com/ulli-kroll/rtw88-usb.git Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221202081224.2779981-10-s.hauer@pengutronix.de
2022-08-09wifi: rtw88: 8822c: extend supported probe request sizePo-Hao Huang
Some WSC IEs require size larger than we current supports. Extend size to fit those demands. Separate the registered scan IE length by IC so settings can be independent. Since old firmware uses fewer page number, define a firmware feature to be compatible with various firmware version. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220727065003.28340-2-pkshih@realtek.com
2022-05-30wifi: rtw88: Fix sparse warning for rtw8822b_hw_specLarry Finger
Sparse lists the following for rtw88: CHECK drivers/net/wireless/realtek/rtw88/rtw8822b.c drivers/net/wireless/realtek/rtw88/rtw8822b.c:2500:22: warning: symbol 'rtw8822b_hw_spec' was not declared. Should it be static? The warning arises because the external declaration for rtw8822b_hw_spec occurs in rtw8822be.h, which is not included in rtw8822b.h. That line is moved, and the now empty file rtw8822be.h is deleted. Symbol 'rtw8822b_hw_spec' can be made constant. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220524153621.19027-2-Larry.Finger@lwfinger.net
2022-05-01rtw88: add HT MPDU density value for each chipChih-Kang Chang
Each chip have best ampdu density value, the correct setting can improve throughput performance. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220428020521.8015-1-pkshih@realtek.com
2022-02-22rtw88: change rtw_info() to proper message levelPing-Ke Shih
Larry reported funny log entries [1] when he used rtl8821ce. These messages are not harmless, but not useful for users, so change them to rtw_dbg() level. By the way, I review all rtw_info() and change others to rtw_warn(). [1] https://lore.kernel.org/linux-wireless/c356d5ae-a7b3-3065-1121-64c446e70333@lwfinger.net/ Reported-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220218035527.9835-1-pkshih@realtek.com
2022-02-21rtw88: coex: Add WLAN MIMO power saving for Bluetooth gaming controllerChing-Te Ku
To keep high sensitivity reaction, Bluetooth gaming controller will send packet very frequently, it will make WLAN performance very poor. To solve this situation, MIMO PS mechanism makes WLAN/BT own an antenna itself, WLAN quits 2SS performance but it can get a stable 1SS performance and Bluetooth gaming controller can keep sensitivity reaction at the same time. 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://lore.kernel.org/r/20220215004855.4098-5-pkshih@realtek.com
2021-12-20rtw88: 8822c: update rx settings to prevent potential hw deadlockPo-Hao Huang
These settings enables mac to detect and recover when rx fifo circuit deadlock occurs. Previous version missed this, so we fix it. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211217012708.8623-1-pkshih@realtek.com
2021-12-20rtw88: don't check CRC of VHT-SIG-B in 802.11ac signalChin-Yen Lee
Currently all realtek wifi chip is set to check CRC of VHT-SIG-B in 802.11ac signal, but some AP don't calculate the CRC and packets from these AP can't be received and lead to disconnection. We disable the check defaultly to avoid this case. 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://lore.kernel.org/r/20211217012421.7859-1-pkshih@realtek.com
2021-09-21rtw88: support adaptivity for ETSI/JP DFS regionZong-Zhe Yang
Add Energy Detected CCA (EDCCA) mechanism to detect energy on the channel. And EDCCA support adaptivity mode now. From MIC Ordinance Regulating Radio Equipment article 49.20, ETSI EN-300-328 and EN-301-893, the device should be able to dynamically pause TX activity when energy detected on the air. According to ETSI/JP DFS region, driver will set corresponding threshold and stop TX activity if the detected energy exceeds the threshold. For now, we support it on 8822b and 8822c first. By default, EDCCA mechanism is turned on. For ETSI/JP DFS region, it will turn to adaptivity mode. However, with adaptivity, if environment is too noisy, TX may often be halted. So, a debugfs for EDCCA is added. It can show what EDCCA mode is used currently. And EDCCA mechanism can be turned on/off through the debugfs while debugging. 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@codeaurora.org> Link: https://lore.kernel.org/r/20210830072014.12250-4-pkshih@realtek.com
2021-09-21rtw88: upgrade rtw_regulatory mechanism and mappingZong-Zhe Yang
Mapping table from country code to rtw_regulatory, which manages tx power limit according to countries, is updated. And mapping architecture is also upgraded. For more precise control on tx power limit, it allows different rtw_regulatory for different bands logically. Besides, a helper function to query rtw_regulatory for current band under current country is provided. For older chips, some newly added rtw_regulatory may not be configured. To avoid that those chips have no limit on some countries mapping to a newer rtw_regulatory after table update, a backward selection mechanism of rtw_regulatory is introduced. It can help chips use a rtw_regulatory which has been configured as an alternative of a newer one which is not configured. In addition, rtw88 actually doesn't manage channel plans by itself. Instead, it follows them from stack. So, correct some naming about chplan with regd, and remove the unnecessary channel control for now. 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@codeaurora.org> Link: https://lore.kernel.org/r/20210830072014.12250-2-pkshih@realtek.com
2020-12-02rtw88: coex: upgrade coexistence A2DP mechanismChing-Te Ku
Add modifications for A2DP interoperability issue of TWS earphones. Some TWS earphones has low buffer size, so it's necessary to reduce the slot period to let it get data more frequently. (e.g. use 4-slot to replace the original 2-slot method). Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201126021059.11981-10-pkshih@realtek.com
2020-11-10rtw88: coex: add debug messageChing-Te Ku
Since coexistence issue is related to WL/BT and each digital/analog/rf, and these issues are often critical with low failure rate, add more debugging information is helpful to clarify issues. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201109085909.9143-11-pkshih@realtek.com
2020-11-10rtw88: coex: update WLAN 5G AFH parameter for 8822bChing-Te Ku
Adaptive Frequency Hopping(AFH) is a method of transmitting radio signals by rapidly changing the carrier frequency among many distinct frequencies, which can avoid interference. Add this feature to update AFH parameter for 8822b. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201109085909.9143-10-pkshih@realtek.com
2020-11-10rtw88: coex: update coex parameter to improve A2DP qualityChing-Te Ku
Update COEX parameters and logic to enhance WL/BT performance while WL_Busy + A2DP in a less interference environment. It can avoid the interference comes cross from each other and earned more performance. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201109085909.9143-3-pkshih@realtek.com
2020-11-10rtw88: coex: fixed some wrong register definition and settingChing-Te Ku
Some register definition and bit definition were incorrect. e.g. REG_BT_COEX_V2 should be word alignment to meet the coding style. e.g. set REG_BT_TDMA_TIME[5:0]=0x5, But the original is to set REG_BT_TDMA_TIME[7:0]=0x5. This will cause unexpected hardware behavior. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201109085909.9143-2-pkshih@realtek.com
2020-11-07rtw88: coex: separate BLE HID profile from BLE profileChing-Te Ku
BT firmware will report BLE-HID and BLE-RCU in different profile. We can distinguish the two profile from BT info now. Add the coexistence for BLE-HID coexistence, it can make BLE HID work more smoothly. BLE-HID need to Tx/Rx packet more frequently to respond user operation, but RCU doesn't. In the case of RCU coexistence, it will make Wi-Fi have a higher priority to earn more Wi-Fi throughput. If BLE-HID go for the same case, it will make user feel mouse is lagging. Desired BT firmware BT-COEX version: 0x1c Desired WL firmware version: 9.9 Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201030055506.6560-1-pkshih@realtek.com
2020-11-07rtw88: remove extraneous 'const' qualifierArnd Bergmann
clang -Wextra warns about functions returning a 'const' integer: drivers/net/wireless/realtek/rtw88/rtw8822b.c:90:8: warning: 'const' type qualifier on return type has no effect [-Wignored-qualifiers] static const u8 rtw8822b_get_swing_index(struct rtw_dev *rtwdev) Remove the extra qualifier here. Fixes: c97ee3e0bea2 ("rtw88: add power tracking support") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201026213040.3889546-7-arnd@kernel.org
2020-09-29rtw88: add dump firmware fifo supportTzu-En Huang
Rtw88 currently has a function to dump reserved page section of the firmware fifo. Reserved page is just part of the firmware fifo, there are multiple sections in the firmware fifo for different usages, such as firmware rx fifo and tx fifo. This commit adds a function to check not only the reserved page section but also other parts of the firmware fifo. In addition, we need to dump firmware fifo to dump the debug log message if firmware crashes. Signed-off-by: Tzu-En Huang <tehuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200925061219.23754-4-tehuang@realtek.com
2020-08-18rtw88: fix spelling mistake: "unsupport" -> "unsupported"Colin Ian King
There are some spelling mistakes in rtw_info messages. Fix these. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200806120803.60113-1-colin.king@canonical.com
2020-07-15rtw88: coex: Fix ACL Tx pause during BT inquiry/page.Zong-Zhe Yang
Add a set of logic with corresponding coexistence parameters to handle the situation under BT inquiry/page. We will set PSTDMA while WL-Busy + BT inquiry/page to separate WL/BT slots. PSTDMA can protect WL data rate and BT performance. If WL-Busy + BT inquiry/page and there was BT device paired, We will set the mechanism to 4Slot PSTDMA. In 4Slot PSTDMA, the paired devices can perform more smoothly and prevent some issues trigger from insufficient data. And to avoid A2DP glitch or disconnection, we will adjust ACL data priority higher than inquiry/page. In addition, we found sometimes BT inquiry/page still working last for seconds after BT had notified inquiry/page finished. It will lead to A2DP glitch cause of ACL data, inquiry/page priority toggled. To fix the corner, we add a timer to remain the inquiry/page status. And we found WL busy/idle threshold is too sensitive, it will keep switching in some weak network environment and coexistence mechanism will switch between TDMA and PSTDMA. The very frequently switching may destroyed not only the handshake with AP, but BT performance. And it will trigger some unexpected error. To prevent the frequently switching, we add a timer to delay the status change while WL busy switch to idle. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200715023324.8600-1-yhchuang@realtek.com
2020-05-29Revert "rtw88: no need to set registers for SDIO"Yan-Hsuan Chuang
This reverts commit 07d0f5534935e2daf63a4e1012af13d68e089fed. For rtw88 driver, the SDIO is going to be supported, so there is no need to remove the SDIO related power sequence settings. And while the power sequence parser will pass in the mask of the HCI, the SDIO part will not be used to set registers accordingly. Moreover, the power sequence table is released as a whole package, so the next time if we are going to update, the SDIO settings will be overwritten. So, revert this now. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200520055350.23328-1-yhchuang@realtek.com
2020-05-18rtw88: no need to set registers for SDIOKevin Lo
There's no need to set SDIO related registers when powering up/down the chip. Signed-off-by: Kevin Lo <kevlo@kevlo.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200515061153.GA15714@ns.kevlo.org
2020-05-18rtw88: extract: make 8822b an individual kernel moduleZong-Zhe Yang
Make objects about 8822b functions and 8822b tables, i.e. rtw8822b.o and rtw8822b_table.o, an individual kernel module called rtw88_8822b.ko. For 8822b pcie chip, i.e. 8822BE chip, add a chip entry point module called rtw88_8822be.ko which will depend on rtw88_8822b.ko and rtwpci.ko. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200515052327.31874-5-yhchuang@realtek.com
2020-05-13rtw88: 8723d: set ltecoex register address in chip_infoPing-Ke Shih
Since 8723D use different address of ltecoex register, this commit add a new field in chip_info and fill proper address. Then, ltecoex_read_reg() and ltecoex_reg_write() can use them to access ltecoex according to chip. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200512102621.5148-7-yhchuang@realtek.com
2020-05-13rtw88: 8723d: implement flush queuePing-Ke Shih
Flush queue is used to check if queue is empty, before doing something else. Since 8723D uses different registers and page number of availabl/reserved occupy 8 bits instead of 16 bits, so use a 'wsize' field to discriminate which rtw_read{8,16} is adopted. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200512102621.5148-6-yhchuang@realtek.com
2020-05-06rtw88: 8723d: Set IG register for CCK ratePing-Ke Shih
DIG sets only one IG register for most chips, but 8723D need to set additional register for CCK rate. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200504105010.10780-8-yhchuang@realtek.com
2020-05-06rtw88: 8723d: some chips don't support LDPCPing-Ke Shih
Some chips are not able to receive LDPC packets. Add an attribute to rtw_chip_info to determine if the LDPC capability in [ht/vht]_cap should be advertised or not. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200504105010.10780-6-yhchuang@realtek.com
2020-04-23rtw88: add legacy firmware download for 8723D devicesPing-Ke Shih
The WLAN CPU of 8723D device is different from others, add legacy firmware download function for it. A new variable wlan_cpu is used to decide which firmware download function we should use. Legacy firmware file contains 32 bytes header including version and subversion. When downloading to wlan cpu, header is excluded. Firmware is downloaded via beacon queue to reserved page that is a part of TX buffer. Since 11N WLAN CPU uses different control registers, this patch introduces related control registers. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200422034607.28747-2-yhchuang@realtek.com
2020-04-21rtw88: 8723d: Add cfg_ldo25 to control LDO25Ping-Ke Shih
Implement rtw_chip_ops::cfg_ldo25 to enable/disable LDO25 with proper voltage. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200420055054.14592-7-yhchuang@realtek.com
2020-04-15rtw88: make rtw_chip_ops::set_antenna return intYan-Hsuan Chuang
To support ieee80211_ops::set_antenna, the driver can decide if the antenna mask is accepted, otherwise it can return an error code. Because each chip could have different limitations, let the chip check the mask and return. Also the antenna mask for TRX from upper space is 32-bit long. Change the antenna mask for rtw_chip_ops::set_antenna from u8 to u32. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200410100950.3199-2-yhchuang@realtek.com
2020-03-26rtw88: add a debugfs entry to dump coex's infoYan-Hsuan Chuang
Add a new entry "coex_info" in debugfs to dump coex's states for us to debug on coex's issues. The basic concept for co-existence (coex, usually for WiFi + BT) is to decide a strategy based on the current status of WiFi and BT. So, it means the WiFi driver requires to gather information from BT side and choose a strategy (TDMA/table/HW settings). Althrough we can easily check the current status of WiFi, e.g., from kernel log or just dump the hardware registers, it is still very difficult for us to gather so many different types of WiFi states (such as RFE config, antenna, channel/band, TRX, Power save). Also we will need BT's information that is stored in "struct rtw_coex". So it is necessary for us to have a debugfs that can dump all of the WiFi/BT information required. Note that to debug on coex related issues, we usually need a longer period of time of coex_info dump every 2 seconds (for example, 30 secs, so we should have 15 times of coex_info's dump). Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200313033008.20070-2-yhchuang@realtek.com
2020-02-12rtw88: 8822[bc]: Make tables const, reduce data object sizeJoe Perches
Reduce the data size 2kb or 3kb by making tables const. Add const to pointer declarations to make compilation work too. (x86-64 defconfig) $ size drivers/net/wireless/realtek/rtw88/rtw8822?.o* text data bss dec hex filename 25054 672 8 25734 6486 drivers/net/wireless/realtek/rtw88/rtw8822b.o.new 23870 1872 8 25750 6496 drivers/net/wireless/realtek/rtw88/rtw8822b.o.old 53646 828 0 54474 d4ca drivers/net/wireless/realtek/rtw88/rtw8822c.o.new 52846 1652 0 54498 d4e2 drivers/net/wireless/realtek/rtw88/rtw8822c.o.old (x86-64 allyesconfig) $ size drivers/net/wireless/realtek/rtw88/rtw8822?.o* text data bss dec hex filename 45811 6280 128 52219 cbfb drivers/net/wireless/realtek/rtw88/rtw8822b.o.new 44211 7880 128 52219 cbfb drivers/net/wireless/realtek/rtw88/rtw8822b.o.old 100195 8128 0 108323 1a723 drivers/net/wireless/realtek/rtw88/rtw8822c.o.new 98947 9376 0 108323 1a723 drivers/net/wireless/realtek/rtw88/rtw8822c.o.old Signed-off-by: Joe Perches <joe@perches.com> Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-02-12rtw88: Use secondary channel offset enumerationPing-Ke Shih
The hardware value of secondary channel offset isn't very intuitive. This commit adds enumeration, so we can easier to check the logic with the suffix of enumeration name, likes _UPPER or _LOWER. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
generated by cgit (git 2.34.1) at 2025-08-01 18:12:51 +0000