aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/wireless/realtek (follow)
AgeCommit message (Collapse)AuthorFilesLines
2025-09-22Merge tag 'rtw-next-2025-09-22' of https://github.com/pkshih/rtwJohannes Berg47-401/+2583
Ping-Ke Shih says: ================== rtw-next patches for v6.18 Some small fixes and features are listed: rtw88: * correct LED function rtw89: * fix wait/completion racing of sending NULL data * implement beacon tracking feature * implement report channel noise function supported by RTL8852A * correct RTL8851B RF calibration * preparation of PCI TX/RX ring and interrupts for coming RTL8922DE ================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-22wifi: rtw89: avoid circular locking dependency in ser_state_run()Fedor Pchelkin1-2/+1
Lockdep gives a splat [1] when ser_hdl_work item is executed. It is scheduled at mac80211 workqueue via ieee80211_queue_work() and takes a wiphy lock inside. However, this workqueue can be flushed when e.g. closing the interface and wiphy lock is already taken in that case. Choosing wiphy_work_queue() for SER is likely not suitable. Back on to the global workqueue. [1]: WARNING: possible circular locking dependency detected 6.17.0-rc2 #17 Not tainted ------------------------------------------------------ kworker/u32:1/61 is trying to acquire lock: ffff88811bc00768 (&rdev->wiphy.mtx){+.+.}-{4:4}, at: ser_state_run+0x5e/0x180 [rtw89_core] but task is already holding lock: ffffc9000048fd30 ((work_completion)(&ser->ser_hdl_work)){+.+.}-{0:0}, at: process_one_work+0x7b5/0x1450 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 ((work_completion)(&ser->ser_hdl_work)){+.+.}-{0:0}: process_one_work+0x7c6/0x1450 worker_thread+0x49e/0xd00 kthread+0x313/0x640 ret_from_fork+0x221/0x300 ret_from_fork_asm+0x1a/0x30 -> #1 ((wq_completion)phy0){+.+.}-{0:0}: touch_wq_lockdep_map+0x8e/0x180 __flush_workqueue+0x129/0x10d0 ieee80211_stop_device+0xa8/0x110 ieee80211_do_stop+0x14ce/0x2880 ieee80211_stop+0x13a/0x2c0 __dev_close_many+0x18f/0x510 __dev_change_flags+0x25f/0x670 netif_change_flags+0x7b/0x160 do_setlink.isra.0+0x1640/0x35d0 rtnl_newlink+0xd8c/0x1d30 rtnetlink_rcv_msg+0x700/0xb80 netlink_rcv_skb+0x11d/0x350 netlink_unicast+0x49a/0x7a0 netlink_sendmsg+0x759/0xc20 ____sys_sendmsg+0x812/0xa00 ___sys_sendmsg+0xf7/0x180 __sys_sendmsg+0x11f/0x1b0 do_syscall_64+0xbb/0x360 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (&rdev->wiphy.mtx){+.+.}-{4:4}: __lock_acquire+0x124c/0x1d20 lock_acquire+0x154/0x2e0 __mutex_lock+0x17b/0x12f0 ser_state_run+0x5e/0x180 [rtw89_core] rtw89_ser_hdl_work+0x119/0x220 [rtw89_core] process_one_work+0x82d/0x1450 worker_thread+0x49e/0xd00 kthread+0x313/0x640 ret_from_fork+0x221/0x300 ret_from_fork_asm+0x1a/0x30 other info that might help us debug this: Chain exists of: &rdev->wiphy.mtx --> (wq_completion)phy0 --> (work_completion)(&ser->ser_hdl_work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&ser->ser_hdl_work)); lock((wq_completion)phy0); lock((work_completion)(&ser->ser_hdl_work)); lock(&rdev->wiphy.mtx); *** DEADLOCK *** 2 locks held by kworker/u32:1/61: #0: ffff888103835148 ((wq_completion)phy0){+.+.}-{0:0}, at: process_one_work+0xefa/0x1450 #1: ffffc9000048fd30 ((work_completion)(&ser->ser_hdl_work)){+.+.}-{0:0}, at: process_one_work+0x7b5/0x1450 stack backtrace: CPU: 0 UID: 0 PID: 61 Comm: kworker/u32:1 Not tainted 6.17.0-rc2 #17 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS edk2-20250523-14.fc42 05/23/2025 Workqueue: phy0 rtw89_ser_hdl_work [rtw89_core] Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 print_circular_bug.cold+0x178/0x1be check_noncircular+0x14c/0x170 __lock_acquire+0x124c/0x1d20 lock_acquire+0x154/0x2e0 __mutex_lock+0x17b/0x12f0 ser_state_run+0x5e/0x180 [rtw89_core] rtw89_ser_hdl_work+0x119/0x220 [rtw89_core] process_one_work+0x82d/0x1450 worker_thread+0x49e/0xd00 kthread+0x313/0x640 ret_from_fork+0x221/0x300 ret_from_fork_asm+0x1a/0x30 </TASK> Found by Linux Verification Center (linuxtesting.org). Fixes: ebfc9199df05 ("wifi: rtw89: add wiphy_lock() to work that isn't held wiphy_lock() yet") Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250919210852.823912-5-pchelkin@ispras.ru
2025-09-22wifi: rtw89: fix leak in rtw89_core_send_nullfunc()Fedor Pchelkin1-0/+1
If there is no rtwsta_link found in rtw89_core_send_nullfunc(), allocated skb is leaked. Free it on the error handling path. Found by Linux Verification Center (linuxtesting.org). Fixes: a8ba4acab7db ("wifi: rtw89: send nullfunc based on the given link") Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250919210852.823912-4-pchelkin@ispras.ru
2025-09-22wifi: rtw89: avoid possible TX wait initialization raceFedor Pchelkin3-20/+24
The value of skb_data->wait indicates whether skb is passed on to the core mac80211 stack or released by the driver itself. Make sure that by the time skb is added to txwd queue and becomes visible to the completing side, it has already allocated and initialized TX wait related data (in case it's needed). This is found by code review and addresses a possible race scenario described below: Waiting thread Completing thread rtw89_core_send_nullfunc() rtw89_core_tx_write_link() ... rtw89_pci_txwd_submit() skb_data->wait = NULL /* add skb to the queue */ skb_queue_tail(&txwd->queue, skb) /* another thread (e.g. rtw89_ops_tx) performs TX kick off for the same queue */ rtw89_pci_napi_poll() ... rtw89_pci_release_txwd_skb() /* get skb from the queue */ skb_unlink(skb, &txwd->queue) rtw89_pci_tx_status() rtw89_core_tx_wait_complete() /* use incorrect skb_data->wait */ rtw89_core_tx_kick_off_and_wait() /* assign skb_data->wait but too late */ Found by Linux Verification Center (linuxtesting.org). Fixes: 1ae5ca615285 ("wifi: rtw89: add function to wait for completion of TX skbs") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250919210852.823912-3-pchelkin@ispras.ru
2025-09-22wifi: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait()Fedor Pchelkin4-9/+61
There is a bug observed when rtw89_core_tx_kick_off_and_wait() tries to access already freed skb_data: BUG: KFENCE: use-after-free write in rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110 CPU: 6 UID: 0 PID: 41377 Comm: kworker/u64:24 Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS edk2-20250523-14.fc42 05/23/2025 Workqueue: events_unbound cfg80211_wiphy_work [cfg80211] Use-after-free write at 0x0000000020309d9d (in kfence-#251): rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.h:141 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758 process_one_work kernel/workqueue.c:3241 worker_thread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 kfence-#251: 0x0000000056e2393d-0x000000009943cb62, size=232, cache=skbuff_head_cache allocated by task 41377 on cpu 6 at 77869.159548s (0.009551s ago): __alloc_skb net/core/skbuff.c:659 __netdev_alloc_skb net/core/skbuff.c:734 ieee80211_nullfunc_get net/mac80211/tx.c:5844 rtw89_core_send_nullfunc drivers/net/wireless/realtek/rtw89/core.c:3431 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.c:3194 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758 process_one_work kernel/workqueue.c:3241 worker_thread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 freed by task 1045 on cpu 9 at 77869.168393s (0.001557s ago): ieee80211_tx_status_skb net/mac80211/status.c:1117 rtw89_pci_release_txwd_skb drivers/net/wireless/realtek/rtw89/pci.c:564 rtw89_pci_release_tx_skbs.isra.0 drivers/net/wireless/realtek/rtw89/pci.c:651 rtw89_pci_release_tx drivers/net/wireless/realtek/rtw89/pci.c:676 rtw89_pci_napi_poll drivers/net/wireless/realtek/rtw89/pci.c:4238 __napi_poll net/core/dev.c:7495 net_rx_action net/core/dev.c:7557 net/core/dev.c:7684 handle_softirqs kernel/softirq.c:580 do_softirq.part.0 kernel/softirq.c:480 __local_bh_enable_ip kernel/softirq.c:407 rtw89_pci_interrupt_threadfn drivers/net/wireless/realtek/rtw89/pci.c:927 irq_thread_fn kernel/irq/manage.c:1133 irq_thread kernel/irq/manage.c:1257 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 It is a consequence of a race between the waiting and the signaling side of the completion: Waiting thread Completing thread rtw89_core_tx_kick_off_and_wait() rcu_assign_pointer(skb_data->wait, wait) /* start waiting */ wait_for_completion_timeout() rtw89_pci_tx_status() rtw89_core_tx_wait_complete() rcu_read_lock() /* signals completion and * proceeds further */ complete(&wait->completion) rcu_read_unlock() ... /* frees skb_data */ ieee80211_tx_status_ni() /* returns (exit status doesn't matter) */ wait_for_completion_timeout() ... /* accesses the already freed skb_data */ rcu_assign_pointer(skb_data->wait, NULL) The completing side might proceed and free the underlying skb even before the waiting side is fully awoken and run to execution. Actually the race happens regardless of wait_for_completion_timeout() exit status, e.g. the waiting side may hit a timeout and the concurrent completing side is still able to free the skb. Skbs which are sent by rtw89_core_tx_kick_off_and_wait() are owned by the driver. They don't come from core ieee80211 stack so no need to pass them to ieee80211_tx_status_ni() on completing side. Introduce a work function which will act as a garbage collector for rtw89_tx_wait_info objects and the associated skbs. Thus no potentially heavy locks are required on the completing side. Found by Linux Verification Center (linuxtesting.org). Fixes: 1ae5ca615285 ("wifi: rtw89: add function to wait for completion of TX skbs") Cc: stable@vger.kernel.org Suggested-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250919210852.823912-2-pchelkin@ispras.ru
2025-09-18wifi: rtw89: wow: enable TKIP related featureChih-Kang Chang4-18/+74
For chips that supports TKIP HW encryption and decryption, enable TKIP cipher for WoWLAN feature. Additionally, the TX MIC KEY and RX MIC KEY is opposite in FW. Therefore, reverse the MIC KEY direction in H2C format, and also reverse it from AOAC report before reporting to mac80211. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065434.39324-1-pkshih@realtek.com
2025-09-18wifi: rtw89: 8922a: add TAS feature supportKuan-Chung Chen8-31/+119
Add TAS support for 8922AE. Unlike AX ICs, BE ICs introduce a TAS timer switch. The firmware starts a TAS timer to periodically collect TX power information and notify the driver via C2H events. To avoid unnecessary C2H events, the TAS timer is enabled during core_start(). Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065429.39269-1-pkshih@realtek.com
2025-09-18wifi: rtw89: open C2H event waiting window first before sending H2C commandZong-Zhe Yang3-14/+48
Some H2C commands need to wait for target C2H events to confirm they are executed well. The characteristics of a target C2H event will be encoded into a value, called condition. Then, the corresponding H2C command will wait for it. And, C2H events will complete a condition according to their own characteristics. So, when conditions of both side match, the corresponding H2C command will be completed. Originally, condition waiting window is opened after the H2C command is sent. However, for CPU-bound systems, target C2H event might be already done before the H2C command opens condition waiting window. Without that, C2H event won't match condition, and it will complete nothing. Finally, H2C command wait will time out. Hence, now open condition waiting window first for H2C commands which need to wait for target C2H events. The waiting function is split to two parts, prepare and evaluate. And, waiting side becomes the below where prepare part and evaluate part must be a pair. waiting prepare: condition (open condition waiting window) Do the needed things to trigger completing side. Record errors that will cause no real completer. waiting evaluate: prepare, errors (start waiting for completion if things are fine; otherwise, clean up and return final result.) Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065352.39082-1-pkshih@realtek.com
2025-09-18wifi: rtw89: renew a completion for each H2C command waiting C2H eventZong-Zhe Yang3-8/+53
Logically before a waiting side which has already timed out turns the atomic status back to idle, a completing side could still pass atomic condition and call complete. It will make the following H2C commands, waiting C2H events, get a completion unexpectedly early. Hence, renew a completion for each H2C command waiting a C2H event. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065343.39023-1-pkshih@realtek.com
2025-09-18wifi: rtw89: 8852b: enable beacon tracking supportKuan-Chung Chen1-0/+1
Enable beacon tracking support on 8852B to improve connection stability. 8852B firmware has supported the power level H2C since version 0.29.128. This H2C is one of the required elements for beacon tracking, allowing control of the maximum receive window while in power save mode. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065337.38966-1-pkshih@realtek.com
2025-09-18wifi: rtw89: debug: support SER L0 simulationZong-Zhe Yang2-1/+68
SER (system error recovery) can deal with different crash types by different levels of processes. Now, add a debug function to trigger MAC error in purpose for SER L0 simulation/verification. And, extend dbgfs fw_crash to accept different parameters. # simulate MAC error (one kind of SER L0) echo 3 > fw_crash Normally, FW won't report SER L0 cases to driver. Instead, they will be handled by FW directly. If unfortunately FW handling fails, SER will rise to L1 and be reported to driver. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065329.38911-1-pkshih@realtek.com
2025-09-18wifi: rtw89: phy: initialize AFE by firmware element tablePing-Ke Shih6-0/+140
A power-on sequence table is introduced to initialize AFE (Analogue Front End) connecting to RF components. Build the sequence in firmware file, and use a parser to execute the sequences including write/poll/delay actions. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065314.38846-1-pkshih@realtek.com
2025-09-18wifi: rtw89: obtain RX path from ppdu status IE00Chih-Kang Chang2-0/+5
The header v2 of ppdu status is optional, If it is not enabled, the RX path must be obtained from IE00 or IE01. Append the IE00 part. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065213.38659-5-pkshih@realtek.com
2025-09-18wifi: rtw89: disable RTW89_PHYSTS_IE09_FTR_0 for ppdu statusChih-Kang Chang1-2/+0
The IE length of RTW89_PHYSTS_IE09_FTR_0 is dynamic, need to calculate more to get it. This IE is not necessary now, disable it to avoid get wrong IE length to let the parse function check failed. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065213.38659-4-pkshih@realtek.com
2025-09-18wifi: rtw89: use ieee80211_tx_info::driver_data to store driver TX infoPing-Ke Shih2-5/+10
It makes more sense to use ieee80211_tx_info::driver_data instead of ieee80211_tx_info::status.status_driver_data which is used to share TX status reporting to mac80211, because actually driver calls ieee80211_tx_info_clear_status() to clear the content including status_driver_data in rtw89_pci_tx_status() before filling the status. Review and point out the scope (by comments) driver can safely use ieee80211_tx_info::driver_data between rtw89_hci_tx_write() and calling ieee80211_tx_info_clear_status(). Add BUILD_BUG_ON() to assert that driver struct size is smaller than the size defined by mac80211. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065213.38659-3-pkshih@realtek.com
2025-09-18wifi: rtw89: chan: allow callers to check if a link has no managed chanctxZong-Zhe Yang2-3/+18
Originally, to directly align with the chanctx design, getter of managed chanctx returned a default channel when a link doesn't own a chanctx yet. Then, callers could simply use the return without trivial NULL checking. But in MLD HW settings of next chip, there will be a special case that a caller needs to check if a link has owned chanctx or not to determine CCK hardware circuit working on HW-x. So, add a func *_or_null for this first. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065213.38659-2-pkshih@realtek.com
2025-09-09wifi: rtw89: Add USB ID 2001:3327 for D-Link AX18U rev. A1Zenm Chen1-0/+2
Add USB ID 2001:3327 for D-Link AX18U rev. A1 which is a RTL8832BU-based Wi-Fi adapter. Link: https://github.com/morrownr/rtw89/pull/17 Signed-off-by: Zenm Chen <zenmchen@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250903223100.3031-1-zenmchen@gmail.com
2025-09-09wifi: rtw89: Add USB ID 2001:332a for D-Link AX9U rev. A1Zenm Chen1-0/+3
Add USB ID 2001:332a for D-Link AX9U rev. A1 which is a RTL8851BU-based Wi-Fi adapter. Only managed mode and AP mode are tested and it works in both. Signed-off-by: Zenm Chen <zenmchen@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250902035755.1969530-1-zenmchen@gmail.com
2025-09-09wifi: rtl8xxxu: expose efuse via debugfsMartin Kaistra1-0/+22
The efuse contains the mac address and calibration data. During manufacturing and testing it can be necessary to read and check this data. Add a debugfs interface to make it available to userspace. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250901121613.1876109-1-martin.kaistra@linutronix.de
2025-09-04wifi: mac80211: support parsing S1G TIM PVBLachlan Hodges1-1/+1
An S1G TIM PVB has 3 mandatory encoding modes, that being block bitmap, single AID and OBL alongside the ability for each encoding mode to be inverted. Introduce the ability to parse the 3 encoding formats. The implementation specification for the encoding formats can be found in IEEE80211-2024 9.4.2.5. Signed-off-by: Arien Judge <arien.judge@morsemicro.com> Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20250725132221.258217-3-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-01wifi: rtw89: 8852bt: Remove redundant off_reverse variablesLiao Yuanhong1-6/+1
The variable off_reverse and its related code are completely redundant in the function. Remove them to clean the code. Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250828094717.599527-1-liaoyuanhong@vivo.com
2025-09-01wifi: rtw89: use int type to store negative error codesQianfeng Rong3-15/+16
The 'ret' variable stores returns from other functions, which return either zero on success or negative error codes on failure. Storing error codes in u32 (an unsigned type) causes no runtime issues but is stylistically inconsistent and very ugly. Change 'ret' from u32 to int - this has no runtime impact. Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250827150620.550641-1-rongqianfeng@vivo.com
2025-09-01wifi: rtw89: add getting function of DMA channel v1Ping-Ke Shih2-0/+23
The coming RTL8922DE uses new mapping of DMA channel. Add it accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250826085424.28713-1-pkshih@realtek.com
2025-09-01wifi: rtw89: abstract getting function of DMA channelPing-Ke Shih10-42/+59
The mapping function from QSEL (almost equivalent EDCA queue) to PCI DMA channel. Since coming chips change the definition, abstract this function as a chip_ops. Don't change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250826085339.28512-1-pkshih@realtek.com
2025-09-01wifi: rtw89: pci: add RPP parser v1Ping-Ke Shih2-0/+27
The new format contains more information including TX DMA channel, actual TX link and etc. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250826085332.28463-1-pkshih@realtek.com
2025-09-01wifi: rtw89: pci: abstract RPP parserPing-Ke Shih8-18/+52
RPP is short for release report of payload, which carries information assisting TX completion. Since coming chips change the format, abstract the parser ahead. Don't change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250826085324.28414-1-pkshih@realtek.com
2025-09-01wifi: rtw89: pci: add group BD address designPing-Ke Shih8-9/+172
The newly designed group BD address is to use the same starting DMA address with offset as below picture: Original DMA memory Group BD address +--------+ (*1) +---------+ (*2) +--------+ | CH 0 -|-------> | | <-------|- CH 0 | <-+--+--+--+ +--------+ | | | | | | | | | CH 1 -|-------> | | | CH 1 -|---+ | | | +--------+ | | | | | | | | CH 2 -|-------> | | | CH 2 -|------+ | | +--------+ | | | | | | | CH 3 -|-------> | | | CH 3 -|---------+ | +--------+ | | | | | | : -|-------> | | | : -|------------+ +--------+ | | +--------+ (*3; offset from CH 0) | CH 8 -|-------> | | <-------|- CH 8 | <-+ +--------+ | | | | | (offset from CH 8) | : -|-------> | | | : -|---+ +--------+ +---------+ +--------+ Compare (*1) and (*2), for original design, each DMA channel has individual DMA address, so it is not necessary to allocate continual DMA address across channels. For group BD address, only two DMA address are set, and each channel set the offset (*3) from base address. The element number and offset of a channel are encoded rather than a raw number, so add a function to translate numbers into hardware format. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250826085318.28361-1-pkshih@realtek.com
2025-09-01wifi: rtw89: pci: define TX/RX buffer descriptor poolPing-Ke Shih2-48/+75
Buffer descriptor (BD) is a helper of DMA for each ring. The new hardware design expects a continual memory across all rings, so allocate a pool and assign to each ring rather than allocate a buffer for a ring individually. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250826085258.28308-1-pkshih@realtek.com
2025-09-01wifi: rtw89: pci: add struct rtw89_{tx,rx}_rings to put related fieldsPing-Ke Shih3-28/+36
The new hardware design will expect a continual memory region across all rings, so a new field will be added to describe the region. To help the changes, add struct and make changes ahead. Don't change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250826085152.28164-5-pkshih@realtek.com
2025-09-01wifi: rtw89: pci: use RDU status of R_BE_PCIE_DMA_IMR_0_V1 instead for 8922DEPing-Ke Shih3-24/+27
The original RDU status of R_BE_HAXI_HIMR00 needs additional IO to get the status. The new WiFi 7 8922DE add the status to R_BE_PCIE_DMA_IMR_0_V1 which is read already, so we can reduce one reading IO. After the changes, interrupt behavior of RTL8922DE in low power mode is the same as normal mode, so remove the configuration function for low power mode. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250826085152.28164-4-pkshih@realtek.com
2025-09-01wifi: rtw89: pci: prepare interrupt related registers and functions for 8922DEPing-Ke Shih3-0/+109
The 8922DE is very similar to 8922AE except to RDU (RX desc unavailable) registers. The following patch will adjust to read this status from another register to reduce one reading IO, so create a set of functions ahead. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250826085152.28164-3-pkshih@realtek.com
2025-09-01wifi: rtw89: pci: move chip ISR definition out from chip generationPing-Ke Shih9-10/+27
The existing WiFi 6 chips can share the same ISR (interrupt status registers), but the coming WiFi 7 chip 8922DE can't share the same definition with existing WiFi 7 chip, so move the definition to an individual struct. Don't change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250826085152.28164-2-pkshih@realtek.com
2025-09-01wifi: rtl8xxxu: Remove TL-WN722N V2 (0x2357: 0x010c) from untested devicesAleksej Smirnov1-1/+2
This Wi-Fi dongle has been used for many years now and have had no problems with it. The device is quite old and known, dumping its efuse to the log and asking the user to send the results to Jes.Sorensen@gmail.com on every boot makes little sense. Signed-off-by: Aleksej Smirnov <debugger94@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/CAAN7eZ7QKEeQgNHEBuZKy4Gqg3oqpGi6BUdOVBOxPN7dedhVJQ@mail.gmail.com
2025-08-26wifi: rtw88: Use led->brightness_set_blocking for PCI tooBitterblue Smith1-12/+3
Commit 26a8bf978ae9 ("wifi: rtw88: Lock rtwdev->mutex before setting the LED") made rtw_led_set() sleep, but that's not allowed. Fix it by using the brightness_set_blocking member of struct led_classdev for PCI devices too. This one is allowed to sleep. bad: scheduling from the idle thread! nix kernel: CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Tainted: G W O 6.16.0 #1-NixOS PREEMPT(voluntary) nix kernel: Tainted: [W]=WARN, [O]=OOT_MODULE nix kernel: Hardware name: [REDACTED] nix kernel: Call Trace: nix kernel: <IRQ> nix kernel: dump_stack_lvl+0x63/0x90 nix kernel: dequeue_task_idle+0x2d/0x50 nix kernel: __schedule+0x191/0x1310 nix kernel: ? xas_load+0x11/0xd0 nix kernel: schedule+0x2b/0xe0 nix kernel: schedule_preempt_disabled+0x19/0x30 nix kernel: __mutex_lock.constprop.0+0x3fd/0x7d0 nix kernel: rtw_led_set+0x27/0x60 [rtw_core] nix kernel: led_blink_set_nosleep+0x56/0xb0 nix kernel: led_trigger_blink+0x49/0x80 nix kernel: ? __pfx_tpt_trig_timer+0x10/0x10 [mac80211] nix kernel: call_timer_fn+0x2f/0x140 nix kernel: ? __pfx_tpt_trig_timer+0x10/0x10 [mac80211] nix kernel: __run_timers+0x21a/0x2b0 nix kernel: run_timer_softirq+0x8e/0x100 nix kernel: handle_softirqs+0xea/0x2c0 nix kernel: ? srso_alias_return_thunk+0x5/0xfbef5 nix kernel: __irq_exit_rcu+0xdc/0x100 nix kernel: sysvec_apic_timer_interrupt+0x7c/0x90 nix kernel: </IRQ> nix kernel: <TASK> nix kernel: asm_sysvec_apic_timer_interrupt+0x1a/0x20 nix kernel: RIP: 0010:cpuidle_enter_state+0xcc/0x450 nix kernel: Code: 00 e8 08 7c 2e ff e8 d3 ee ff ff 49 89 c6 0f 1f 44 00 00 31 ff e8 c4 d1 2c ff 80 7d d7 00 0f 85 5d 02 00 00 fb 0f 1f 44 00 00 <45> 85 ff 0f 88 a0 01 00 00 49 63 f7 4c 89 f2 48 8d 0> nix kernel: RSP: 0018:ffffd579801c7e68 EFLAGS: 00000246 nix kernel: RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000 nix kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 nix kernel: RBP: ffffd579801c7ea0 R08: 0000000000000000 R09: 0000000000000000 nix kernel: R10: 0000000000000000 R11: 0000000000000000 R12: ffff8eab0462a400 nix kernel: R13: ffffffff9a7d7a20 R14: 00000003aebe751d R15: 0000000000000003 nix kernel: ? cpuidle_enter_state+0xbc/0x450 nix kernel: cpuidle_enter+0x32/0x50 nix kernel: do_idle+0x1b1/0x210 nix kernel: cpu_startup_entry+0x2d/0x30 nix kernel: start_secondary+0x118/0x140 nix kernel: common_startup_64+0x13e/0x141 nix kernel: </TASK> Fixes: 26a8bf978ae9 ("wifi: rtw88: Lock rtwdev->mutex before setting the LED") 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/ad8a49ef-4f2d-4a61-8292-952db9c4eb65@gmail.com
2025-08-26wifi: rtw89: coex: Limit Wi-Fi scan slot cost to avoid A2DP glitchChing-Te Ku1-1/+4
When Wi-Fi is scanning at 2.4GHz, PTA will abort almost all the BT request. Once the Wi-Fi slot stay too long, BT audio device can not get enough data, audio glitch will happened. This patch limit 2.4Ghz Wi-Fi slot to 80ms while Wi-Fi is scanning to avoid audio glitch. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250819034428.26307-5-pkshih@realtek.com
2025-08-26wifi: rtw89: 8852c: update firmware crash trigger type for newer firmwarePing-Ke Shih1-0/+1
The newer firmware (after 0.27.128.0) uses trigger type 1. Add an entry accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250819034428.26307-4-pkshih@realtek.com
2025-08-26wifi: rtw89: 8852a: report average RSSI to avoid unnecessary scanningPo-Hao Huang1-3/+10
8852A uses single antenna during power save, when the loss between two antennas is too large, previous logic induces greater RSSI variation. Report the average beacon RSSI for connected AP to get more stable RSSI and less unnecessary scanning. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250819034428.26307-3-pkshih@realtek.com
2025-08-26wifi: rtw89: 8852a: report per-channel noise level by get_survey opsPo-Hao Huang13-4/+482
To optimize roaming decisions, report per-channel noise levels during scans so supplicant can have a better view of the current channel condition. This allows it to prefer the APs operating on channels with lower noise levels. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250819034428.26307-2-pkshih@realtek.com
2025-08-19wifi: rtw89: 8852bt: Simplify unnecessary if-else conditions in _dpk_onoff()Liao Yuanhong1-4/+1
Some simple if-else logic can be simplified using the ! operator to improve code readability. Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250818064219.448066-1-liaoyuanhong@vivo.com
2025-08-19wifi: rtl8xxxu: Don't claim USB ID 07b8:8188Bitterblue Smith1-2/+0
This ID appears to be RTL8188SU, not RTL8188CU. This is the wrong driver for RTL8188SU. The r8712u driver from staging used to handle this ID. Closes: https://lore.kernel.org/linux-wireless/ee0acfef-a753-4f90-87df-15f8eaa9c3a8@gmx.de/ Cc: stable@vger.kernel.org Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/f147b2ab-4505-435a-aa32-62964e4f1f1e@gmail.com
2025-08-19wifi: rtlwifi: rtl8192cu: Don't claim USB ID 07b8:8188Bitterblue Smith1-1/+0
This ID appears to be RTL8188SU, not RTL8188CU. This is the wrong driver for RTL8188SU. The r8712u driver from staging used to handle this ID. Closes: https://lore.kernel.org/linux-wireless/ee0acfef-a753-4f90-87df-15f8eaa9c3a8@gmx.de/ 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/2e5e2348-bdb3-44b2-92b2-0231dbf464b0@gmail.com
2025-08-19wifi: rtw89: fix group frames loss when connected to non-transmitted BSSIDKuan-Chung Chen4-0/+36
When STA connects to AP with dot11MultiBSSIDImplemented set to true, the layout of the TIM element's Partial Virtual Bitmap changes. Bits 1 to (2^n - 1) are used to indicate buffered group addressed frames (e.g., broadcast/multicast) for non-transmitted BSSIDs. Fix the interpretation of this field to ensure group addressed frames are correctly received. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250811124001.15774-1-pkshih@realtek.com
2025-08-19wifi: rtw89: fix BSSID comparison for non-transmitted BSSIDKuan-Chung Chen1-1/+5
For non-transmitted connections, beacons are received from the transmitted BSSID. Fix this to avoid missing beacon statistics. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250811123950.15697-1-pkshih@realtek.com
2025-08-19wifi: rtw89: 8852c: check LPS H2C command complete by C2H reg instead of ↵Chih-Kang Chang1-0/+1
done ack 8852C after FW 0.27.128.0 driver check LPS H2C command received by FW using C2H reg instead of done ack. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250811123934.15614-1-pkshih@realtek.com
2025-08-19wifi: rtw89: 8851b: rfk: update TX wideband IQKKuan-Chung Chen2-32/+43
Adjust TX wideband calibration from 1 to 2 loop gain settings. This can reflect in better performance in 5 GHz medium-high attenuation environments. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250811123913.15524-1-pkshih@realtek.com
2025-08-19wifi: rtw89: 8851b: rfk: update IQK TIA settingKuan-Chung Chen1-31/+54
With the new TIA setting of RX IQK, unstable RX throughput can be avoided, especially in medium-high attenuation environments. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250811123744.15361-5-pkshih@realtek.com
2025-08-19wifi: rtw89: wow: remove notify during WoWLAN net-detectKuan-Chung Chen1-2/+0
In WoWLAN net-detect mode, the firmware periodically performs scans and sends scan reports via C2H, which driver does not need. These unnecessary C2H events cause firmware watchdog timeout, leading to unexpected wakeups and SER 0x2599 on 8922AE. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250811123744.15361-4-pkshih@realtek.com
2025-08-19wifi: rtw89: debug: add beacon_info debugfsKuan-Chung Chen1-0/+61
Add debugfs beacon_info to display the information of beacon tracking. The screenshot as below: [Beacon info] count: 15 interval: 100 dtim: 1 raw rssi: 146 hw rate: 0 length: 407 [Distribution] tbtt 00 - 04: 26 05 - 09: 5 10 - 14: 1 15 - 19: 0 20 - 24: 0 25 - 29: 0 drift 0: 9 1: 7 2: 3 3: 3 4: 4 5: 1 6: 1 7: 2 8: 1 11: 1 lower bound: 0 upper bound: 10 outlier count: 1 [Tracking] tbtt offset: 20 bcn timeout: 19 Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250811123744.15361-3-pkshih@realtek.com
2025-08-19wifi: rtw89: introduce beacon tracking to improve connection stabilityKuan-Chung Chen7-32/+619
In ideal scenario, AP's beacon should transmit at the Target Beacon Transmission Time (TBTT). However, in practice, beacon may be slightly off-schedule. This beacon "drift" prevents the firmware from receiving beacon at the expected TBTT, leading to connection disruptions. To address this, we introduce beacon tracking mechanism to enhance overall connection stability. This mechanism executes the following steps in each cycle (2 seconds): 1) Based on the last 32 received beacons, compute the minimum TBTT offset to use for the next cycle 2) Using the same 32 beacons, calculate the drift of each. A histogram is plotted, and outliers are identified using a boxplot. 3) According to the statistical results from the second step, a maximum receive window size (beacon timeout) is selected to cover approximately 80% of the beacons and applied to the next cycle. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250811123744.15361-2-pkshih@realtek.com
2025-08-12wifi: rtw89: 8852bt: Use standard helper for string choiceAkhilesh Patil1-2/+2
Use standard helper str_on_off() defined at string_choices.h in _dpk_information() to improve code reusability. Reduce hardcoding of repeated use of the same strings to save code space. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/r/202507282341.drTGfLWA-lkp@intel.com/ Signed-off-by: Akhilesh Patil <akhilesh@ee.iitb.ac.in> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/aJWNhu9bAkcjEyb4@bhairav-test.ee.iitb.ac.in
generated by cgit v1.2.3 (git 2.39.1) at 2025-12-27 09:05:27 +0000