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
Add BB diagnostic to track potential abnormal conditions. Currently,
five diagnostic metrics are monitored: 1) Hang detection monitors
consecutive absence of TX and RX activity. 2) PD maximum triggers
when PD stays at its maximum threshold for a period. 3) No RX
occurs when no CCA activity is detected over multiple consecutive
cycles. 4) High FA indicates a high false alarm ratio, reflecting
severe environmental interference. 5) EDCCA alerts when high EDCCA
ratio, signaling a potential TX hang.
These metrics are exposed via debugfs diag_bb.
Output:
[PHY 0]
Diag bitmap = 0x0
Event{Hang, PD MAX, No RX, High FA, High EDCCA Ratio} = {0, 0, 0, 0, 0}
consecutive_no_tx_cnt=0, consecutive_no_rx_cnt=0
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260429132625.1659182-8-pkshih@realtek.com
Enhance bb_info debugfs by adding TX status information to aid
debugging and performance analysis.
A snapshot of TX-related registers, including PPDU type and subtype,
bandwidth, TX power, STBC, etc. The information is collected per
PHY during track_work and displayed via bb_info debugfs.
TX status output:
== TX General
EHT_MU_SU DATA
BW: 160, TX_SC: 0, TX_PATH_EN: 3, PATH_MAP: 0xe4
TXPWR TMAC: 11, P0: 11, P1: 11 dBm
MCS: 9, STBC: 0
Info: [0x0000000b, 0xc1702c30, 0x0ff1e430, 0xc0000000, 0x99000009, 0x40000000]
Common ctrl: [0x00000150, 0x40190140]
In addition, include the retry ratio from RA reports and display it
as PER (packet error rate) in station debug information.
PER output:
TX rate [0, 0]: HE 2SS MCS-4 GI:0.8 BW:20 (hw_rate=0x324) PER:23
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260429132625.1659182-6-pkshih@realtek.com
The original MLSR link decision refers to RSSI, but it should be
based on the premise of an existing link. Otherwise, make a link
decision to select a new link from any available band.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260429132625.1659182-2-pkshih@realtek.com
Some devices malfunction when connected to a network with 40 MHz channel
width, because they don't support that.
RTL8188FU, RTL8192FU, and RTL8710BU (RTL8188GU) have a way to signal
this (and some other capabilities) to the driver. Get this information
from the hardware and advertise 40 MHz support only when the hardware
can handle it. We assume the other chips can always handle it.
RTL8710BU needs a different way to retrieve this information, which will
be implemented some other time.
Fixes: dbf9b7bb0e ("wifi: rtl8xxxu: Enable 40 MHz width by default")
Cc: stable@vger.kernel.org
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221394
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/c57de68e-5d57-4c26-898f-8a284bb25381@gmail.com
Bit 28 of double word 2 in the RX descriptor indicates if the packet is
a normal 802.11 frame, or a message from the wifi firmware to the
driver (Card 2 Host).
Commit f5678bfe1c ("rtlwifi: rtl8821ae: Replace local bit manipulation
macros") mistakenly made the driver look for this bit in double word 1,
causing packet loss and Bluetooth coexistence problems.
Fixes: f5678bfe1c ("rtlwifi: rtl8821ae: Replace local bit manipulation macros")
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/04da7398-cedb-425a-a810-5772ab10139d@gmail.com
Fix interoperability problem where CSI feedback with STBC enabled at
VHT 160MHz BW cannot be properly decoded by certain APs, causing CSI
reports to be rejected. This problem is specific to Wi-Fi 7 chips,
as Wi-Fi 6 defaults to 20MHz CSI BW. Therefore, disable STBC encoding
for CSI transmission in VHT 160MHz mode to ensure CSI feedback is
accepted by these APs and maintain smooth throughput.
Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260424072552.59220-4-pkshih@realtek.com
Disable HE QoS HTC field when operating in AP mode to resolve
interoperability issues with some stations.
Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260424072552.59220-3-pkshih@realtek.com
The bit is to wait for CLK ready when entering PCIE L1SS. However, a
certain host might not enable CLK for a situation, causing device state
stuck and trigger PCIE SER. Unset this bit as default like earlier chips.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260424072552.59220-2-pkshih@realtek.com
The mac_id field in RX descriptors is 8 bits wide (0-255), but
assoc_link_on_macid[] has only RTW89_MAX_MAC_ID_NUM (128) entries.
While the driver currently assigns mac_id values below 128, the
descriptor value comes from firmware and is not validated before use
as an array index. Add a defensive bounds check in
rtw89_assoc_link_rcu_dereference() to guard against out-of-range
firmware values.
Fixes: 144c6cd24b ("wifi: rtw89: 8922a: configure AP_LINK_PS if FW supports")
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260421111442.3395411-1-tristmd@gmail.com
In rtw_pci_rx_napi(), new_len is computed as the sum of pkt_len (14-bit
descriptor field, max 16383) and pkt_offset (drv_info_sz + shift, both
firmware-controlled). The result can exceed RTK_PCI_RX_BUF_SIZE (11478),
causing an out-of-bounds read from the pre-allocated DMA buffer when
skb_put_data copies new_len bytes. The USB transport already validates
this (rtw_usb_rx_data_put checks against RTW_USB_MAX_RECVBUF_SZ); the
PCIe path does not.
Add a check that new_len does not exceed the DMA buffer size.
Fixes: e3037485c6 ("rtw88: new Realtek 802.11ac driver")
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260421111434.3389674-1-tristmd@gmail.com
RF calibration (RFK) will record the results in HW RFK tables. SW can
select and configure the target HW RFK table to reuse the RFK result
on the target channel. Though the above can work as before, when MLD
runs eMLSR mode, a faster switching between links than SW is needed.
So, introduce a new working flow for MLD. With the new settings, HW
can easily switch RFK results between links during eMLSR mode.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260420034051.17666-17-pkshih@realtek.com
The original helper can only queries target channel, but cannot determine
current role's status, e.g. is it MLD or not. These things should be a set.
Adding more and more helpers to query them individually without synchronous
doesn't seem right. Introduce a new helper to query current channel set and
role status.
Besides, when single channel, e.g. MLO_2_PLUS_0_1RF and MLO_0_PLUS_2_1RF,
the target channel pointer will be duplicated to fill the returned channel
set. So, some callers can save trivial things for these cases. The returned
channels will be non-NULL, so callers don't need trivial NULL check either.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260420034051.17666-16-pkshih@realtek.com
The PD (Packet Detection) lower bound is set after the STA interface
connects. When the P2P interface attempts to find peers, it enters
the remain-on-channel flow to listen for probe requests. However, if
the RSSI of the connected AP is too high, the P2P interface fails to
receive it. To resolve this, suspend the DIG during the
remain-on-channel period.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260420034051.17666-15-pkshih@realtek.com
The original flow checks the scan offload C2H event done ack to increase
the scan sequence. However, the scan offload response C2H event may be
received earlier than the scan offload C2H event done ack, which causes
these C2H event to be dropped by rtw89_fw_c2h_purge_obsoleted_scan_events()
check because the scan sequence of the scan offload response C2H event
is less than the scan offload C2H event done ack. Therefore, checking
the scan offload C2H event recv ack instead of C2H event done ack to fix
this issue.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260420034051.17666-14-pkshih@realtek.com
This C2H packet is used to indicate that FW has received the
corresponding H2C command. No logic is changed.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260420034051.17666-13-pkshih@realtek.com
Use firmware offload to perform batch register writes for PHY and RF.
This reduces I/O operations, improves bus transfer efficiency, and
decreases hardware initialization time.
Performance improvement on USB 2.0 HCI:
- rtw89_phy_init_bb_reg: 61 ms -> 5 ms
- rtw89_phy_init_rf_reg: 587 ms -> 106 ms
Use offload-aware delay functions (do_udelay and do_mdelay) for the
delay calls in rtw89_phy_init_reg, rtw89_phy_config_rf_reg, and
rtw89_phy_config_rf_reg_v1 to ensure compatibility with batch register
writes.
Signed-off-by: Eric Huang <echuang@realtek.com>
Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260420034051.17666-11-pkshih@realtek.com
During the initialization of DMAC and CMAC, the driver performs a
large number of consecutive register writes. Sending these I/O
requests individually over the host interface introduces significant
latency and delays the device bring-up process.
Optimize the initialization flow by wrapping the register write
sequences in mac.c and mac_be.c with rtw89_io_pack() and
rtw89_io_unpack(). This batches the operations and offloads them
to the firmware via H2C commands, which significantly accelerates
the overall initialization time.
(8852C USB2.0 AMD B450 1379 ms -> 1273 ms)
Signed-off-by: Chia-Yuan Li <leo.li@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260420034051.17666-10-pkshih@realtek.com
Offload register write operations to the firmware to improve IO efficiency.
Instead of the host performing direct bus access for every register, the
operations are now encapsulated into firmware commands.
This implementation allows the host to aggregate multiple register write
actions into a single command buffer. By batching these operations, we
reduce the number of individual transactions on the bus and minimize
per-transfer overhead, leading to faster overall IO performance.
Add a support_fw_cmd_ofld field to the chip_info structure to control
whether firmware-offloaded batch writes are enabled. Enable it by
default for RTL8832CU.
Co-developed-by: Eric Huang <echuang@realtek.com>
Signed-off-by: Eric Huang <echuang@realtek.com>
Co-developed-by: Johnson Tsai <wenjie.tsai@realtek.com>
Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com>
Signed-off-by: Chia-Yuan Li <leo.li@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260420034051.17666-9-pkshih@realtek.com
RTL8852BT missed to configure support_noise field in chip_info.
Although RTL8852BT doesn't support that, add the configuration
to make things clear.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260420034051.17666-8-pkshih@realtek.com
PD (Packet Detection) threshold is a key parameter in the DIG
(Dynamic Initial Gain) algorithm that determines the sensitivity
of packet detection. Current implementation only supports dynamic
PD adjustment based on environment. This patch adds support for
static PD threshold via debugfs allowing users to set a fixed PD
value for testing or specific scenarios.
Signed-off-by: Eric Huang <echuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260420034051.17666-6-pkshih@realtek.com
This helps avoid excessive bus traffic and I/O overhead on
slower HCIs (e.g., USB, SDIO) caused by frequent power state
transitions.
Add RTW89_DM_INACTIVE_PS to the disabled_dm bitmap via debugfs and
check it in the rtw89_enter_ips path. When set, the driver skips
entering inactive power save and returns immediately.
Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260420034051.17666-5-pkshih@realtek.com
This helps avoid scan-triggered off-channel activity during
latency-sensitive scenarios.
Add RTW89_DM_HW_SCAN to the disabled_dm bitmap via debugfs and
check it in the hw_scan path. When set, the driver rejects hw_scan
requests and returns -EBUSY.
Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260420034051.17666-4-pkshih@realtek.com
Improve user experience while using interactive applications.
Adjust power saving decisions under different scenarios.
Minimize latency for delay-sensitive connections by exiting
power-save on packet bursts and maintain active until a period
of inactivity is reached. For connections that are not that
sensitive to delays, keep the current aggressive power save logic.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260420034051.17666-3-pkshih@realtek.com
The commit 127ea8d0b0 ("wifi: rtw89: fix typo "frome" -> "from" in rx_freq_frome_ie")
change the struct field to correct the typo, but miss to fix this for
RTL8922D because it is submitting at the same time.
As RTL8922D is not enabled yet, this build error doesn't appear.
Fix it accordingly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260420034051.17666-2-pkshih@realtek.com
Tested without MLO, mostly in station mode and a little in AP mode.
It can reach 1.5 Gbps RX, 1 Gbps TX speed.
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/c0bd60ba-4e2d-41cb-8b0c-38454a341d7a@gmail.com
This is the entry point of the new rtw89_8922au module.
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/0d22cd72-4048-41ad-a4aa-511681e6ba51@gmail.com
Add rtw8922a_dle_mem_usb2 and rtw8922a_dle_mem_usb3 and their various
quotas and sizes in struct rtw89_mac_size_set.
"dle" could be "Data Link Engine" or "Double Link Engine". These are
some parameters needed for RTL8922AU.
Also rename wde_size4_v1 to wde_size3_v1 because the name seemed
incorrect.
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/f9ac366b-ca8d-492e-83bf-440f8557c629@gmail.com
"hfc" means "hci fc" which is "Host Control Interface Flow Control".
These are some parameters needed for RTL8922AU.
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/474eb37a-a2e1-434a-b648-9e4b78e604d2@gmail.com
RTL8912AU needs different settings for USB 2 and USB 3.
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/588bf309-4b92-454f-bfd6-5e81248abee3@gmail.com
There are a few differences in the power on/off functions between PCIE
and USB.
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/dccdb944-c31d-483f-8d1a-a51bcfe23916@gmail.com
It uses the same settings as RTL8852CU, but the register and bit names
have "BE" instead of "AX".
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/bd9e444f-257c-48c8-8adb-f58432b2c5c2@gmail.com
Skip most of the function because RTL8922AU only needs to configure the
RX aggregation here.
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/71329cd6-0249-4654-be1d-74c8823f4888@gmail.com
Return early because RTL8922AU doesn't need to do anything here.
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/58bf4dc4-dd4d-4caa-b6c0-e90749769cea@gmail.com
RTL8922AU uses a different register and mask to reset TX/RX. Add them
here.
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/fd6ae7f6-0035-45d8-8832-49a053fd217d@gmail.com
RTL8912AU has 2 bulk in endpoints, not 1, so raise the limit.
The second bulk-in is for USB interrupt mode for SER (system error
recovery) flow. SER is not currently implemented for USB devices in
rtw89.
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/3d30c8d1-fa25-48d0-b27d-7d634c5aa005@gmail.com
USB transport adds significant latency to H2C/C2H round-trips used
by RF calibration. The existing timeout values were designed for PCIe
and are too tight for USB, causing "failed to wait RF DACK",
"failed to wait RF TSSI" and similar errors on USB adapters.
Apply a 4x timeout multiplier when the device uses USB transport.
The multiplier is applied in rtw89_phy_rfk_report_wait() so all
calibrations benefit without changing any call sites or PCIe
timeout values.
The 4x multiplier was chosen based on measured data from two
independent testers (RTL8922AU, 6GHz MLO and 2.4/5GHz):
Calibration PCIe timeout Max measured (USB) 4x timeout
PRE_NTFY 5ms 1ms 20ms
DACK 58ms 72ms 232ms
RX_DCK 128ms 374ms 512ms
TSSI normal 20ms 24ms 80ms
TSSI scan 6ms 14ms 24ms
TXGAPK 54ms 18ms 216ms
IQK 84ms 53ms 336ms
DPK 34ms 30ms 136ms
Tested with RTL8922AU on 6GHz MLO (5GHz + 6GHz simultaneous):
25 connect/disconnect cycles with zero failures.
The 4x multiplier was also verified under adverse host conditions
on 5GHz. 5 cycles per scenario, stress-ng as the load generator,
max observed time per calibration:
Calibration PCIe 4x Baseline CPU stress Mem stress Combined
PRE_NTFY 5 20 0 0 0 1
DACK 58 232 71 (!) 71 (!) 71 (!) 71 (!)
RX_DCK 128 512 23 22 22 23
IQK 84 336 53 53 53 53
DPK 34 136 23 23 26 23
TSSI 20 80 6 9 14 9
TXGAPK 54 216 16 16 16 16
Legend: (!) = exceeds PCIe budget but within 4x budget.
Two observations from that matrix:
1. DACK exceeds the stock PCIe budget (58ms) in baseline on 5GHz
on this hardware. Without the 4x multiplier, DACK fails
-ETIMEDOUT deterministically on every connect, no stress
needed. This is the condition the patch addresses.
2. Calibration times appear dominated by USB transport round-trip
latency rather than host load, though hardware and external
component factors may also contribute. DACK stays at 71ms
across all four scenarios. Host-side stress has essentially
zero effect on observed calibration duration. Bumping the
multiplier above 4x would not address a failure mode that
this stress matrix produces.
Reported-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Link: https://github.com/Lucid-Duck/rtw89-usb3-gap/tree/main/evidence/crash-2026-04-11
Signed-off-by: Louis Kotze <loukot@gmail.com>
Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca> # RTL8922AU (BrosTrend BE6500)
Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca> # RTL8852AU (D-Link DWA-X1850 A1)
Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca> # RTL8852AU (D-Link DWA-X1850 B1)
Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca> # RTL8852BU (BrosTrend AX4L)
Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca> # RTL8852CU (EDUP AX5400)
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260416045536.817930-1-loukot@gmail.com
It was recently reported that rtw_fw_adaptivity_result()
in fw.c dereferences rtwdev->chip->edcca_th without
a NULL check. The issue is that devices with the
8821CE chip don't define edcca_th in their chip
info. As a result, when rtw_fw_adaptivity_result()
tries to dereference it, the kernel triggers an oops.
Add a NULL check for edcca_th before dereferencing
it in rtw_fw_adaptivity_result() in fw.c. Placing
the check at the function entry avoids logging any
garbage values.
This change does not address the root cause for
this behavior, but it prevents the NULL dereference
and the resulting oops while a more permanent solution
is developed.
Tested on a 8822CE chip which defines edcca_th, so
this issue is not present on it, but it still uses
this driver and I can verify there are no regressions.
Suggested-by: Ping-Ke Shih <pkshih@realtek.com>
Reported-by: Oleksandr Havrylov <goainwo@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221286
Signed-off-by: Panagiotis Petrakopoulos <npetrakopoulos2003@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Tested-by: Oleksandr Havrylov <goainwo@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260415052959.14844-1-npetrakopoulos2003@gmail.com
