linux.git/drivers/net/wireless/realtek, branch v6.16

treewide, timers: Rename from_timer() to timer_container_of()

2025-06-08T07:07:37+00:00

Move this API to the canonical timer_*() namespace.

[ tglx: Redone against pre rc1 ]

Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com

Merge tag 'rtw-next-2025-05-16' of https://github.com/pkshih/rtw

2025-05-16T08:51:11+00:00

Ping-Ke Shih says:
==================
rtw-next patches for v6.16

Some fixes and refinements across drivers, and regular development of
MLO and STA + P2P concurrency. Major changes are listed below.

rtw88:

 * improve throughput for RTL8814AU

rtw89:

 * support MLO

 * improve user experience for STA + P2P concurrency

 * dynamic antenna gain (DAG) with different power by antenna

 * load SAR tables from ACPI
==================

Link: https://patch.msgid.link/17e74675-70cc-43d7-a797-afb937030d34@RTEXMBS04.realtek.com.tw/
Signed-off-by: Johannes Berg

wifi: rtw89: fix firmware scan delay unit for WiFi 6 chips

2025-05-16T01:03:40+00:00

The scan delay unit of firmware command for WiFi 6 chips is
microsecond, but is wrong set now and lead to abnormal work
for net-detect. Correct the unit to avoid the error.

Fixes: e99dd80c8a18 ("wifi: rtw89: wow: add delay option for net-detect")
Signed-off-by: Chin-Yen Lee 
Signed-off-by: Ping-Ke Shih 
Link: https://patch.msgid.link/20250513125203.6858-1-pkshih@realtek.com

wifi: rtw88: fix the 'para' buffer size to avoid reading out of bounds

2025-05-16T01:00:52+00:00

Set the size to 6 instead of 2, since 'para' array is passed to
'rtw_fw_bt_wifi_control(rtwdev, para[0], ¶[1])', which reads
5 bytes:

void rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data)
{
    ...
    SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data);
    SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1));
    ...
    SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4));

Detected using the static analysis tool - Svace.
Fixes: 4136214f7c46 ("rtw88: add BT co-existence support")
Signed-off-by: Alexey Kodanev 
Signed-off-by: Ping-Ke Shih 
Link: https://patch.msgid.link/20250513121304.124141-1-aleksei.kodanev@bell-sw.com

wifi: rtw89: mcc: avoid redundant recalculations if no chance to improve

2025-05-16T00:45:00+00:00

MCC will track the changes of beacon offset, and trigger a recalculation
when the difference is larger than the tolerance. It means that a better
pattern is expected after recalculating. However, in the cases which get
a worse beacon offset, there is no chance to improve the pattern even if
recalculating. So, bypass them.

Signed-off-by: Zong-Zhe Yang 
Signed-off-by: Ping-Ke Shih 
Link: https://patch.msgid.link/20250511035217.10410-7-pkshih@realtek.com

wifi: rtw89: mcc: deal with non-periodic NoA

2025-05-16T00:43:41+00:00

Originally, MCC just took periodic NoA into account. When the connected GO
announces non-periodic NoA and GC side is during MCC, sometimes GC cannot
receive beacons well if the MCC scheduling conflicts with the non-periodic
NoA planning. After the loss exceeds the tolerable amount, beacon filter
will report connection loss. However, in this case, the loss is acceptable.
So now, MCC will calculate the range of non-periodic NoA. And then, don't
care beacon loss during the range.

Besides, rtw89_mcc_fill_role_limit() only makes sense for GC. Remove the
redundant check of GO.

Signed-off-by: Zong-Zhe Yang 
Signed-off-by: Ping-Ke Shih 
Link: https://patch.msgid.link/20250511035217.10410-6-pkshih@realtek.com

wifi: rtw89: mcc: introduce calculation of anchor pattern

2025-05-16T00:43:31+00:00

In the cases that two MCC roles' TBTTs are too close or too far, original
MCC pattern calculation logic will lead to a result that both roles might
not cover its TBTT with sufficient time. Introduce a new calculation logic
called anchor pattern for these corner cases. It allows to choose one role
as anchor to put its TBTT in the middle of its duration directly. For now,
a P2P role has a higher priority to be chosen as an anchor. Then, if able,
another role might need to depend on courtesy mechanism to take time from
anchor.

Signed-off-by: Zong-Zhe Yang 
Signed-off-by: Ping-Ke Shih 
Link: https://patch.msgid.link/20250511035217.10410-5-pkshih@realtek.com

wifi: rtw89: mcc: add courtesy mechanism conditions to P2P roles

2025-05-16T00:43:22+00:00

In one enablement of courtesy mechanism, there is one provider and
one receiver. And, receiver can use the provider's time in a given
period. But, to make P2P NoA protocol work as expected as possible,
GO should be present at the time it doesn't announce absent, and GC
should not use the time when GO announces absent. So, don't enable
courtesy mechanism if provider is GO or receiver is GC.

Signed-off-by: Zong-Zhe Yang 
Signed-off-by: Ping-Ke Shih 
Link: https://patch.msgid.link/20250511035217.10410-4-pkshih@realtek.com

wifi: rtw89: mcc: drop queued chanctx changes when stopping

2025-05-16T00:43:12+00:00

When MCC is about to stop, there may be some chanctx changes which are
queued for work but have not yet been run. To avoid these changes from
being processed in a wrong state (e.g. next new MCC instance), cancel
the queued work and drop queued changes.

Signed-off-by: Zong-Zhe Yang 
Signed-off-by: Ping-Ke Shih 
Link: https://patch.msgid.link/20250511035217.10410-3-pkshih@realtek.com

wifi: rtw89: mcc: pass whom to stop at when pausing chanctx

2025-05-16T00:42:43+00:00

When stopping MCC, FW can stop at a given MCC role following H2C command.
When pausing chanctx during MCC, in general, the caller expects to process
things with its chanctx. So, pass the caller as target and let FW stop MCC
at it.

Signed-off-by: Zong-Zhe Yang 
Signed-off-by: Ping-Ke Shih 
Link: https://patch.msgid.link/20250511035217.10410-2-pkshih@realtek.com