summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek
AgeCommit message (Collapse)Author
2025-02-21wifi: rtw89: pci: disable PCIE wake bit when PCIE deinitPing-Ke Shih
commit 9c1df813e08832c3836c254bc8a2f83ff22dbc06 upstream. The PCIE wake bit is to control PCIE wake signal to host. When PCIE is going down, clear this bit to prevent waking up host unexpectedly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241111063835.15454-1-pkshih@realtek.com Signed-off-by: Zenm Chen <zenmchen@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-17wifi: rtw88: 8703b: Fix RX/TX issuesVasily Khoruzhick
commit a806a8160a0fcaff368bb510c8a52eff37faf727 upstream. Fix 3 typos in 8703b driver. 2 typos in calibration routines are not fatal and do not seem to have any impact, just fix them to match vendor driver. However the last one in rtw8703b_set_channel_bb() clears too many bits in REG_OFDM0_TX_PSD_NOISE, causing TX and RX issues (neither rate goes above MCS0-MCS1). Vendor driver clears only 2 most significant bits. With the last typo fixed, the driver is able to reach MCS7 on Pinebook Cc: stable@vger.kernel.org Fixes: 9bb762b3a957 ("wifi: rtw88: Add definitions for 8703b chip") Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Fiona Klute <fiona.klute@gmx.de> Tested-by: Andrey Skvortsov <andrej.skvortzov@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250103075107.1337533-1-anarsoul@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-17wifi: rtw88: sdio: Fix disconnection after beacon lossFiona Klute
commit fb2fcfbe5eef9ae26b0425978435ae1308951e51 upstream. This is the equivalent of commit 28818b4d871b ("wifi: rtw88: usb: Fix disconnection after beacon loss") for SDIO chips. Tested on Pinephone (RTL8723CS), random disconnections became rare, instead of a frequent nuisance. Cc: stable@vger.kernel.org Signed-off-by: Fiona Klute <fiona.klute@gmx.de> Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> # Tested on Pinebook Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250106135434.35936-1-fiona.klute@gmx.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-17wifi: rtlwifi: rtl8821ae: Fix media status reportBitterblue Smith
commit 66ef0289ac99e155d206ddaa0fdfad09ae3cd007 upstream. RTL8821AE is stuck transmitting at the lowest rate allowed by the rate mask. This is because the firmware doesn't know the device is connected to a network. Fix the macros SET_H2CCMD_MSRRPT_PARM_OPMODE and SET_H2CCMD_MSRRPT_PARM_MACID_IND to work on the first byte of __cmd, not the second. Now the firmware is correctly notified when the device is connected to a network and it activates the rate control. Before (MCS3): [ 5] 0.00-1.00 sec 12.5 MBytes 105 Mbits/sec 0 339 KBytes [ 5] 1.00-2.00 sec 10.6 MBytes 89.1 Mbits/sec 0 339 KBytes [ 5] 2.00-3.00 sec 10.6 MBytes 89.1 Mbits/sec 0 386 KBytes [ 5] 3.00-4.00 sec 10.6 MBytes 89.1 Mbits/sec 0 386 KBytes [ 5] 4.00-5.00 sec 10.2 MBytes 86.0 Mbits/sec 0 427 KBytes After (MCS9): [ 5] 0.00-1.00 sec 33.9 MBytes 284 Mbits/sec 0 771 KBytes [ 5] 1.00-2.00 sec 31.6 MBytes 265 Mbits/sec 0 865 KBytes [ 5] 2.00-3.00 sec 29.9 MBytes 251 Mbits/sec 0 963 KBytes [ 5] 3.00-4.00 sec 28.2 MBytes 237 Mbits/sec 0 963 KBytes [ 5] 4.00-5.00 sec 26.8 MBytes 224 Mbits/sec 0 963 KBytes Fixes: 39f40710d0b5 ("rtlwifi: rtl88821ae: Remove usage of private bit manipulation macros") 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/754785b3-8a78-4554-b80d-de5f603b410b@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-17wifi: rtw88: add __packed attribute to efuse layout structPing-Ke Shih
[ Upstream commit 0daa521a1c8c29ffbefe6530f0d276e74e2749d0 ] The layout struct of efuse should not do address alignment by compiler. Otherwise it leads unexpected layout and size for certain arch suc as arm. In x86-64, the results are identical before and after this patch. Also adjust bit-field to prevent over adjacent byte to avoid warning: rtw88/rtw8822b.h:66:1: note: offset of packed bit-field `res2` has changed in GCC 4.4 66 | } __packed; | ^ Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202412120131.qk0x6OhE-lkp@intel.com/ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241212054203.135046-1-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-17wifi: rtw89: add crystal_cap check to avoid setting as overflow valueChih-Kang Chang
[ Upstream commit 7b98caea39676561f22db58752551161bb36462b ] In the original flow, the crystal_cap might be calculated as a negative value and set as an overflow value. Therefore, we added a check to limit the calculated crystal_cap value. Additionally, we shrank the crystal_cap adjustment according to specific CFO. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241128055433.11851-7-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08wifi: rtw89: fix race between cancel_hw_scan and hw_scan completionPing-Ke Shih
[ Upstream commit ba4bb0402c60e945c4c396c51f0acac3c3e3ea5c ] The rtwdev->scanning flag isn't protected by mutex originally, so cancel_hw_scan can pass the condition, but suddenly hw_scan completion unset the flag and calls ieee80211_scan_completed() that will free local->hw_scan_req. Then, cancel_hw_scan raises null-ptr-deref and use-after-free. Fix it by moving the check condition to where protected by mutex. KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] CPU: 2 PID: 6922 Comm: kworker/2:2 Tainted: G OE Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB6WW (2.76 ) 09/10/2019 Workqueue: events cfg80211_conn_work [cfg80211] RIP: 0010:rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core] Code: 00 45 89 6c 24 1c 0f 85 23 01 00 00 48 8b 85 20 ff ff ff 48 8d RSP: 0018:ffff88811fd9f068 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88811fd9f258 RCX: 0000000000000001 RDX: 0000000000000011 RSI: 0000000000000001 RDI: 0000000000000089 RBP: ffff88811fd9f170 R08: 0000000000000000 R09: 0000000000000000 R10: ffff88811fd9f108 R11: 0000000000000000 R12: ffff88810e47f960 R13: 0000000000000000 R14: 000000000000ffff R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8881d6f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007531dfca55b0 CR3: 00000001be296004 CR4: 00000000001706e0 Call Trace: <TASK> ? show_regs+0x61/0x73 ? __die_body+0x20/0x73 ? die_addr+0x4f/0x7b ? exc_general_protection+0x191/0x1db ? asm_exc_general_protection+0x27/0x30 ? rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core] ? rtw89_fw_h2c_scan_offload_be+0x458/0x13c3 [rtw89_core] ? __pfx_rtw89_fw_h2c_scan_offload_be+0x10/0x10 [rtw89_core] ? do_raw_spin_lock+0x75/0xdb ? __pfx_do_raw_spin_lock+0x10/0x10 rtw89_hw_scan_offload+0xb5e/0xbf7 [rtw89_core] ? _raw_spin_unlock+0xe/0x24 ? __mutex_lock.constprop.0+0x40c/0x471 ? __pfx_rtw89_hw_scan_offload+0x10/0x10 [rtw89_core] ? __mutex_lock_slowpath+0x13/0x1f ? mutex_lock+0xa2/0xdc ? __pfx_mutex_lock+0x10/0x10 rtw89_hw_scan_abort+0x58/0xb7 [rtw89_core] rtw89_ops_cancel_hw_scan+0x120/0x13b [rtw89_core] ieee80211_scan_cancel+0x468/0x4d0 [mac80211] ieee80211_prep_connection+0x858/0x899 [mac80211] ieee80211_mgd_auth+0xbea/0xdde [mac80211] ? __pfx_ieee80211_mgd_auth+0x10/0x10 [mac80211] ? cfg80211_find_elem+0x15/0x29 [cfg80211] ? is_bss+0x1b7/0x1d7 [cfg80211] ieee80211_auth+0x18/0x27 [mac80211] cfg80211_mlme_auth+0x3bb/0x3e7 [cfg80211] cfg80211_conn_do_work+0x410/0xb81 [cfg80211] ? __pfx_cfg80211_conn_do_work+0x10/0x10 [cfg80211] ? __kasan_check_read+0x11/0x1f ? psi_group_change+0x8bc/0x944 ? __kasan_check_write+0x14/0x22 ? mutex_lock+0x8e/0xdc ? __pfx_mutex_lock+0x10/0x10 ? __pfx___radix_tree_lookup+0x10/0x10 cfg80211_conn_work+0x245/0x34d [cfg80211] ? __pfx_cfg80211_conn_work+0x10/0x10 [cfg80211] ? update_cfs_rq_load_avg+0x3bc/0x3d7 ? sched_clock_noinstr+0x9/0x1a ? sched_clock+0x10/0x24 ? sched_clock_cpu+0x7e/0x42e ? newidle_balance+0x796/0x937 ? __pfx_sched_clock_cpu+0x10/0x10 ? __pfx_newidle_balance+0x10/0x10 ? __kasan_check_read+0x11/0x1f ? psi_group_change+0x8bc/0x944 ? _raw_spin_unlock+0xe/0x24 ? raw_spin_rq_unlock+0x47/0x54 ? raw_spin_rq_unlock_irq+0x9/0x1f ? finish_task_switch.isra.0+0x347/0x586 ? __schedule+0x27bf/0x2892 ? mutex_unlock+0x80/0xd0 ? do_raw_spin_lock+0x75/0xdb ? __pfx___schedule+0x10/0x10 process_scheduled_works+0x58c/0x821 worker_thread+0x4c7/0x586 ? __kasan_check_read+0x11/0x1f kthread+0x285/0x294 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x6f ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Fixes: 895907779752 ("rtw89: 8852a: add ieee80211_ops::hw_scan") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250107114254.6769-1-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08wifi: rtw89: mcc: consider time limits not divisible by 1024Zong-Zhe Yang
[ Upstream commit 35642ba31dc4a1816a20191e90156a9e329beb10 ] For each MCC role, time limits, including max_tob_us, max_toa_us, and mac_dur_us, are calculated if there are NoA attributes. The relation between these time limits is "max_dur_us = max_tob_us + max_toa_us". Then, the unit is converted from us to TU. However, originally, each time limit was divided by 1024 independently. It missed to consider the cases that max_tob_us or max_toa_us is not divisible by 1024. It causes the result breaks "max_dur (TU) = max_tob (TU) + max_toa (TU)". Finally, when MCC calculates pattern parameters based on these kinds of time limits, it might not perform well. Fixes: b09df09b55fb ("wifi: rtw89: mcc: initialize start flow") Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250103074412.124066-1-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08wifi: rtw89: avoid to init mgnt_entry list twice when WoWLAN failedChih-Kang Chang
[ Upstream commit 2f7667675df1b40b73ecc53b4b8c3189b1e5f2c1 ] If WoWLAN failed in resume flow, the rtw89_ops_add_interface() triggered without removing the interface first. Then the mgnt_entry list init again, causing the list_empty() check in rtw89_chanctx_ops_assign_vif() useless, and list_add_tail() again. Therefore, we have added a check to prevent double adding of the list. rtw89_8852ce 0000:01:00.0: failed to check wow status disabled rtw89_8852ce 0000:01:00.0: wow: failed to check disable fw ready rtw89_8852ce 0000:01:00.0: wow: failed to swap to normal fw rtw89_8852ce 0000:01:00.0: failed to disable wow rtw89_8852ce 0000:01:00.0: failed to resume for wow -110 rtw89_8852ce 0000:01:00.0: MAC has already powered on i2c_hid_acpi i2c-ILTK0001:00: PM: acpi_subsys_resume+0x0/0x60 returned 0 after 284705 usecs list_add corruption. prev->next should be next (ffff9d9719d82228), but was ffff9d9719f96030. (prev=ffff9d9719f96030). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:34! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 2 PID: 6918 Comm: kworker/u8:19 Tainted: G U O Hardware name: Google Anraggar/Anraggar, BIOS Google_Anraggar.15217.514.0 03/25/2024 Workqueue: events_unbound async_run_entry_fn RIP: 0010:__list_add_valid_or_report+0x9f/0xb0 Code: e8 56 89 ff ff 0f 0b 48 c7 c7 3e fc e0 96 48 89 c6 e8 45 89 ff ... RSP: 0018:ffffa51b42bbbaf0 EFLAGS: 00010246 RAX: 0000000000000075 RBX: ffff9d9719d82ab0 RCX: 13acb86e047a4400 RDX: 3fffffffffffffff RSI: 0000000000000000 RDI: 00000000ffffdfff RBP: ffffa51b42bbbb28 R08: ffffffff9768e250 R09: 0000000000001fff R10: ffffffff9765e250 R11: 0000000000005ffd R12: ffff9d9719f95c40 R13: ffff9d9719f95be8 R14: ffff9d97081bfd78 R15: ffff9d9719d82060 FS: 0000000000000000(0000) GS:ffff9d9a6fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007e7d029a4060 CR3: 0000000345e38000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: <TASK> ? __die_body+0x68/0xb0 ? die+0xaa/0xd0 ? do_trap+0x9f/0x170 ? __list_add_valid_or_report+0x9f/0xb0 ? __list_add_valid_or_report+0x9f/0xb0 ? handle_invalid_op+0x69/0x90 ? __list_add_valid_or_report+0x9f/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x9f/0xb0 rtw89_chanctx_ops_assign_vif+0x1f9/0x210 [rtw89_core cbb375c44bf28564ce479002bff66617a25d9ac1] ? __mutex_unlock_slowpath+0xa0/0xf0 rtw89_ops_assign_vif_chanctx+0x4b/0x90 [rtw89_core cbb375c44bf28564ce479002bff66617a25d9ac1] drv_assign_vif_chanctx+0xa7/0x1f0 [mac80211 6efaad16237edaaea0868b132d4f93ecf918a8b6] ieee80211_reconfig+0x9cb/0x17b0 [mac80211 6efaad16237edaaea0868b132d4f93ecf918a8b6] ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed] ? dev_printk_emit+0x51/0x70 ? _dev_info+0x6e/0x90 wiphy_resume+0x89/0x180 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed] ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed] dpm_run_callback+0x37/0x1e0 device_resume+0x26d/0x4b0 ? __pfx_dpm_watchdog_handler+0x10/0x10 async_resume+0x1d/0x30 async_run_entry_fn+0x29/0xd0 worker_thread+0x397/0x970 kthread+0xed/0x110 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x38/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Fixes: 68ec751b2881 ("wifi: rtw89: chan: manage active interfaces") Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250103024500.14990-1-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08wifi: rtw89: chan: fix soft lockup in rtw89_entity_recalc_mgnt_roles()Zong-Zhe Yang
[ Upstream commit e4790b3e314a4814f1680a5dc552031fb199b878 ] During rtw89_entity_recalc_mgnt_roles(), there is a normalizing process which will re-order the list if an entry with target pattern is found. And once one is found, should have aborted the list_for_each_entry. But, `break` just aborted the inner for-loop. The outer list_for_each_entry still continues. Normally, only the first entry will match the target pattern, and the re-ordering will change nothing, so there won't be soft lockup. However, in some special cases, soft lockup would happen. Fix it by `goto fill` to break from the list_for_each_entry. The following is a sample of kernel log for this problem. watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [wpa_supplicant:2055] [...] RIP: 0010:rtw89_entity_recalc ([...] chan.c:392 chan.c:479) rtw89_core [...] Fixes: 68ec751b2881 ("wifi: rtw89: chan: manage active interfaces") Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241231004811.8646-3-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08wifi: rtw89: fix proceeding MCC with wrong scanning state after sequence changesZong-Zhe Yang
[ Upstream commit e47f0a5898540eb19b953708707887d4b3020645 ] When starting/proceeding MCC, it will abort an ongoing hw scan process. In the proceeding cases, it unexpectedly tries to abort a non-exist hw scan process. Then, a trace shown at the bottom will happen. This problem is caused by a previous commit which changed some call sequence inside rtw89_hw_scan_complete() to fix some coex problems. These changes lead to our scanning flag was not cleared when proceeding MCC. To keep the fixes on coex, and resolve the problem here, re-consider the related call sequence. The known sequence requirements are listed below. * the old sequence: A. notify coex B. clear scanning flag C. proceed chanctx C-1. set channel C-2. proceed MCC (the problem: A needs to be after C-1) * the current sequence: C. proceed chanctx C-1. set channel C-2. proceed MCC A. notify coex B. clear scanning flag (the problem: C-2 needs to be after B) So, now let hw scan caller pass a callback to proceed chanctx if needed. Then, the new sequence will be like the below. C-1. set channel A. notify coex B. clear scanning flag C-2. proceed MCC The following is the kernel log for the problem in current sequence. rtw89_8852be 0000:04:00.0: rtw89_hw_scan_offload failed ret -110 ------------[ cut here ]------------ [...] CPU: 2 PID: 3991 Comm: kworker/u16:0 Tainted: G OE 6.6.17 #3 Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018 Workqueue: events_unbound wiphy_work_cancel [cfg80211] RIP: 0010:ieee80211_sched_scan_stopped+0xaea/0xd80 [mac80211] Code: 9c 24 d0 11 00 00 49 39 dd 0f 85 46 ff ff ff 4c 89 e7 e8 09 2d RSP: 0018:ffffb27783643d48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff8a2280964bc0 RSI: 0000000000000000 RDI: ffff8a23df580900 RBP: ffffb27783643d88 R08: 0000000000000001 R09: 0000000000000400 R10: 0000000000000000 R11: 0000000000008268 R12: ffff8a23df580900 R13: ffff8a23df581b00 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8a258e680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f26a0654000 CR3: 000000002ea2e002 CR4: 00000000001706e0 Call Trace: <TASK> ? show_regs+0x68/0x70 ? ieee80211_sched_scan_stopped+0xaea/0xd80 [mac80211] ? __warn+0x8f/0x150 ? ieee80211_sched_scan_stopped+0xaea/0xd80 [mac80211] ? report_bug+0x1f5/0x200 ? handle_bug+0x46/0x80 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? ieee80211_sched_scan_stopped+0xaea/0xd80 [mac80211] ieee80211_scan_work+0x14a/0x650 [mac80211] ? __queue_work+0x10f/0x410 wiphy_work_cancel+0x2fb/0x310 [cfg80211] process_scheduled_works+0x9d/0x390 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x15b/0x2d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x108/0x140 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> ---[ end trace 0000000000000000 ]--- Fixes: f16c40acd319 ("wifi: rtw89: Fix TX fail with A2DP after scanning") Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241231004811.8646-2-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08wifi: rtw89: tweak setting of channel and TX power for MLOZong-Zhe Yang
[ Upstream commit 2305ebc1835b1ca921045b4f0941e82edde3249b ] Setting of channel and TX power depend on channel contexts, but original code cannot handle combination of MCC (multi-channel concurrency) and MLO well. So according to active interfaces, we generate a table for current channel contexts. And then based on entity mode, we get the corresponding channel context to apply during channel or TX power setting. When MLO is supported, there will be dual-PHY and we will apply the channel context of the 2nd link to the 2nd PHY. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241022083106.149252-5-pkshih@realtek.com Stable-dep-of: e47f0a589854 ("wifi: rtw89: fix proceeding MCC with wrong scanning state after sequence changes") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08wifi: rtw89: chan: manage active interfacesZong-Zhe Yang
[ Upstream commit 68ec751b288178de7d19b71ea61648269a35b8cd ] To set channel well for combination of MCC (multi-channel concurrency) and impending MLO support, we need a method to manage relation between active interfaces and channel contexts. If an interface owns at least one active link, we call it an active interface. We add a list to manage active ones. Basically, the list follows the active order except for the below case. To be compatible with legacy behavior, the first interface that owns the first channel context will put at the first entry in the list when recalculating. Besides, MCC can also select and fill roles based on the above active list. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241022083106.149252-4-pkshih@realtek.com Stable-dep-of: e47f0a589854 ("wifi: rtw89: fix proceeding MCC with wrong scanning state after sequence changes") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08wifi: rtw89: handle entity active flag per PHYZong-Zhe Yang
[ Upstream commit ad95bb3b92c65849a6101402197e2cbeb2910a4a ] Originally, we have an active flag to record whether we have set PHY once. After impending MLO support, there will be dual-PHY and they can be set individually on Wi-Fi 7 chips. So, we now have active flag per PHY and handle them individually. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240925020119.13170-3-pkshih@realtek.com Stable-dep-of: e47f0a589854 ("wifi: rtw89: fix proceeding MCC with wrong scanning state after sequence changes") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08wifi: rtlwifi: pci: wait for firmware loading before releasing memoryThadeu Lima de Souza Cascardo
[ Upstream commit b59b86c5d08be7d761c04affcbcec8184738c200 ] At probe error path, the firmware loading work may have already been queued. In such a case, it will try to access memory allocated by the probe function, which is about to be released. In such paths, wait for the firmware worker to finish before releasing memory. Fixes: 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory") Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241206173713.3222187-5-cascardo@igalia.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08wifi: rtlwifi: fix memory leaks and invalid access at probe error pathThadeu Lima de Souza Cascardo
[ Upstream commit e7ceefbfd8d447abc8aca8ab993a942803522c06 ] Deinitialize at reverse order when probe fails. When init_sw_vars fails, rtl_deinit_core should not be called, specially now that it destroys the rtl_wq workqueue. And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be leaked. Remove pci_set_drvdata call as it will already be cleaned up by the core driver code and could lead to memory leaks too. cf. commit 8d450935ae7f ("wireless: rtlwifi: remove unnecessary pci_set_drvdata()") and commit 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory"). Fixes: 0c8173385e54 ("rtl8192ce: Add new driver") Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241206173713.3222187-4-cascardo@igalia.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08wifi: rtlwifi: destroy workqueue at rtl_deinit_coreThadeu Lima de Souza Cascardo
[ Upstream commit d8ece6fc3694657e4886191b32ca1690af11adda ] rtl_wq is allocated at rtl_init_core, so it makes more sense to destroy it at rtl_deinit_core. In the case of USB, where _rtl_usb_init does not require anything to be undone, that is fine. But for PCI, rtl_pci_init, which is called after rtl_init_core, needs to deallocate data, but only if it has been called. That means that destroying the workqueue needs to be done whether rtl_pci_init has been called or not. And since rtl_pci_deinit was doing it, it has to be moved out of there. It makes more sense to move it to rtl_deinit_core and have it done in both cases, USB and PCI. Since this is a requirement for a followup memory leak fix, mark this as fixing such memory leak. Fixes: 0c8173385e54 ("rtl8192ce: Add new driver") Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241206173713.3222187-3-cascardo@igalia.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08wifi: rtlwifi: remove unused check_buddy_privThadeu Lima de Souza Cascardo
[ Upstream commit 2fdac64c3c35858aa8ac5caa70b232e03456e120 ] Commit 2461c7d60f9f ("rtlwifi: Update header file") introduced a global list of private data structures. Later on, commit 26634c4b1868 ("rtlwifi Modify existing bits to match vendor version 2013.02.07") started adding the private data to that list at probe time and added a hook, check_buddy_priv to find the private data from a similar device. However, that function was never used. Besides, though there is a lock for that list, it is never used. And when the probe fails, the private data is never removed from the list. This would cause a second probe to access freed memory. Remove the unused hook, structures and members, which will prevent the potential race condition on the list and its corruption during a second probe when probe fails. Fixes: 26634c4b1868 ("rtlwifi Modify existing bits to match vendor version 2013.02.07") Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241206173713.3222187-2-cascardo@igalia.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08wifi: rtlwifi: usb: fix workqueue leak when probe failsThadeu Lima de Souza Cascardo
[ Upstream commit f79bc5c67867c19ce2762e7934c20dbb835ed82c ] rtl_init_core creates a workqueue that is then assigned to rtl_wq. rtl_deinit_core does not destroy it. It is left to rtl_usb_deinit, which must be called in the probe error path. Fixes: 2ca20f79e0d8 ("rtlwifi: Add usb driver") Fixes: 851639fdaeac ("rtlwifi: Modify some USB de-initialize code.") Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241107133322.855112-6-cascardo@igalia.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08wifi: rtlwifi: fix init_sw_vars leak when probe failsThadeu Lima de Souza Cascardo
[ Upstream commit 00260350aed80c002df270c805ca443ec9a719a6 ] If ieee80211_register_hw fails, the memory allocated for the firmware will not be released. Call deinit_sw_vars as the function that undoes the allocationes done by init_sw_vars. Fixes: cefe3dfdb9f5 ("rtl8192cu: Call ieee80211_register_hw from rtl_usb_probe") Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241107133322.855112-5-cascardo@igalia.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08wifi: rtlwifi: wait for firmware loading before releasing memoryThadeu Lima de Souza Cascardo
[ Upstream commit b4b26642b31ef282df6ff7ea8531985edfdef12a ] At probe error path, the firmware loading work may have already been queued. In such a case, it will try to access memory allocated by the probe function, which is about to be released. In such paths, wait for the firmware worker to finish before releasing memory. Fixes: a7f7c15e945a ("rtlwifi: rtl8192cu: Free ieee80211_hw if probing fails") Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241107133322.855112-4-cascardo@igalia.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08wifi: rtlwifi: rtl8192se: rise completion of firmware loading as last stepThadeu Lima de Souza Cascardo
[ Upstream commit 8559a9e0c457729fe3edb3176bbf7c7874f482b0 ] Just like in commit 4dfde294b979 ("rtlwifi: rise completion at the last step of firmware callback"), only signal completion once the function is finished. Otherwise, the module removal waiting for the completion could free the memory that the callback will still use before returning. Fixes: b0302aba812b ("rtlwifi: Convert to asynchronous firmware load") Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241107133322.855112-3-cascardo@igalia.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08wifi: rtlwifi: do not complete firmware loading needlesslyThadeu Lima de Souza Cascardo
[ Upstream commit e73e11d303940119e41850a0452a0deda2cc4eb5 ] The only code waiting for completion is driver removal, which will not be called when probe returns a failure. So this completion is unnecessary. Fixes: b0302aba812b ("rtlwifi: Convert to asynchronous firmware load") Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241107133322.855112-2-cascardo@igalia.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08wifi: rtlwifi: rtl8821ae: phy: restore removed code to fix infinite loopColin Ian King
[ Upstream commit 5e5903a442bb889a62a0f5d89ac33e53ab08592c ] A previous clean-up fix removed the assignment of v2 inside a while loop that turned it into an infinite loop. Fix this by restoring the assignment of v2 from array[] so that v2 is updated inside the loop. Fixes: cda37445718d ("wifi: rtlwifi: rtl8821ae: phy: remove some useless code") Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Tested-by: Ping-Ke Shih <pkshih@realtek.com> Reviewed-by: Su Hui <suhui@nfschina.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241106154642.1627886-1-colin.i.king@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-01wifi: rtl8xxxu: add more missing rtl8192cu USB IDsHans de Goede
commit 31be3175bd7be89e39c82b3973c9d4ff55a17583 upstream. The rtl8xxxu has all the rtl8192cu USB IDs from rtlwifi/rtl8192cu/sw.c except for the following 10, add these to the untested section so they can be used with the rtl8xxxu as the rtl8192cu are well supported. This fixes these wifi modules not working on distributions which have disabled CONFIG_RTL8192CU replacing it with CONFIG_RTL8XXXU_UNTESTED, like Fedora. Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2321540 Cc: stable@vger.kernel.org Cc: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241107140833.274986-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-12-14wifi: rtw89: check return value of ieee80211_probereq_get() for RNRPing-Ke Shih
[ Upstream commit 630d5d8f2bf6b340202b6bc2c05d794bbd8e4c1c ] The return value of ieee80211_probereq_get() might be NULL, so check it before using to avoid NULL pointer access. Addresses-Coverity-ID: 1529805 ("Dereference null return value") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240919081216.28505-2-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-14wifi: rtw88: use ieee80211_purge_tx_queue() to purge TX skbPing-Ke Shih
[ Upstream commit 3e5e4a801aaf4283390cc34959c6c48f910ca5ea ] When removing kernel modules by: rmmod rtw88_8723cs rtw88_8703b rtw88_8723x rtw88_sdio rtw88_core Driver uses skb_queue_purge() to purge TX skb, but not report tx status causing "Have pending ack frames!" warning. Use ieee80211_purge_tx_queue() to correct this. Since ieee80211_purge_tx_queue() doesn't take locks, to prevent racing between TX work and purge TX queue, flush and destroy TX work in advance. wlan0: deauthenticating from aa:f5:fd:60:4c:a8 by local choice (Reason: 3=DEAUTH_LEAVING) ------------[ cut here ]------------ Have pending ack frames! WARNING: CPU: 3 PID: 9232 at net/mac80211/main.c:1691 ieee80211_free_ack_frame+0x5c/0x90 [mac80211] CPU: 3 PID: 9232 Comm: rmmod Tainted: G C 6.10.1-200.fc40.aarch64 #1 Hardware name: pine64 Pine64 PinePhone Braveheart (1.1)/Pine64 PinePhone Braveheart (1.1), BIOS 2024.01 01/01/2024 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ieee80211_free_ack_frame+0x5c/0x90 [mac80211] lr : ieee80211_free_ack_frame+0x5c/0x90 [mac80211] sp : ffff80008c1b37b0 x29: ffff80008c1b37b0 x28: ffff000003be8000 x27: 0000000000000000 x26: 0000000000000000 x25: ffff000003dc14b8 x24: ffff80008c1b37d0 x23: ffff000000ff9f80 x22: 0000000000000000 x21: 000000007fffffff x20: ffff80007c7e93d8 x19: ffff00006e66f400 x18: 0000000000000000 x17: ffff7ffffd2b3000 x16: ffff800083fc0000 x15: 0000000000000000 x14: 0000000000000000 x13: 2173656d61726620 x12: 6b636120676e6964 x11: 0000000000000000 x10: 000000000000005d x9 : ffff8000802af2b0 x8 : ffff80008c1b3430 x7 : 0000000000000001 x6 : 0000000000000001 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000003be8000 Call trace: ieee80211_free_ack_frame+0x5c/0x90 [mac80211] idr_for_each+0x74/0x110 ieee80211_free_hw+0x44/0xe8 [mac80211] rtw_sdio_remove+0x9c/0xc0 [rtw88_sdio] sdio_bus_remove+0x44/0x180 device_remove+0x54/0x90 device_release_driver_internal+0x1d4/0x238 driver_detach+0x54/0xc0 bus_remove_driver+0x78/0x108 driver_unregister+0x38/0x78 sdio_unregister_driver+0x2c/0x40 rtw_8723cs_driver_exit+0x18/0x1000 [rtw88_8723cs] __do_sys_delete_module.isra.0+0x190/0x338 __arm64_sys_delete_module+0x1c/0x30 invoke_syscall+0x74/0x100 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x158 el0t_64_sync_handler+0x120/0x138 el0t_64_sync+0x194/0x198 ---[ end trace 0000000000000000 ]--- Reported-by: Peter Robinson <pbrobinson@gmail.com> Closes: https://lore.kernel.org/linux-wireless/CALeDE9OAa56KMzgknaCD3quOgYuEHFx9_hcT=OFgmMAb+8MPyA@mail.gmail.com/ Tested-by: Ping-Ke Shih <pkshih@realtek.com> # 8723DU Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240822014255.10211-2-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-05wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failuresGuilherme G. Piccoli
commit 5c1b544563005a00591a3aa86ecff62ed4d11be3 upstream. Syzkaller reported a hung task with uevent_show() on stack trace. That specific issue was addressed by another commit [0], but even with that fix applied (for example, running v6.12-rc5) we face another type of hung task that comes from the same reproducer [1]. By investigating that, we could narrow it to the following path: (a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and dummy_hcd infrastructure. (b) During the probe of rtl8192cu, the driver ends-up performing an efuse read procedure (which is related to EEPROM load IIUC), and here lies the issue: the function read_efuse() calls read_efuse_byte() many times, as loop iterations depending on the efuse size (in our example, 512 in total). This procedure for reading efuse bytes relies in a loop that performs an I/O read up to *10k* times in case of failures. We measured the time of the loop inside read_efuse_byte() alone, and in this reproducer (which involves the dummy_hcd emulation layer), it takes 15 seconds each. As a consequence, we have the driver stuck in its probe routine for big time, exposing a stack trace like below if we attempt to reboot the system, for example: task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000 Workqueue: usb_hub_wq hub_event Call Trace: __schedule+0xe22/0xeb6 schedule_timeout+0xe7/0x132 __wait_for_common+0xb5/0x12e usb_start_wait_urb+0xc5/0x1ef ? usb_alloc_urb+0x95/0xa4 usb_control_msg+0xff/0x184 _usbctrl_vendorreq_sync+0xa0/0x161 _usb_read_sync+0xb3/0xc5 read_efuse_byte+0x13c/0x146 read_efuse+0x351/0x5f0 efuse_read_all_map+0x42/0x52 rtl_efuse_shadow_map_update+0x60/0xef rtl_get_hwinfo+0x5d/0x1c2 rtl92cu_read_eeprom_info+0x10a/0x8d5 ? rtl92c_read_chip_version+0x14f/0x17e rtl_usb_probe+0x323/0x851 usb_probe_interface+0x278/0x34b really_probe+0x202/0x4a4 __driver_probe_device+0x166/0x1b2 driver_probe_device+0x2f/0xd8 [...] We propose hereby to drastically reduce the attempts of doing the I/O reads in case of failures, restricted to USB devices (given that they're inherently slower than PCIe ones). By retrying up to 10 times (instead of 10000), we got reponsiveness in the reproducer, while seems reasonable to believe that there's no sane USB device implementation in the field requiring this amount of retries at every I/O read in order to properly work. Based on that assumption, it'd be good to have it backported to stable but maybe not since driver implementation (the 10k number comes from day 0), perhaps up to 6.x series makes sense. [0] Commit 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race") [1] A note about that: this syzkaller report presents multiple reproducers that differs by the type of emulated USB device. For this specific case, check the entry from 2024/08/08 06:23 in the list of crashes; the C repro is available at https://syzkaller.appspot.com/text?tag=ReproC&x=1521fc83980000. Cc: stable@vger.kernel.org # v6.1+ Reported-by: syzbot+edd9fe0d3a65b14588d5@syzkaller.appspotmail.com Tested-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241101193412.1390391-1-gpiccoli@igalia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-12-05wifi: rtw89: coex: check NULL return of kmalloc in btc_fw_set_monreg()Pei Xiao
[ Upstream commit 81df5ed446b448bdc327b7c7f0b50121fc1f4aa2 ] kmalloc may fail, return value might be NULL and will cause NULL pointer dereference. Add check NULL return of kmalloc in btc_fw_set_monreg(). Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> Fixes: b952cb0a6e2d ("wifi: rtw89: coex: Add register monitor report v7 format") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/516a91f3997534f708af43c7592cbafdd53dd599.1730253508.git.xiaopei01@kylinos.cn Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-05wifi: rtw89: unlock on error path in rtw89_ops_unassign_vif_chanctx()Dan Carpenter
[ Upstream commit ac4f4e5a203927e555107db6e781e85f241720e1 ] We need to call mutex_unlock() on this error path. Fixes: aad0394e7a02 ("wifi: rtw89: tweak driver architecture for impending MLO support") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/8683a712-ffc2-466b-8382-0b264719f8ef@stanley.mountain Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-05wifi: rtw89: Fix TX fail with A2DP after scanningPo-Hao Huang
[ Upstream commit f16c40acd31901ad0ba2554b60e0e2b0c7b59cde ] There might be some racing between BT and WiFi after scan. Since one of the TX related register will be modified by both FW and rtw89_set_channel() in driver, which could cause Tx fail. Reorder the calling sequence to only notify coexistence mechanism after rtw89_set_channel() is called, so that there are no concurrent operations. Fixes: 5f499ce69b8d ("wifi: rtw89: pause/proceed MCC for ROC and HW scan") Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241021063219.22613-1-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-05wifi: rtw89: tweak driver architecture for impending MLO supportZong-Zhe Yang
[ Upstream commit aad0394e7a02fe933159be79d9d4595d2ad089dd ] The drv_priv hooked to mac80211 become as below. (drv_priv) (instance-0) +---------------+ +-----------+ +----------------+ | ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link | +---------------+ +-----------+ | +----------------+ | | (instance-1) | +----------------+ +---> | rtw89_vif_link | +----------------+ (drv_priv) (instance-0) +---------------+ +-----------+ +----------------+ | ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link | +---------------+ +-----------+ | +----------------+ | | (instance-1) | +----------------+ +---> | rtw89_sta_link | +----------------+ The relation bewteen mac80211 link_id and our link instance is like below. |\ (link_id) | \ 0 -------- | | 1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0 2 -------- | | ... | | ------ instance-1 (link_id: Y) -> work on HW band 1 14 -------- | | | / |/ N.B. For cases of non-MLD connection, we set our link instance-0 active with link_id 0. So, our code flow can be compatible between non-MLD connection and MLD connection. Based on above, we tweak entire driver architecture first. But, we don't dynamically enable multiple links here. That will be handled separately. Most of the things changed here are changing flows to iterate all active links and read bss_conf/link_sta data according to target link. And, for cases of scan, ROC, WOW, we use instance-0 to deal with the request. There are some things listed below, which work for now but need to extend before multiple active links. 1. tx path select suitable link instance among multiple active links 2. rx path determine rx link by PPDU instead of always link instance-0 3. CAM apply MLD pairwise key to any active links dynamically Besides, PS code cannot easily work along with tweaking architecture. With supporting MLO flag (currently false), we disable PS first and will fix it by another commit in the following. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com Stable-dep-of: f16c40acd319 ("wifi: rtw89: Fix TX fail with A2DP after scanning") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-05wifi: rtw89: refactor STA related func ahead for MLOZong-Zhe Yang
[ Upstream commit 72e9457c1954dc39a7059bd6d6346b60a24aa55e ] Refactor STA related functions, e.g. add/assoc/disassoc/disconnect/remove to separate most link stuffs into sub-functions for MLO reuse. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240916053158.47350-7-pkshih@realtek.com Stable-dep-of: f16c40acd319 ("wifi: rtw89: Fix TX fail with A2DP after scanning") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-05wifi: rtw89: refactor VIF related func ahead for MLOZong-Zhe Yang
[ Upstream commit 26d460e13f84426fa7dd2c0c369676034c206161 ] Refactor VIF related functions, e.g. add/remove/assoc/mapping to separate most link stuffs into sub-functions for MLO reuse. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240916053158.47350-6-pkshih@realtek.com Stable-dep-of: f16c40acd319 ("wifi: rtw89: Fix TX fail with A2DP after scanning") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-05wifi: rtw89: read link_sta corresponding to the linkZong-Zhe Yang
[ Upstream commit 04911c0fe874bb44e8ee0f5896a5a10c37a14cf2 ] Tweak code to not always access sta->deflink directly. Instead, according to link_id, read target link_sta from sta->link[]. For now, rtwsta_link->link_id keeps 0. When driver starts to support MLO, the link_id will be assigned. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240916053158.47350-5-pkshih@realtek.com Stable-dep-of: f16c40acd319 ("wifi: rtw89: Fix TX fail with A2DP after scanning") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-05wifi: rtw89: read bss_conf corresponding to the linkZong-Zhe Yang
[ Upstream commit 89bac818bbd2ccced29d4b888ba1a4cf3e1ede4e ] Tweak code to not always access vif->bss_conf directly. Instead, according to link_id, read target bss_conf from vif->link_conf[]. For now, rtwvif_link->link_id keeps 0. When driver starts to support MLO, the link_id will be assigned. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240916053158.47350-4-pkshih@realtek.com Stable-dep-of: f16c40acd319 ("wifi: rtw89: Fix TX fail with A2DP after scanning") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-05wifi: rtw89: rename rtw89_sta to rtw89_sta_link ahead for MLOZong-Zhe Yang
[ Upstream commit 9ee282193440527a20c9b40d47db8abaa73ecd49 ] This is an intermediate version that is separated from subsequent major MLO changes, so some functions' namings are not really determined here. e.g. struct rtw89_sta_link *sta_to_rtwsta_safe(struct ieee80211_sta *sta) No logic is changed. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240916053158.47350-3-pkshih@realtek.com Stable-dep-of: f16c40acd319 ("wifi: rtw89: Fix TX fail with A2DP after scanning") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-05wifi: rtw89: rename rtw89_vif to rtw89_vif_link ahead for MLOZong-Zhe Yang
[ Upstream commit 2f7dae17c48cd1d5616f11d22b3de675db7ab40d ] This is an intermediate version that is separated from subsequent major MLO changes, so some functions' namings are not really determined here. e.g. struct rtw89_vif_link *vif_to_rtwvif_safe(struct ieee80211_vif *vif) No logic is changed. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240916053158.47350-2-pkshih@realtek.com Stable-dep-of: f16c40acd319 ("wifi: rtw89: Fix TX fail with A2DP after scanning") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-05wifi: rtl8xxxu: Perform update_beacon_work when beaconing is enabledMartin Kaistra
[ Upstream commit d7063ed6758c62e00a2f56467ded85a021fac67a ] In STA+AP concurrent mode, performing a scan operation on one vif temporarily stops beacons on the other. When the scan is completed, beacons are enabled again with BSS_CHANGED_BEACON_ENABLED. We can observe that no beacons are being sent when just rtl8xxxu_start_tx_beacon() is being called. Thus, also perform update_beacon_work in order to restore beaconing. Fixes: cde8848cad0b ("wifi: rtl8xxxu: Add beacon functions") Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240930084955.455241-1-martin.kaistra@linutronix.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-17wifi: rtlwifi: rtl8192du: Don't claim USB ID 0bda:8171Bitterblue Smith
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 <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/40245564-41fe-4a5e-881f-cd517255b20a@gmail.com
2024-10-17wifi: rtw88: Fix the RX aggregation in USB 3 modeBitterblue Smith
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 <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/afb94a82-3d18-459e-97fc-1a217608cdf0@gmail.com
2024-10-17wifi: rtw89: pci: early chips only enable 36-bit DMA on specific PCI hostsPing-Ke Shih
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 <mweissenbach@ignaz.org> Closes: https://lore.kernel.org/linux-wireless/20240918073237.Horde.VLueh0_KaiDw-9asEEcdM84@ignaz.org/T/#m07c5694df1acb173a42e1a0bab7ac22bd231a2b8 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Marcel Weißenbach <mweissenbach@ignaz.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240924021633.19861-1-pkshih@realtek.com
2024-09-18wifi: rtw89: coex: add debug message of link counts on 2/5GHz bands for ↵Ping-Ke Shih
wl_info v7 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 <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240912021626.10494-1-pkshih@realtek.com
2024-09-09Merge tag 'rtw-next-2024-09-05' of https://github.com/pkshih/rtwKalle Valo
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
2024-09-05wifi: rtw89: avoid reading out of bounds when loading TX power FW elementsZong-Zhe Yang
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 <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240902015803.20420-1-pkshih@realtek.com
2024-09-05wifi: rtw89: use frequency domain RSSIEric Huang
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 <echuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240828055217.10263-3-pkshih@realtek.com
2024-09-05wifi: rtw89: adjust DIG threshold to reduce false alarmEric Huang
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 <echuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240828055217.10263-2-pkshih@realtek.com
2024-09-04Merge tag 'wireless-next-2024-09-04' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next 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 <kuba@kernel.org>
2024-09-02wifi: rtw89: wow: add scan interval option for net-detectChin-Yen Lee
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 <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240826090439.17242-5-pkshih@realtek.com
2024-09-02wifi: rtw89: wow: add net-detect support for 8922aeChin-Yen Lee
Enable net-detect in WoWLAN stub of 8922a, and declare net-detect support up to 8 SSIDs. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240826090439.17242-4-pkshih@realtek.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-05 14:35:08 +0000