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
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
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
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
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
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 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
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
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
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
Deauth frames used wrong link address after switching from default link
to another, causing AP to reject subsequent auth frames. This affected
not only deauth but all management frames. Fixed by setting correct
mac_id to let header conversion references correct address CAM.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251223030651.480633-4-pkshih@realtek.com
Ping-Ke Shih
Dian-Syuan Yang
Kuan-Chung Chen
Chih-Kang Chang
Zong-Zhe Yang
Chin-Yen Lee
Ali Tariq
Bitterblue Smith
Martin Hrůza