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>
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: ebfc9199df ("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
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: 1ae5ca6152 ("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
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: 1ae5ca6152 ("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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
