Assign timeslot to WiFi if power state is on. Since firmware isn't working
at this moment, write scoreboard register to notify BT. Extend the code to
support two BT for coming chips.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260108120320.2217402-3-pkshih@realtek.com
The coex scoreboard is to exchange WiFi and BT profiles, and the coming
chip 8922D changes the design including extend to two scoreboards and
individual register for cfg/get. Follow the changes to abstract current
code, but not change logic for existing chips at all.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260108120320.2217402-2-pkshih@realtek.com
The coming chip RTL8922D has variant of hardware with different AID. Add
AID field to header of firmware elements, and compare AID with the value
read from hardware.
Currently, apply this rule to BB and RF parameters.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260106030911.15528-10-pkshih@realtek.com
CMAC H2C command is to configure CMAC such as TX retry and padding. Add to
update CMAC function block when BT-coex want shorter TX time due to
timeslot assignment, or when MCC want higher retry time to improve
connection rate.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260106030911.15528-8-pkshih@realtek.com
The RFE type 5 should set different DSWR parameters when card power on.
Therefore, add the corresponding register settings for this type.
Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251231090647.56407-12-pkshih@realtek.com
During fuzz testing, it was discovered that bss_conf->beacon_int
might be zero, which could result in a division by zero error in
subsequent calculations. Set a default value of 100 TU if the
interval is zero to ensure stability.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251231090647.56407-11-pkshih@realtek.com
The H2C command rtw89_fw_h2c_rf_pre_ntfy_mcc have different format.
8922A after FW 0.35.49.0 use v0, after FW 0.35.84.0 use v1. The coming
8922D will use v2.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251231090647.56407-10-pkshih@realtek.com
Actually, WITH_RFK_PRE_NOTIFY means supporting one of RFK_PRE_NOTIFY_Vx.
So, change it to be a FW feature group which contains RFK_PRE_NOTIFY_Vx.
Then, because WITH_RFK_PRE_NOTIFY is abandoned after some FW versions by
chip, disable WITH_RFK_PRE_NOTIFY correspondingly in FW feature table.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251231090647.56407-9-pkshih@realtek.com
In the FW feature table, V0 and V1 was configured by lt, less than. So, V1
flag was also set in the range of V0. However, in RFK_PRE_NOTIFY handling,
rtw89_fw_h2c_rf_pre_ntfy, V1 is tested before V0. Things would process as
V1 even if V0 should be used.
Tweak FW feature configuration by ge, greater or equal, to align handling.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251231090647.56407-7-pkshih@realtek.com
Some FW features (groups) may be valid only in a range of FW versions,
i.e. after some FW versions, they can no longer be used. So, introduce
some helper macros to configure this kind of things in FW feature table.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251231090647.56407-6-pkshih@realtek.com
Originally, FW feature map was declared as a u32. But, the number of FW
feature flags is going to be over than 32. So, change it to a BITMAP and
update the corresponding macros.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251231090647.56407-5-pkshih@realtek.com
The Wi-Fi 7 RF calibration flow has a new design which mainly affect
MLO cases. Before, old RFK H2C command can just send the used channels
and MLO mode even if there are multiple active links. After, each RFK
H2C command should send one channel corresponding to one active link.
For example, connect MLD AP (channel X) and then activate second link
(channel X + channel Y)
Before:
RFK#1: channel X (path A + path B)
RFK#2: channel X (path A) + channel Y (path B)
After:
RFK#1: channel X (path A + path B)
[set MLO mode to focus on 2nd link/channel]
RFK#2: channel Y (path A + path B)
[set MLO mode back to target case]
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251231090647.56407-4-pkshih@realtek.com
The pre-notify is to notify firmware the configured channels, and then
RF calibration in firmware can use these values to calibrate RF properly.
Since we need more information, change and add the new H2C command format.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251231090647.56407-3-pkshih@realtek.com
The H2C command of RFK pre info is to tell current operating channels to
firmware, so RF calibrations can rely on these information as arguments
to configure hardware.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251231090647.56407-2-pkshih@realtek.com
If the driver supports ack status reports of TX frames, mac80211 allows it
to detect AP if it's alive and determine whether the client can maintain
the connection by sending null-data. Therefore, refine the flow to let
driver inform mac80211 to enable beacon loss work to track AP's status
upon receiving beacon loss event.
Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251229030926.27004-13-pkshih@realtek.com
When inactive, 6 GHz power type has been assigned to the default one,
but missed to mark the local control variable, dflt, true. Then, this
might let some 6 GHz power info of disconnected APs keep being taken
into account under certain cases.
So, mark default when inactive.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251229030926.27004-12-pkshih@realtek.com
8922a supports SCAN_OFFLOAD_EXTRA_OP feature. Enable it, FW can do
back-op and TX NULL frames on the second connection.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251229030926.27004-11-pkshih@realtek.com
When scan with 2 OP channels, for the case like
not-connect(macid 0) + GO(macid 1) or not-connect(macid 0) + GC(macid 1),
the macid 0 doesn't offload NULL data packet to FW. Therefore, refine the
NULL data judgement to let interfaces that only connected and non-AP mode
need to TX nulldata.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251229030926.27004-10-pkshih@realtek.com
Hardware version from efuse prioritizes to the version from register.
For WiFi 7 chips, this becomes required, so implement this in common flow.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251229030926.27004-7-pkshih@realtek.com
Since TX/RX aggregation is different from chip to chip, define individual
number according to hardware ability. Also the coming chip RTL8922DE
can get expected performance.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251229030926.27004-6-pkshih@realtek.com
The coming RTL8922DE use different register and its bit to poll if DMA
becomes idle before entering WoWLAN. Abstract to share common flow.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251229030926.27004-5-pkshih@realtek.com
For WOW_CAM update function, 8922DE use different H2C command from 8922AE.
Use chip to distinguish them.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251229030926.27004-4-pkshih@realtek.com
The WoWLAN pattern mask is generated in byte stream, and actually firmware
expects to see the same byte stream too. Since these byte stream is sent
to firmware with 32-bit stream in little-endian order. Change to mask
to __le32, and just do assignment instead of le32 conversion to wkfm fields
of H2C command.
For little-endian machine, it doesn't change logic at all.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251229030926.27004-3-pkshih@realtek.com
The WOW CAM H2C command is used to tell firmware the content
of pattern match. Use struct instead of macros to fill the data.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251229030926.27004-2-pkshih@realtek.com
The driver does not set hw->sta_data_size, which causes mac80211 to
allocate insufficient space for driver private station data in
__sta_info_alloc(). When rtl8xxxu_sta_add() accesses members of
struct rtl8xxxu_sta_info through sta->drv_priv, this results in a
slab-out-of-bounds write.
KASAN report on RISC-V (VisionFive 2) with RTL8192EU adapter:
BUG: KASAN: slab-out-of-bounds in rtl8xxxu_sta_add+0x31c/0x346
Write of size 8 at addr ffffffd6d3e9ae88 by task kworker/u16:0/12
Set hw->sta_data_size to sizeof(struct rtl8xxxu_sta_info) during
probe, similar to how hw->vif_data_size is configured. This ensures
mac80211 allocates sufficient space for the driver's per-station
private data.
Tested on StarFive VisionFive 2 v1.2A board.
Fixes: eef55f1545 ("wifi: rtl8xxxu: support multiple interfaces in {add,remove}_interface()")
Cc: stable@vger.kernel.org
Signed-off-by: Ali Tariq <alitariq45892@gmail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251225115430.13011-1-alitariq45892@gmail.com
Internally wiphy writes to individual channels in this structure,
so we must not share one static definition of channel list between
multiple device instances, because that causes hard to debug
breakage.
For example, with two rtw88 driven devices in the system, channel
information may get incoherent, preventing channel use.
Copied from commit 0ae36391c8 ("wifi: rtw89: Fix inadverent sharing
of struct ieee80211_supported_band data").
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/e94ad653-2b6d-4284-a33c-8c694f88955b@gmail.com
Simplify the code by using device managed memory allocations.
This also fixes a memory leak in rtw_register_hw(). The supported bands
were not freed in the error path.
Copied from commit 145df52a86 ("wifi: rtw89: Convert
rtw89_core_set_supported_band to use devm_*").
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/1aa7fdef-2d5b-4a31-a4e9-fac8257ed30d@gmail.com
The driver reduces the RX gain while connected to a network located
close by. In this condition scans return few results because the more
distant networks can't be heard.
Temporarily increase the RX gain before scanning in order to detect
all available networks. Reset the RX gain back to the last recorded
value once the scan finishes.
Link: https://github.com/lwfinger/rtw88/issues/337
Signed-off-by: Martin Hrůza <martin.hruza123@gmail.com>
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/c2e72aff-190d-4f59-9914-2588de756385@gmail.com
For BE chips, needs to transmit QoS null data periodically to ensure
the connection with AP in GC+STA mode. However, in environments
with interference, the Qos null data might fail to transmit
successfully. Therefore, when receive the beacon from AP will
reset the QoS null data failure counter to avoid unnecessary
disconnection.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251223030651.480633-13-pkshih@realtek.com
When initializing mac port, needs to set TBTT AGG number to trigger TBTT
related interrupts. Otherwise, after sending join info H2C command with
disconnection mode, firmware will clear TBTT AGG number. Without the
setting from mac port initialization after that, this port will not be
able to transmit beacons.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251223030651.480633-12-pkshih@realtek.com
XTAL SI is an indirect serial interface to access registers in another
hardware domain. When BT driver initializes UART interface, firmware might
rarely control XTAL SI at the same time causing access racing.
Current is to adjust initialization flow to avoid the racing. To make
the racing visible if it still presents, add a message to address this.
USB adapters might be unplugged suddenly, causing flooding messages. Check
RTW89_FLAG_UNPLUGGED flag to avoid them.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251223030651.480633-11-pkshih@realtek.com
The each of C2H reg event have different polling timeout. Refine the
LPS C2H reg event polling timeout. Otherwise, during SER, the FW has
already crashed, the leave LPS check will wait until timeout expires,
causing the SER recovery to take too long.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251223030651.480633-10-pkshih@realtek.com
Original methods of SER (system error recovery) L0/L1 simulations need
to leave PS mode before working. Introduce new methods to simulate SER
L0/L1 and they can work under PS. Since new methods require FW support,
so add a FW feature flag and configure the supported chips.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251223030651.480633-9-pkshih@realtek.com
Originally, polling FW status was required during recovering from L1.
Now, because newer FW support event mode, the polling can be skipped.
Add a FW feature flag and configure the supported chips.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251223030651.480633-7-pkshih@realtek.com
After recovering from L1, explicitly enable error IMR to ensure next
L1 SER (system error recovery) can work normally.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251223030651.480633-6-pkshih@realtek.com
To run power on function properly, reset power states (off/on/PS) to
initial state. Otherwise, it might be unusable due to fail to power on.
Since a USB adapter might play as USB mass storage with driver and then
switch to WiFi adapter, causing it stays on power-on state when doing WiFi
USB probe. Exclude this case.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251223030651.480633-5-pkshih@realtek.com
