- new handy helper FIELD_GET_SIGNED() (Yury);
- arch test_and_set_bit_lock() and clear_bit_unlock() cleanup (Randy);
- __bf_shf() simplification (Yury);
- bitmap_print_to_pagebuf() removal (Yury);
- RISCV/bitrev conditional support (Jindie, Yury);
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEEi8GdvG6xMhdgpu/4sUSA/TofvsgFAmowS0sACgkQsUSA/Tof
vshqLgwAw2RkV8ZHAniyPgz4noGztto+fcD70UbMgkh48n46PSKIUPCUvOj4RGHc
Nzcjg6VkHLlypb7U3fHoXOHhkt+nTt+OeVDtZCmr8OzlRYmWXAo9TptfalDAlH1A
OucRocjYSkwl/nbuYk0EQ/0+AcTFlfVTeyyus6wUYt7Nj1ncCNjKF2K5EjtF4aoQ
JiA4d9LKWCIN4qFodP/9aFDzLX5MvqHgvOmBPSSFZKkMAer9HHCa/V3jHH3JMh21
bMPjZvaPUCI9oywLL+pDe0RRhP1CYFevxJ/Tnpcx0elV+CekrzuSsM3zpRbPt6hR
0P+8VVzUuoI8yth5mSH1gvUn9ZDvDeognTpKpXR574lB83A8Ub/Gu/NGMXO3TY0q
mtuVbI5ZG0dCqahjEZvJQJmZ/qqbmwDhQDBtPS0x3S9XyzhNAga+JFpr6FXhULx8
b8ZrDPc5BGLtTt5aBOAgpN10CeFM8JHxku1B489sqRXQWaeKW++GkVfVTZ9UOK1E
8c3l/1Bl
=z8f4
-----END PGP SIGNATURE-----
Merge tag 'bitmap-for-7.2' of https://github.com/norov/linux
Pull bitmap updates from Yury Norov:
"This includes the new FIELD_GET_SIGNED() helper,
bitmap_print_to_pagebuf() removal, RISCV/bitrev support, and a couple
cleanups.
- new handy helper FIELD_GET_SIGNED() (Yury)
- arch test_and_set_bit_lock() and clear_bit_unlock() cleanup (Randy)
- __bf_shf() simplification (Yury)
- bitmap_print_to_pagebuf() removal (Yury)
- RISCV/bitrev conditional support (Jindie, Yury)"
* tag 'bitmap-for-7.2' of https://github.com/norov/linux:
MAINTAINERS: BITOPS: include bitrev.[ch]
arch/riscv: Add bitrev.h file to support rev8 and brev8
bitops: Define generic___bitrev8/16/32 for reuse
lib/bitrev: Introduce GENERIC_BITREVERSE
arch: select HAVE_ARCH_BITREVERSE conditionally on BITREVERSE
bitmap: fix find helper documentation
bitmap: drop bitmap_print_to_pagebuf()
cpumask: switch cpumap_print_to_pagebuf() to using scnprintf()
bitfield: wire __bf_shf to __builtin_ctzll
bitops: use common function parameter names
ptp: switch to using FIELD_GET_SIGNED()
rtc: rv3032: switch to using FIELD_GET_SIGNED()
wifi: rtw89: switch to using FIELD_GET_SIGNED()
iio: mcp9600: switch to using FIELD_GET_SIGNED()
iio: pressure: bmp280: switch to using FIELD_GET_SIGNED()
iio: magnetometer: yas530: switch to using FIELD_GET_SIGNED()
iio: intel_dc_ti_adc: switch to using FIELD_GET_SIGNED()
x86/extable: switch to using FIELD_GET_SIGNED()
bitfield: add FIELD_GET_SIGNED()
Expose the device's Serial Number (SN) and UUID from EFUSE via two
read-only sysfs attributes, `serial_number` and `uuid`, on the ieee80211
phy device under the `rtw89_usb` attribute group.
This hardware identification information is essential for user-space
applications to uniquely identify, track, and manage specific Wi-Fi
adapters. For example, in automated factory provisioning or device
management systems, user-space tools rely on the EFUSE serial number and
UUID to bind configurations to specific physical adapters. Currently,
standard wireless APIs do not expose this low-level hardware
information, making these sysfs nodes the only viable solution for
user space to extract this data.
The attributes are gated behind a new RTW89_QUIRK_HW_INFO_SYSFS quirk,
enabled only for the VID 0x28de / PID 0x2432 device via the
dev_id_quirks field in rtw89_driver_info.
Example usage from user-space:
$ cat /sys/class/ieee80211/phy0/rtw89_usb/serial_number
3642000123
$ cat /sys/class/ieee80211/phy0/rtw89_usb/uuid
aaec2b7c-0a55-4727-8de0-b30febccbbaa
Cc: Elliot Saba <sabae@valvesoftware.com>
Cc: Charles Lohr <charlesl@valvesoftware.com>
Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260529075032.16807-3-pkshih@realtek.com
Add a dev_id_quirks field to rtw89_driver_info so that per-device
(VID/PID) quirks can be expressed independently of chip-level
default_quirks. Apply the bitmap in rtw89_alloc_ieee80211_hw() so
both USB and PCI probes benefit automatically.
All existing driver_info structs initialize dev_id_quirks to 0;
no behavior change.
Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260529075032.16807-2-pkshih@realtek.com
Skip the ACPI capability check for all USB devices by default,
allowing them to use their default configurations.
For USB dongles, customers will manage their own compliance and
certification. This initial patch focuses on the generic USB skip
infrastructure; specific customer certifications and localized
configurations will be handled by quirks afterward.
Signed-off-by: David Lee <sc.lee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260525082636.31105-1-pkshih@realtek.com
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
Switch from sign_extend32(FIELD_GET()) to the dedicated
FIELD_GET_SIGNED() and don't calculate the fields length explicitly.
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yury Norov <ynorov@nvidia.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
