blaster4385/linux-IllusionX/drivers/net/wireless/realtek, branch v6.12.1

wifi: rtlwifi: rtl8192du: Don't claim USB ID 0bda:8171

2024-10-17T14:25:03Z

This ID appears to be RTL8188SU, not RTL8192DU. This is the wrong driver for RTL8188SU. The r8712u driver from staging handles this ID. I think this ID comes from the original rtl8192du driver from Realtek. I don't know if they added it by mistake, or it was actually used for two different chips. RTL8188SU with this ID exists in the wild. RTL8192DU with this ID probably doesn't. Fixes: b5dc8873b6ff ("wifi: rtlwifi: Add rtl8192du/sw.c") Cc: stable@vger.kernel.org # v6.11 Closes: https://github.com/lwfinger/rtl8192du/issues/105 Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://patch.msgid.link/40245564-41fe-4a5e-881f-cd517255b20a@gmail.com

wifi: rtw88: Fix the RX aggregation in USB 3 mode

2024-10-17T14:24:17Z

RTL8822CU, RTL8822BU, and RTL8821CU don't need BIT_EN_PRE_CALC. In fact, RTL8822BU in USB 3 mode doesn't pass all the frames to the driver, resulting in much lower download speed than normal: $ iperf3 -c 192.168.0.1 -R Connecting to host 192.168.0.1, port 5201 Reverse mode, remote host 192.168.0.1 is sending [ 5] local 192.168.0.50 port 43062 connected to 192.168.0.1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 26.9 MBytes 225 Mbits/sec [ 5] 1.00-2.00 sec 7.50 MBytes 62.9 Mbits/sec [ 5] 2.00-3.00 sec 8.50 MBytes 71.3 Mbits/sec [ 5] 3.00-4.00 sec 8.38 MBytes 70.3 Mbits/sec [ 5] 4.00-5.00 sec 7.75 MBytes 65.0 Mbits/sec [ 5] 5.00-6.00 sec 8.00 MBytes 67.1 Mbits/sec [ 5] 6.00-7.00 sec 8.00 MBytes 67.1 Mbits/sec [ 5] 7.00-8.00 sec 7.75 MBytes 65.0 Mbits/sec [ 5] 8.00-9.00 sec 7.88 MBytes 66.1 Mbits/sec [ 5] 9.00-10.00 sec 7.88 MBytes 66.1 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.02 sec 102 MBytes 85.1 Mbits/sec 224 sender [ 5] 0.00-10.00 sec 98.6 MBytes 82.7 Mbits/sec receiver Don't set BIT_EN_PRE_CALC. Then the speed is much better: % iperf3 -c 192.168.0.1 -R Connecting to host 192.168.0.1, port 5201 Reverse mode, remote host 192.168.0.1 is sending [ 5] local 192.168.0.50 port 39000 connected to 192.168.0.1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 52.8 MBytes 442 Mbits/sec [ 5] 1.00-2.00 sec 71.9 MBytes 603 Mbits/sec [ 5] 2.00-3.00 sec 74.8 MBytes 627 Mbits/sec [ 5] 3.00-4.00 sec 75.9 MBytes 636 Mbits/sec [ 5] 4.00-5.00 sec 76.0 MBytes 638 Mbits/sec [ 5] 5.00-6.00 sec 74.1 MBytes 622 Mbits/sec [ 5] 6.00-7.00 sec 74.0 MBytes 621 Mbits/sec [ 5] 7.00-8.00 sec 76.0 MBytes 638 Mbits/sec [ 5] 8.00-9.00 sec 74.4 MBytes 624 Mbits/sec [ 5] 9.00-10.00 sec 63.9 MBytes 536 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 717 MBytes 601 Mbits/sec 24 sender [ 5] 0.00-10.00 sec 714 MBytes 599 Mbits/sec receiver Fixes: 002a5db9a52a ("wifi: rtw88: Enable USB RX aggregation for 8822c/8822b/8821c") Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://patch.msgid.link/afb94a82-3d18-459e-97fc-1a217608cdf0@gmail.com

wifi: rtw89: pci: early chips only enable 36-bit DMA on specific PCI hosts

2024-10-17T14:23:15Z

The early chips including RTL8852A, RTL8851B, RTL8852B and RTL8852BT have interoperability problems of 36-bit DMA with some PCI hosts. Rollback to 32-bit DMA by default, and only enable 36-bit DMA for tested platforms. Since all Intel platforms we have can work correctly, add the vendor ID to white list. Otherwise, list vendor/device ID of bridge we have tested. Fixes: 1fd4b3fe52ef ("wifi: rtw89: pci: support 36-bit PCI DMA address") Reported-by: Marcel Weißenbach Closes: https://lore.kernel.org/linux-wireless/20240918073237.Horde.VLueh0_KaiDw-9asEEcdM84@ignaz.org/T/#m07c5694df1acb173a42e1a0bab7ac22bd231a2b8 Signed-off-by: Ping-Ke Shih Tested-by: Marcel Weißenbach Signed-off-by: Kalle Valo Link: https://patch.msgid.link/20240924021633.19861-1-pkshih@realtek.com

wifi: rtw89: coex: add debug message of link counts on 2/5GHz bands for wl_info v7

2024-09-18T13:33:17Z

The counts will be used by MLO, and it is ongoing to add the code, so add debug message in todo part to avoid warnings reported by clang: coex.c:6323:23: warning: variable 'cnt_2g' set but not used [-Wunused-but-set-variable] 6323 | u8 i, mode, cnt = 0, cnt_2g = 0, cnt_5g = 0, ... | ^ coex.c:6323:35: warning: variable 'cnt_5g' set but not used [-Wunused-but-set-variable] 6323 | u8 i, mode, cnt = 0, cnt_2g = 0, cnt_5g = 0, ... | ^ Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://patch.msgid.link/20240912021626.10494-1-pkshih@realtek.com

Merge tag 'rtw-next-2024-09-05' of https://github.com/pkshih/rtw

2024-09-09T12:32:33Z

rtw-next patches for v6.12 The rtw89 is continuously adjusting code to support MLO. The major changes are listed below: rtw88: * fix USB not transmitting beacon in AP mode rtw89: * complete BT-coexistence code for RTL8852BT * fix throughput degrade of VHT rate for RTL8851B/8852A/8852B/8852BT * enable WoWLAN net-detect for more one chip, RTL8922A

wifi: rtw89: avoid reading out of bounds when loading TX power FW elements

2024-09-05T01:13:44Z

Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body. Signed-off-by: Zong-Zhe Yang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20240902015803.20420-1-pkshih@realtek.com

wifi: rtw89: use frequency domain RSSI

2024-09-05T00:55:02Z

To get more accurate RSSI, this commit includes frequency domain RSSI info in RSSI calculation. Add correspond physts parsing and macro to get frequency domain RSSI information for supported IC. Signed-off-by: Eric Huang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20240828055217.10263-3-pkshih@realtek.com

wifi: rtw89: adjust DIG threshold to reduce false alarm

2024-09-05T00:50:47Z

Use RSSI without subtracting offset as packet detection lower bound and set an absolute minimal threshold. It's equivalent to setting a higher noise floor, thereby reducing false alarm and improving interference endurance. Signed-off-by: Eric Huang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20240828055217.10263-2-pkshih@realtek.com

Merge tag 'wireless-next-2024-09-04' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next

2024-09-05T00:20:14Z

Kalle Valo says: ==================== pull-request: wireless-next-2024-09-04 here's a pull request to net-next tree, more info below. Please let me know if there are any problems. ==================== Conflicts: drivers/net/wireless/ath/ath12k/hw.c 38055789d151 ("wifi: ath12k: use 128 bytes aligned iova in transmit path for WCN7850") 8be12629b428 ("wifi: ath12k: restore ASPM for supported hardwares only") https://lore.kernel.org/87msldyj97.fsf@kernel.org Link: https://patch.msgid.link/20240904153205.64C11C4CEC2@smtp.kernel.org Signed-off-by: Jakub Kicinski

wifi: rtw89: wow: add scan interval option for net-detect

2024-09-02T01:15:02Z

The scan interval option is the period in unit of second for WoWLAN firmware to do each scan. We get the option from cfg80211 and practice it. If the interval is too short for firmware to finish one scan, the firmware will start next scan immediately after finishing one and the WiFi chip could never enter idle mode to reduce power consumption. Signed-off-by: Chin-Yen Lee Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20240826090439.17242-5-pkshih@realtek.com