RTL8922A (FW >= 0.35.111) and RTL8922D (FW >= 0.35.94) set fcxbtver,
fcxbtscan and fcxbtafh to 8, but the handler in _chk_btc_report only
had branches for version 1 and 7. When version 8 arrived pfinfo was
left NULL and pcinfo->req_len was left at zero, so the length check at
validation stage rejected the report and bt->ver_info.fw was never
written, causing BT_FW:0x0 in the BTC dump.
BT-scan and BT-afh version 8 hit the goto err path for the same reason,
making all BT sub-reports silently broken on these chips.
The structural change in version 8 is that the previously reserved
second byte in each struct is now bt_id (0 = BT0, 1 = BT1), allowing
firmware to send separate reports for each Bluetooth device. All three
structs are otherwise layout-compatible with version 7.
Add rtw89_btc_fbtc_btver_v8, rtw89_btc_fbtc_btscan_v8 and
rtw89_btc_fbtc_btafh_v8 structs with the bt_id field, extend the
corresponding unions, add version 8 branches to _chk_btc_report, and
update _update_bt_report to route each report to BT0 or BT1 according
to BT ID.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260724135640.3195044-11-pkshih@realtek.com
Complete the implementation of _fw_set_gpio() function to support all
GPIO control configuration types for coexistence. Included debug signal,
antenna switch, external I2C mailbox, external PTA related GPIO
configuration. This function is called during initialization and when
BT re-enables.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260724135640.3195044-8-pkshih@realtek.com
In the last error path in rtl_pci_probe(), the cleanup functions are
skipped due to a wrong goto label. Moreover, the successful call to
rtl_init_rfkill(), ieee80211_register_hw(), rtl_debug_add_one() have to
be reverted. Fix this issue by updating the labels and adding the
relevant cleanup functions to the last error path.
Fixes: 0c8173385e ("rtl8192ce: Add new driver")
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260723120118.145383-1-nihaal@cse.iitm.ac.in
Commit 7738a7ab9d ("misc: eeprom: eeprom_93cx6: Add quirk for extra
read clock cycle") added extra 'quirk' field to struct eeprom_93cx6.
Many existing users of eeprom_93cx6, including rtl818x drivers, allocate
the structure on the stack without initializing all fields. As a result,
the added quirk field has an undefined value and can randomly cause
reading wrong data from the EEPROM.
Fix by initializing the structures with {}.
Fixes: 7738a7ab9d ("misc: eeprom: eeprom_93cx6: Add quirk for extra read clock cycle")
Cc: stable@kernel.org # v6.13+
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260723110640.8588-1-stf_xl@wp.pl
The RTL8822CE on the ASUS TUF Gaming A15 FA506II wedges during normal
use. The driver watchdog toggles PCIe ASPM while leaving power save;
the DBI read of the ASPM link-config register fails with -EIO, the PCIe
link becomes unstable, and the device drops off the bus, taking Wi-Fi
down until a cold power cycle:
rtw88_8822ce 0000:03:00.0: failed to read ASPM, ret=-5
rtw88_8822ce 0000:03:00.0: firmware failed to leave lps state
rtw88_8822ce 0000:03:00.0: mac power on failed
This is the same platform ASPM inter-operability problem already
handled for other machines through rtw_pci_quirks[]. Disabling PCI
ASPM and deep power save on this model stops the failure. Add a DMI
quirk so the workaround is applied automatically.
Signed-off-by: Mihail Dimoski <mihaildimoski@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260718124045.23493-1-mihaildimoski@gmail.com
The function to filled up H2C command data is the last step in the driver,
the next step is going to firmware. So the structure version number should
not included driver local branch number (like firmware is v5, but driver
branch to v105), it should be assigned as a explicit version number which
paired with firmware.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717065739.64124-8-pkshih@realtek.com
The CFR (Channel Frequency Response) manual mode condition for 2GHz is
missing to limit on bandwidth for specific channels, which are channel
13 with 20MHz bandwidth and channel 11 with 40MHz bandwidth. Also add
a band check to avoid affecting 5GHz/6GHz bands.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717061910.54466-10-pkshih@realtek.com
Add multicolor LED support for the RTL8852CU valve board to reflect
wireless connection status (by default, green LED is ON when associated
and OFF when disconnected).
Extend the rtw89 LED subsystem with a multicolor path via led_classdev_mc,
for board-level variants with more than one LED GPIO channel.
Add a new RTW89_LEDS_MC Kconfig option and support multicolor LEDs
through led_classdev_mc, with per-channel caching to minimize
redundant register writes. The RTL8852CU valve board is wired up as
the first user, driving a multicolor WRGB LED over four GPIO channels
(8, 18, 16, and 17) that map to LED_COLOR_ID_WHITE/RED/GREEN/BLUE.
Usage:
- Auto-triggered (default):
Green LED ON when connected, OFF when disconnected
- Manual override (e.g., set red; channel order: WHITE RED GREEN BLUE):
echo "0 1 0 0" > /sys/class/leds/rtw89-phyX-multicolor/multi_intensity
echo 1 > /sys/class/leds/rtw89-phyX-multicolor/brightness
Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717061910.54466-3-pkshih@realtek.com
Add a new RTW89_LEDS Kconfig option, along with LED structures to describe
flexible GPIO mappings for chip common LED definition. Core LED lifecycle
and registration logic default to the mac80211 association trigger, and
chips are wired up as the first user with a single-GPIO monochrome LED.
Usage:
- Auto-triggered (default):
ON when connected, OFF when disconnected
- Manual override:
echo <1|0> > /sys/class/leds/rtw89-phyX/brightness
Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260717061910.54466-2-pkshih@realtek.com
The udelay/mdelay helpers set the command source to
RTW89_FW_CMD_OFLD_SRC_OTHER (4), which does not fit the two-bit field
RTW89_H2C_CMD_OFLD_W0_SRC (GENMASK(1, 0)). The le32_encode_bits() masks
it down to 0 (RTW89_FW_CMD_OFLD_SRC_BB), and compiler throws
__field_overflow() error. Fortunately it still works because firmware
ignores the source field for a delay command.
Use RTW89_FW_CMD_OFLD_SRC_MAC as the vendor driver does, and drop the
unused RTW89_FW_CMD_OFLD_SRC_OTHER enumerator.
Reported-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Closes: https://github.com/morrownr/rtw89/issues/111
Fixes: ae3d327515 ("wifi: rtw89: add IO offload support via firmware")
Signed-off-by: Chia-Yuan Li <leo.li@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260714074811.30124-1-pkshih@realtek.com
Even under the same regulation, TX shape may need different settings for
different 6 GHz power types. So, add one more dimension for that. Because
TX shape parameters are not quite large, the 2/5/6 GHz sections are not
divided into different structures. So, the 2/5 GHz sections will also get
the new dimension. To 2/5 GHz sections, fill the TX shape settings with
RTW89_REG_6GHZ_POWER_DFLT (0) field.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260712034506.53209-7-pkshih@realtek.com
TX shape parameters can come from (old way) built-in arrays or (new way)
FW elements. The built-in arrays will no longer be updated, but will be
retained during a certain transition period. However, the format of newer
TX shape parameters are going to be expanded. It will only be applied to
FW elements. To keep built-in arrays compatible during transition period,
add tx shape v0 for old format.
The v0 fields can be removed along with built-in arrays once transition
period ends.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260712034506.53209-6-pkshih@realtek.com
Fix 2.4GHz specific L-SIG length TX issue, causing interoperability problem
with certain APs. Limit the A-MPDU duration to be workaround.
For 8922DE, the MAC limit is 164 ticks, and BB limit is 4608 us. The
conversion is 32.768us / tick. Since smaller limit should be adopted,
BB limit is filled into newly added field.
The units of register and CCTL table are tick and us/512 respectively.
Convert to target unit when filling values.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260712034506.53209-4-pkshih@realtek.com
Update recommend external control slot length to driver. Some of the
Wi-Fi feature has its time slot requirement can not be simply controlled
by coexistence firmware TDMA timer. For example: Wi-Fi scan/MCC etc.
In the same time, coexistence need to tell driver the recommend Bluetooth
slot length to make sure Bluetooth can still has enough time slot to
traffic.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260712030506.43438-11-pkshih@realtek.com
