Add the specific USB device ID which adapter tested fully functional on
Fedora 44 with kernel 7.0.8-200.fc44.x86_64 and linux-firmware
20260410-1.fc44.
Reported-by: Guillermo Servera Negre <guillem@gservera.com>
Tested-by: Guillermo Servera Negre <guillem@gservera.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260525011728.6836-1-pkshih@realtek.com
The Realtek wifi 6/7 devices which support USB 3 are weird: when first
plugged in, they pretend to be USB 2. The driver needs to send some
commands to the device, which make it disappear and come back as a
USB 3 device.
Implement the required commands in rtw89.
Add a new function rtw89_usb_write32_quiet() to avoid the warnings
when writing to R_{AX,BE}_PAD_CTRL2. Even though the write succeeds,
usb_control_msg() returns -EPROTO, probably because the USB device
disappears immediately. This results in some confusing warnings in
the kernel log.
When a USB 3 device is plugged into a USB 2 port, rtw89 will try to
switch it to USB 3 mode only once. The device will disappear and come
back still in USB 2 mode, of course.
Tested with RTL8832AU, RTL8832BU, RTL8832CU, and RTL8912AU.
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/e955451c-93a1-4d04-8024-d224a04f1d4a@gmail.com
Some RTL8821CE cards can return frames with corrupted RX descriptor,
causing warnings and crashes if they are passed to the upper layers.
The PHY status size field is 4 bits wide, but in rtw88 its value should
only be 0 or 4. Checking this catches most of the corrupt frames.
If a PHY status is present, the PHY status size should not be 0.
The frame size should not be less than or equal to 4 and should not
exceed 11454.
The rate should not exceed 4SS MCS9.
Discard the frame if any of these checks fail.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221286
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Tested-by: Oleksandr Havrylov <goainwo@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/5bfecba3-8a90-4e0f-9558-af5cd8a14975@gmail.com
By default, BB enables triangular spectrum by a series of register
settings. According to band and regulation, RF parameters determine whether
TX shape needs to be restricted or not. So now, clear the corresponding
settings if it has no need to do.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260520123823.1792954-8-pkshih@realtek.com
Support of Large MRU (Multiple Resource Unit) starts from RTL8922D_CID7090,
i.e. RTL8922A and RTL8922D-VS variant do not support it. There are the new
corresponding control registers. So, configure them.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260520123823.1792954-6-pkshih@realtek.com
Because base settings of digital power compensation can be shared across
all bands, the settings are divided into two parts -- base and individual
values per bands. Refactor the code to be reuse with new format.
No change logic at all.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260520123823.1792954-3-pkshih@realtek.com
RF parameters has different TX power track table for different AID.
FW elements may include multiple TX power track tables for different
AID. So, load the corresponding one.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260520123823.1792954-2-pkshih@realtek.com
When rtw_usb_write_port() fails to submit a USB Request Block (URB)
(e.g., due to device disconnect or ENOMEM), the completion callback is
never executed.
Currently, the driver ignores the return value of rtw_usb_write_port()
in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these
functions rely on the completion callback to free the socket buffers
(skbs) and the transaction control block (txcb), a submission failure
results in:
1. A memory leak of the allocated skb in rtw_usb_write_data().
2. A memory leak of the txcb structure and all aggregated skbs in
rtw_usb_tx_agg_skb().
Fix this by checking the return value of rtw_usb_write_port(). If it
fails, explicitly free the skb in rtw_usb_write_data(), and properly
purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb().
The issue was discovered in practice during device disconnect/reconnect
scenarios and memory pressure conditions. Tested by verifying normal TX
operation continues after the fix without regressions.
Fixes: a82dfd33d1 ("wifi: rtw88: Add common USB chip support")
Cc: stable@vger.kernel.org
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Tested-by: Luka Gejak <luka.gejak@linux.dev>
Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260518142311.10328-2-luka.gejak@linux.dev
The driver expects the firmware to report TX status within 500ms.
However, a timeout can be triggered when the hardware performs
background scans while under TX load. During these scans, the firmware
stays off-channel for periods exceeding 500ms, delaying the delivery of
TX reports back to the driver.
When this occurs, the purge timer fires prematurely and drops the
tracking skbs from the queue. This results in the host stack
interpreting the missing status as packet loss, leading to TCP window
collapse. In testing with iperf3, this causes throughput to drop from
~90 Mbps to near-zero for approximately 2 seconds until the connection
recovers.
Increase RTW_TX_PROBE_TIMEOUT to 2500ms for RTL8723DU. This duration is
sufficient to accommodate off-channel dwell time during full background
scans, ensuring the purge timer only trips during genuine firmware
lockups and preventing unnecessary TCP retransmission cycles.
Fixes: a82dfd33d1 ("wifi: rtw88: Add common USB chip support")
Cc: stable@vger.kernel.org
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Tested-by: Luka Gejak <luka.gejak@linux.dev>
Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260518142311.10328-1-luka.gejak@linux.dev
A user with MLO-capable router reports:
[ 753.080409] rtw89_8922au_git 2-2:1.0: Cannot map qsel to dma v2: 26
[ 753.080417] rtw89_8922au_git 2-2:1.0: Cannot map qsel to dma v2: 26
[ 813.649426] rtw89_8922au_git 2-2:1.0: Cannot map qsel to dma v2: 26
[ 813.649445] rtw89_8922au_git 2-2:1.0: Cannot map qsel to dma v2: 26
[ 813.855983] rtw89_8922au_git 2-2:1.0: Cannot map qsel to dma v2: 26
Map RTW89_TX_QSEL_B1_MGMT and RTW89_TX_QSEL_B1_HI to RTW89_TXCH_CH10.
This is probably the right channel for these queues.
This function is also used for RTL8852AU and RTL8852CU, but those
currently aren't used in DBCC mode with rtw89 so it makes no difference
for them.
Link: https://github.com/morrownr/rtw89/issues/83#issuecomment-4314735734
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/0c8e0cf1-13e9-4c67-a67f-5f6f79fd0658@gmail.com
The existing quota set is for RTL8922DE-VS, so rename the existing tables.
Add new quota set for RTL8922DE, containing more memory to yield better
performance, so rearrange quota accordingly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260515014433.16168-14-pkshih@realtek.com
RTL8922D has many variants, using different quota tables. Consolidate the
quota data into a struct, and then select corresponding table for the
chip variant.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260515014433.16168-13-pkshih@realtek.com
The previous commit aims to fix issue caused by malformed AMPDU frames.
But the drop logic fails to deal with the first AMPDU packet paired with
certain range of sequence number, and leads to unexpected packet drop.
It is more likely to encounter this failure when there are busy traffic
during rekey process and could lead to disconnection from the AP.
Fix this by adding a initial state judgement and only reset status
during pairwise rekey.
Fixes: bda294ed0e ("wifi: rtw89: Drop malformed AMPDU frames with abnormal PN")
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260515014433.16168-10-pkshih@realtek.com
In WoWLAN mode, the firmware periodically sends Null packets to the AP
to keep the connection alive and prevent the AP from disconnecting the
client due to inactivity. However, it was observed that certain APs,
such as TP-Link Archer BE800, do not recognize Null packets as
valid activity and still drop the connection. Replacing Null packets
with ARP reply packets effectively resolves this compatibility issue
and maintains the connection.
Specifically, while the firmware typically handles standard ARP
offloads by dynamically modifying target IP/MAC fields, these
keep-alive ARP reply packets are pre-filled by the driver with the
DUT's own MAC and IP addresses for both sender and target fields.
In this case, the firmware transmits the packets as-is without
further modification. This approach ensures compatibility with APs
that require valid Layer 3 traffic for activity monitoring while
simplifying the firmware's processing logic during WoWLAN mode.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260515014433.16168-9-pkshih@realtek.com
Originally, driver always transmits LTR (Latency Tolerance Reporting) to
pcie host, but it may cause pcie link down on some platforms because
LTR is not supported. As a result, driver will check the control
register of LTR setting to decide whether to enable LTR feature.
This applies to Wi-Fi 6 chips only. For Wi-Fi 7 chips, although the
driver still issues LTR, the hardware has its own internal logic
to determine whether to actually transmit it to pcie host.
Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260515014433.16168-5-pkshih@realtek.com
When SER (system error recovery) happens, there may be some handshake
between FW and SW, e.g. SER Level 1. These handshake are based on H2C
commands and C2H events. Dump the status of them to enhance SER debug.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260515014433.16168-4-pkshih@realtek.com
Wi-Fi 7 FW fixes support of triggering SER L0/L1 simulation via halt H2C
command on v0.35.108.0. After that, the halt H2C command trigger for
Wi-Fi 6 and Wi-Fi 7 can be the same. Update FW feature table and share the
halt H2C command trigger function between Wi-Fi 6 and Wi-Fi 7.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260515014433.16168-3-pkshih@realtek.com
Wi-Fi 7 has dedicated HW register to count SER L0 simulation, i.e.
manually triggered by users. Show count of it in dbgfs ser_counters.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260515014433.16168-2-pkshih@realtek.com
The settings of control options are predefined per RFSI band (2GHz band or
not 5/6GHz band) and used for fine-tuning transmit power. Calculate and set
the RFSI band once creating channel context, and use it by BB wrapper
configurations.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260511070148.25257-11-pkshih@realtek.com
The BB wrap is a hardware block to control TX power. Since RTL8922D has
many variants with different CID and RFE types, prepare flow and dummy
struct adopt to configuration functions for coming patches.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260511070148.25257-2-pkshih@realtek.com
Remove the rtw_txq_dequeue helper. It's a wrapper around
ieee80211_tx_dequeue with just one caller.
Call ieee80211_tx_dequeue directly in rtw_txq_push. There's no need to
fetch txq for every frame, we can do this once outside of the rcu lock.
Make the loop variable i unsigned long, it should have the same type as
frames.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260507082238.889656-1-martin@kaiser.cx
The radiotap headroom is allocated only if IEEE80211_CONF_MONITOR is set.
However, it is potentially racing that SKB allocation without radiotap
headroom but adding radiotap from matched PPDU status of another SKB.
Add a check to avoid the case.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260506131000.1706298-15-pkshih@realtek.com
The format of PHY status IE-10 for RTL8922D is different from earlier
chips. Fortunately only starting bit is different, but the layout is the
same. Get the VHT/HE SIG-A value by corresponding mask accordingly.
The IE-09 format of generation 0 and 1 are totally the same.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260506131000.1706298-14-pkshih@realtek.com
Hardware reports a list of PHY status IE. In monitor mode, IE-09 of
PHY status is enabled, and the report contains trailing 8-byte zeros,
causing failed to parse and drop all IE information.
The 8 zeros are recognize as IE type 0, but length of type 0 must be
not 8 (reference to rtw89_phy_gen_def::physt_ie_len[0]).
Check and skip them.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260506131000.1706298-13-pkshih@realtek.com
To capture HE-MU packets, set BSS color and AID for specific connected
station.
The writing format: <bss color> <aid>
For example,
$ echo 0x4 0x16 > monitor_opts
Read this entry to get current setting:
bss_color=0x4 aid=0x16
By the way, add another sec2() function to create debugfs entries to
prevent running smatch timeout.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260506131000.1706298-11-pkshih@realtek.com
Fill HE radiotap by PHY status IE-09/IE-10 which contains HE SIG-A/SIG-B
respectively.
The IE-10 may contain two content channels (if bandwidth is larger than
40MHz), and starting address of second content channel can be calculated by
length of first content channel containing up to 15 user fields with 8-byte
alignment.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260506131000.1706298-9-pkshih@realtek.com
The IE-09/IE-10 of PHY status contain SIG-A/SIG-B respectively, so enable
them in monitor mode to have rich information. If the parser detects
length invalid, ignore to reference IE-09/IE-10 to prevent accessing out
of range.
The RTL8922D is generation 2 of PHY status, which doesn't report SIG-B by
IE-10, so not enable it.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260506131000.1706298-6-pkshih@realtek.com
Both RTL8922A and RTL8922D are WiFi 7 chips, but their IE length of PHY
status are different. Define them accordingly.
Generation 0: WiFi 6 chips
Generation 1: WiFi 7 RTL8922A
Generation 2: WiFi 7 RTL8922D
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260506131000.1706298-5-pkshih@realtek.com
