summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek/rtw89
AgeCommit message (Collapse)Author
2025-02-21wifi: rtw89: 8922a: fix incorrect STA-ID in EHT MU PPDUKuan-Chung Chen
EHT MU PPDU contains user field of EHT-SIG field with STA-ID that must match AID subfield in the Associate Response. Add a necessary setting to prevent these from being inconsistent. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250217061235.32031-1-pkshih@realtek.com
2025-02-21wifi: rtw89: rtw8852b{t}: fix TSSI debug timestampsDmitry Antipov
Since the vendor driver is claimed to measure 'tssi_alimk_time' of 'struct rtw89_tssi_info' in microseconds, adjust rtw8852b{t}-specific '_tssi_alimentk()' to not mess the former with nanoseconds and print both per-call and accumulated times. Compile tested only. Fixes: 7f18a70d7b4d ("wifi: rtw89: 8852b: rfk: add TSSI") Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250213095006.1308810-1-dmantipov@yandex.ru
2025-02-10wifi: rtw89: debugfs depends on CFG80211's onePing-Ke Shih
The wiphy_locked_debugfs_read() and wiphy_locked_debugfs_write() used by rtw89 are defined if CFG80211_DEBUGFS enabled. Add the dependency accordingly. Fixes: 8fdf78f3cd5f ("wifi: rtw89: debugfs: use wiphy_locked_debugfs_{read,write}() if needed") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202502101810.3CUpUL7p-lkp@intel.com/ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250210123105.10466-1-pkshih@realtek.com
2025-02-10wifi: rtw89: regd: avoid using BITMAP_FROM_U64() to assign function bitmapPing-Ke Shih
Since there are two function features for now, func_bitmap[] has single one element, which BITMAP_FROM_U64() generating two elements is exceeded. Change to assign function bitmap barely. With i386-allmodconfig (a 32 bit system), it throws >> include/linux/bitmap.h:736:33: warning: excess elements in array initializer 736 | ((unsigned long) ((u64)(n) >> 32)) | ^ drivers/net/wireless/realtek/rtw89/regd.c:16:34: note: in expansion of macro 'BITMAP_FROM_U64' 16 | .func_bitmap = { BITMAP_FROM_U64(_fmap), }, \ | ^~~~~~~~~~~~~~~ drivers/net/wireless/realtek/rtw89/regd.c:20:9: note: in expansion of macro 'COUNTRY_REGD' 20 | COUNTRY_REGD("00", RTW89_WW, RTW89_WW, RTW89_WW, 0x0); | ^~~~~~~~~~~~ Fixes: 79a36fc56bea ("wifi: rtw89: regd: handle supported regulatory functions by country") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202502031932.BMQ4lhJT-lkp@intel.com/ Cc: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250205014051.13765-1-pkshih@realtek.com
2025-02-10wifi: rtw89: coex: Update Wi-Fi/Bluetooth coexistence version to 7.0.3Ching-Te Ku
Refine the TWS Bluetooth related coexistence mechanism. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250205013233.10945-4-pkshih@realtek.com
2025-02-10wifi: rtw89: coex: To avoid TWS serials A2DP lag, adjust slot arrangementChing-Te Ku
The TWS(True wireless stereo) serials Bluetooth audio device need to keep packet traffic not only with DUT, it also need to synchronize packet with its assistant earbud. And all the BR/EDR Bluetooth device need to do page scan to keep re-connect event sensitively between different DUT. These behavior will make TWS Bluetooth device cost more time slot to keep the good audio performance. This patch decrease half of Wi-Fi slot(from 40ms to 20ms) in a single cycle. Make the slot more flexible to prevent audio lag. The single cycle will be shorter, then it will bring some slot protection cost make Wi-Fi throughput decrease about 5%. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250205013233.10945-3-pkshih@realtek.com
2025-02-10wifi: rtw89: coex: Assign value over than 0 to avoid firmware timer hangChing-Te Ku
If the slot duration is 0, the firmware timer will trigger timer hang at the timer initializing state in a low rate due to hardware algorithm. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250205013233.10945-2-pkshih@realtek.com
2025-02-10wifi: rtw89: fw: validate multi-firmware header before getting its sizePing-Ke Shih
To access firmware elements appended after multi-firmware, add its size as offset to get start address of firmware elements. +-----+-------+------+---------+--------------+ -- | sig | fw_nr | rsvd | version | reserved | \ +---------------------------------------------+ | fw 0 | cv | type | mp | rsvd | shift | size | rsvd | | +---------------------------------------------+ | fw 1 | cv | type | mp | rsvd | shift | size | rsvd | | +---------------------------------------------+ | fw N-1 | ... | | +=============================================+ | mfw size | fw 0 content | | +=============================================+ | | fw 1 content | | +=============================================+ | | ... | | +=============================================+ | | fw N -1 content | | +=============================================+ --/ | fw element TLV X | +=============================================+ | fw element TLV Y | +=============================================+ | fw element TLV Z | +=============================================+ To avoid Coverity warning when getting mfw size, validate it header ahead. Addresses-Coverity-ID: 1544385 ("Untrusted array index read") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250203072911.47313-5-pkshih@realtek.com
2025-02-10wifi: rtw89: fw: validate multi-firmware header before accessingPing-Ke Shih
A firmeware file contains multi-firmware with a header to represent contents. The mfw_hdr->fw_nr is to define number of firmware in file. +-----+-------+------+---------+--------------+ | sig | fw_nr | rsvd | version | reserved | +---------------------------------------------+ -- fw 0 | cv | type | mp | rsvd | shift | size | rsvd | \ +---------------------------------------------+ | fw 1 | cv | type | mp | rsvd | shift | size | rsvd | | mfw_hdr->fw_nr +---------------------------------------------+ | fw N-1 | ... | / +=============================================+ -- | fw 0 content | | (pointed by fw0 shift/size) | +=============================================+ To avoid Coverity warning, validate header is in range of firmware size, and also validate the range of actual firmware content is in range. Addresses-Coverity-ID: 1494046 ("Untrusted loop bound") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250203072911.47313-4-pkshih@realtek.com
2025-02-10wifi: rtw89: ps: update H2C command with more info for PSEric Huang
Adding beacon BW offset, OP1dB table and rfe_type to lps_ml_cmn_info. These information will help FW to configure RX more accurately. Signed-off-by: Eric Huang <echuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250203072911.47313-3-pkshih@realtek.com
2025-02-10wifi: rtw89: call power_on ahead before selecting firmwarePing-Ke Shih
Driver selects firmware by hardware version, which normally can be read from registers before selecting firmware. However, certain chips such as RTL8851B, it needs to read hardware version from efuse while doing power_on, but do power_on after selecting firmware in current flow. To resolve this flow problem, move power_on out from rtw89_mac_partial_init(), and call rtw89_mac_pwr_on() separately at proper places to have expected flow. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250203072911.47313-2-pkshih@realtek.com
2025-02-03wifi: rtw89: pci: not assert wiphy_lock to free early_h2c for PCI probe/removePing-Ke Shih
Except probe/remove flow, the consumers of early_h2c list are interface start and debugfs. There must be no race between probe/remove flow and interface start. The failed probe flow is to free early_h2c list as well as remove flow, at these two moments debugfs doesn't present. Thus, it is safe to free early_h2c list without held wiphy_lock in these situations. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-11-pkshih@realtek.com
2025-02-03wifi: rtw89: remove definition of driver mutexPing-Ke Shih
No consumers of driver mutex now, so remove definition eventually. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-10-pkshih@realtek.com
2025-02-03wifi: rtw89: manual cosmetic along lockdep_assert_wiphy()Ping-Ke Shih
With spatch script, already remove most driver mutex and generate lockdep_assert_wiphy(), and some are needed to refine manually further to be expected: - lockdep_assert_wiphy() always be the first statement in function - return directly rather than unnecessary goto - change assert from mutex to wiphy lock, which script can't convert automatically. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-9-pkshih@realtek.com
2025-02-03wifi: rtw89: remove consumers of driver mutexPing-Ke Shih
All need lock have taken both driver mutex and wiphy lock, so we can remove driver mutex safely by below spatch script. Also, check every lockdep_assert_wiphy() is executed without locks warning at runtime. @ rule1_1 @ @@ - lockdep_assert_held(&rtwdev->mutex); + lockdep_assert_wiphy(rtwdev->hw->wiphy); @ rule1_2 @ @@ - guard(mutex)(&rtwdev->mutex); + lockdep_assert_wiphy(rtwdev->hw->wiphy); @ rule2_1 @ @@ - mutex_lock(&rtwdev->mutex); + lockdep_assert_wiphy(rtwdev->hw->wiphy); ... - mutex_unlock(&rtwdev->mutex); @ rule2_2 @ @@ - mutex_unlock(&rtwdev->mutex); + lockdep_assert_wiphy(rtwdev->hw->wiphy); ... - mutex_lock(&rtwdev->mutex); @ rule3_1 @ type t; identifier fn; @@ t fn(struct wiphy *wiphy, ...) { ... - lockdep_assert_wiphy(rtwdev->hw->wiphy); + lockdep_assert_wiphy(wiphy); ... } @ rule3_1_1 @ type t; identifier fn; @@ t fn(...) { ... struct wiphy *wiphy = ...; ... - lockdep_assert_wiphy(rtwdev->hw->wiphy); + lockdep_assert_wiphy(wiphy); ... } @ rule3_2 @ type t; identifier fn; @@ t fn(struct ieee80211_hw *hw, ...) { ... - lockdep_assert_wiphy(rtwdev->hw->wiphy); + lockdep_assert_wiphy(hw->wiphy); ... } @ rule3_2_1 @ type t; identifier fn; @@ t fn(...) { ... struct ieee80211_hw *hw = ...; ... - lockdep_assert_wiphy(rtwdev->hw->wiphy); + lockdep_assert_wiphy(hw->wiphy); ... } The compiler warnings will be fixed manually by latter patch: rtw89/mac80211.c:371:1: warning: statement expected after label Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-8-pkshih@realtek.com
2025-02-03wifi: rtw89: debugfs: use debugfs_short_fopsPing-Ke Shih
With this change, the object code size can reduce 768 bytes. text data bss dec hex filename 77257 4262 4 81523 13e73 debug.o (before) 76489 4262 4 80755 13b73 debug.o (after) Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-7-pkshih@realtek.com
2025-02-03wifi: rtw89: debugfs: use wiphy_locked_debugfs_{read,write}() if neededPing-Ke Shih
If a debugfs entry takes driver mutex now, let it uses wiphy_locked_debugfs_{read,write}() to take both driver mutex and wiphy lock. Add rwlock option to support this. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-6-pkshih@realtek.com
2025-02-03wifi: rtw89: debugfs: specify buffer size allocated by devm_kazlloc() for ↵Ping-Ke Shih
reading Some debufs entries need output buffer over default size 4K. Since reading of many debugfs entries is to access IO, it costs time to dynamically re-allocate larger buffer and access IO again and again. Add an option to specify the size it needs. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-5-pkshih@realtek.com
2025-02-03wifi: rtw89: debugfs: implement file_ops::read/write to replace seq_filePing-Ke Shih
Since debugfs needs wiphy lock held, wiphy_locked_debugfs_{read,write}() will be adopted, so implmenet file_ops::read/write along with their arguments. For reading part, it needs lots of changes because seq_file is not suitable for wiphy_locked_debugfs_{read,write}(), so use spatch script below to convert basically, and manually implement the functions. @ rule1 @ identifier m; @@ - seq_printf(m, + p += scnprintf(p, end - p, ...) @ rule2 @ identifier m; @@ - seq_puts(m, + p += scnprintf(p, end - p, ...) For current version, only 4K buffer to output. To note ourselves, add ellipsis symbol "..." to trailing if buffer is full. Later, add an option to specify buffer size needed by a debugfs entry. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-4-pkshih@realtek.com
2025-02-03wifi: rtw89: use wiphy_work() to replace ieee802111_work()Ping-Ke Shih
For certain works protected by driver mutex, use wiphy_work() directly to have wiphy lock held naturally. Then every this kind of works is protected by both wiphy lock and driver mutex. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-3-pkshih@realtek.com
2025-02-03wifi: rtw89: add wiphy_lock() to work that isn't held wiphy_lock() yetPing-Ke Shih
To ensure where are protected by driver mutex can also be protected by wiphy_lock(), so afterward we can remove driver mutex safely. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-2-pkshih@realtek.com
2025-02-03wifi: rtw89: cleanup unused rtwdev::roc_workZong-Zhe Yang
The needed one was moved to rtwvif::roc_work. And, rtwdev::roc_work is unused. So, remove it. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250120034004.21135-1-pkshih@realtek.com
2025-02-03wifi: rtw89: regd: refactor init/setup flow and prototypeZong-Zhe Yang
The regulatory and wiphy setup should be done in rtw89_regd_setup(). And, what rtw89_regd_init() should do is to initialize target regulatory domain (regd), if and only if one is programmed in efuse. Since HW is registered after rtw89_regd_setup() and before rtw89_regd_init(), do not fill fields of regulatory in rtw89_regd_init(). So, move the regulatory->reg_6ghz_power assignment into rtw89_regd_setup(). Besides, rtw89_regd_notifier is assigned in rtw89_regd_setup() instead of rtw89_regd_init(). To reduce confusion, stop passing rtw89_regd_notifier to rtw89_regd_init(). And, rename rtw89_regd_init() to rtw89_regd_init_hint(). Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250120032723.19042-4-pkshih@realtek.com
2025-02-03wifi: rtw89: regd: handle supported regulatory functions by countryZong-Zhe Yang
There are two regulatory functions including TAS (Time Average SAR) and DAG (Dynamic Antenna Gain) for now. They are used to improve RF behavior. But, availability depends on country. Extend regd map to record the status of whether a country allows to enable certain regulatory functions. Also, extend the handling of loading regd map via FW element for this. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250120032723.19042-3-pkshih@realtek.com
2025-02-03wifi: rtw89: regd: support loading regd table from fw elementZong-Zhe Yang
Regd table is a table that we use to describe how to map Realtek RF TX power settings on different countries. Originally, a common regd table for all chips is implemented in driver. However, in order to work on all chips, the common regd table might have some trade-off. So now, there are also an individual regd table for some chips. And, we support loading it from FW element. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250120032723.19042-2-pkshih@realtek.com
2025-02-03wifi: rtw89: phy: disable CFO track when two PHY are working simultaneouslyPing-Ke Shih
To have good performance, adjust hardware XTAL to track CFO (carrier frequency offset). However, there is only one hardware XTAL, so it is not possible to track on two PHY simultaneously. It also can't track on single one PHY when two PHY are working, because the adjustment of XTAL will affect all PHY. Thus, disable CFO track for this case. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250117072828.16728-9-pkshih@realtek.com
2025-02-03wifi: rtw89: phy: support EDCCA log per PHYPing-Ke Shih
The registers of EDCCA log for PHY 1 isn't a simple offset, so define them accordingly. Then the function use register set to access reports according to phy_idx. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250117072828.16728-8-pkshih@realtek.com
2025-02-03wifi: rtw89: phy: support EDCCA per PHYPing-Ke Shih
Dynamic mechanism EDCCA (Energy Detection Clear Channel Assessment) is to dynamically adjusted to make EDCCA suitable for situations. Use PHY context to support two PHY. For the EDCCA log part, registers to report EDCCA for PHY 1 is not a simple offset from PHY 0, so add them by separate patch. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250117072828.16728-7-pkshih@realtek.com
2025-02-03wifi: rtw89: phy: support ch_info per PHYPing-Ke Shih
The ch_info is to record current channel info such as minimum RSSI of connected stations, and to assist in dynamic mechanisms of DIG and EDCCA. Move the struct to PHY context, so the dynamic mechanisms can use the info of the same PHY. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250117072828.16728-6-pkshih@realtek.com
2025-02-03wifi: rtw89: phy: support DIG per PHYPing-Ke Shih
DIG standing for dynamic initial gain is to define RX coverage. Adjust this value dynamically to gain good RX performance. Use PHY context to extend DIG algorithm to support two PHY. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250117072828.16728-5-pkshih@realtek.com
2025-02-03wifi: rtw89: phy: support env_monitor per PHYPing-Ke Shih
The env_monitor is to collect information of current operating channel as helper to make decision with better hardware parameters to adopt current environment. Use PHY context as argument to control PHY accordingly, and use rtw89_phy_{write32,read32}_idx with phy_idx to access registers. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250117072828.16728-4-pkshih@realtek.com
2025-02-03wifi: rtw89: phy: add PHY context array to support functions per PHYPing-Ke Shih
To support MLO working on PHY 0 and PHY 1, extend existing PHY dynamic mechanism from PHY 0 to PHY 0/1. Implement a 2 elements array for two PHY instances, and pass pointer of each element as argument to existing functions. Then existing algorithm is kept, unchanged. Also provide iterate and get function to access PHY context. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250117072828.16728-3-pkshih@realtek.com
2025-02-03wifi: rtw89: phy: rename to RTW89_PHY_NUM as proper namingPing-Ke Shih
The meaning is number of PHY, not maximum ID of PHY. Change to proper naming. No change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250117072828.16728-2-pkshih@realtek.com
2025-01-20wifi: rtw89: Correct immediate cfg_len calculation for scan_offload_beLiang Jie
Ensures the correct calculation of `cfg_len` prior to the allocation of the skb in the `rtw89_fw_h2c_scan_offload_be` function, particularly when the `SCAN_OFFLOAD_BE_V0` firmware feature is enabled. It addresses an issue where an incorrect skb size might be allocated due to a delayed setting of `cfg_len`, potentially leading to memory inefficiencies. By moving the conditional check and assignment of `cfg_len` before skb allocation, the patch guarantees that `len`, which depends on `cfg_len`, is accurately computed, ensuring proper skb size and preventing any unnecessary memory reservation for firmware operations not supporting beyond the `w8` member of the command data structure. This correction helps to optimize memory usage and maintain consistent behavior across different firmware versions. Fixes: 6ca6b918f280 ("wifi: rtw89: 8922a: Add new fields for scan offload H2C command") Signed-off-by: Liang Jie <liangjie@lixiang.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250112105144.615474-1-buaajxlj@163.com
2025-01-20wifi: rtw89: coex: Update Wi-Fi/Bluetooth coexistence version to 7.0.2Ching-Te Ku
With this version, fix Wi-Fi scan/connecting/RF calibration triggered A2DP sound lag related issues. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250110015416.10704-4-pkshih@realtek.com
2025-01-20wifi: rtw89: coex: Separated Wi-Fi connecting event from Wi-Fi scan eventChing-Te Ku
Wi-Fi connecting process don't need to assign to firmware slot control, if assign firmware slot control for Wi-Fi connecting event, firmware will not toggle slots because driver don't tell the slot schedule to firmware. Wi-Fi connecting event end should also cancel the 4way handshake status. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250110015416.10704-3-pkshih@realtek.com
2025-01-20wifi: rtw89: coex: Add protect to avoid A2DP lag while Wi-Fi connectingChing-Te Ku
To get a well Wi-Fi RF quality, Wi-Fi need to do RF calibrations. While Wi-Fi is doing RF calibrations, driver will pause the Bluetooth traffic to make sure the RF calibration will not be interfered by Bluetooth. However, if the RF calibrations take too much time, Bluetooth audio will perform a lag sound. Add a function to make Bluetooth can do traffic between the individual calibrations to avoid Bluetooth sound lag. And patch related A2DP coexistence mechanism actions. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250110015416.10704-2-pkshih@realtek.com
2025-01-12wifi: rtw89: 8922ae: add variant info to support RTL8922AE-VSPing-Ke Shih
RTL8922AE-VS is a variant of RTL8922AE, which is supported by firmware version after 0.35.54.0 and only can support up to MCS11. Add a variant struct to describe these requirements accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250108020955.14668-3-pkshih@realtek.com
2025-01-12wifi: rtw89: read hardware capabilities part 1 via firmware commandPing-Ke Shih
Firmware after version 0.35.51.0 defines and exports more hardware capabilities, which driver will consider reported QAM field as EHT MCS capability to register hardware. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250108020955.14668-2-pkshih@realtek.com
2025-01-12wifi: rtw89: fix race between cancel_hw_scan and hw_scan completionPing-Ke Shih
The rtwdev->scanning flag isn't protected by mutex originally, so cancel_hw_scan can pass the condition, but suddenly hw_scan completion unset the flag and calls ieee80211_scan_completed() that will free local->hw_scan_req. Then, cancel_hw_scan raises null-ptr-deref and use-after-free. Fix it by moving the check condition to where protected by mutex. KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] CPU: 2 PID: 6922 Comm: kworker/2:2 Tainted: G OE Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB6WW (2.76 ) 09/10/2019 Workqueue: events cfg80211_conn_work [cfg80211] RIP: 0010:rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core] Code: 00 45 89 6c 24 1c 0f 85 23 01 00 00 48 8b 85 20 ff ff ff 48 8d RSP: 0018:ffff88811fd9f068 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88811fd9f258 RCX: 0000000000000001 RDX: 0000000000000011 RSI: 0000000000000001 RDI: 0000000000000089 RBP: ffff88811fd9f170 R08: 0000000000000000 R09: 0000000000000000 R10: ffff88811fd9f108 R11: 0000000000000000 R12: ffff88810e47f960 R13: 0000000000000000 R14: 000000000000ffff R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8881d6f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007531dfca55b0 CR3: 00000001be296004 CR4: 00000000001706e0 Call Trace: <TASK> ? show_regs+0x61/0x73 ? __die_body+0x20/0x73 ? die_addr+0x4f/0x7b ? exc_general_protection+0x191/0x1db ? asm_exc_general_protection+0x27/0x30 ? rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core] ? rtw89_fw_h2c_scan_offload_be+0x458/0x13c3 [rtw89_core] ? __pfx_rtw89_fw_h2c_scan_offload_be+0x10/0x10 [rtw89_core] ? do_raw_spin_lock+0x75/0xdb ? __pfx_do_raw_spin_lock+0x10/0x10 rtw89_hw_scan_offload+0xb5e/0xbf7 [rtw89_core] ? _raw_spin_unlock+0xe/0x24 ? __mutex_lock.constprop.0+0x40c/0x471 ? __pfx_rtw89_hw_scan_offload+0x10/0x10 [rtw89_core] ? __mutex_lock_slowpath+0x13/0x1f ? mutex_lock+0xa2/0xdc ? __pfx_mutex_lock+0x10/0x10 rtw89_hw_scan_abort+0x58/0xb7 [rtw89_core] rtw89_ops_cancel_hw_scan+0x120/0x13b [rtw89_core] ieee80211_scan_cancel+0x468/0x4d0 [mac80211] ieee80211_prep_connection+0x858/0x899 [mac80211] ieee80211_mgd_auth+0xbea/0xdde [mac80211] ? __pfx_ieee80211_mgd_auth+0x10/0x10 [mac80211] ? cfg80211_find_elem+0x15/0x29 [cfg80211] ? is_bss+0x1b7/0x1d7 [cfg80211] ieee80211_auth+0x18/0x27 [mac80211] cfg80211_mlme_auth+0x3bb/0x3e7 [cfg80211] cfg80211_conn_do_work+0x410/0xb81 [cfg80211] ? __pfx_cfg80211_conn_do_work+0x10/0x10 [cfg80211] ? __kasan_check_read+0x11/0x1f ? psi_group_change+0x8bc/0x944 ? __kasan_check_write+0x14/0x22 ? mutex_lock+0x8e/0xdc ? __pfx_mutex_lock+0x10/0x10 ? __pfx___radix_tree_lookup+0x10/0x10 cfg80211_conn_work+0x245/0x34d [cfg80211] ? __pfx_cfg80211_conn_work+0x10/0x10 [cfg80211] ? update_cfs_rq_load_avg+0x3bc/0x3d7 ? sched_clock_noinstr+0x9/0x1a ? sched_clock+0x10/0x24 ? sched_clock_cpu+0x7e/0x42e ? newidle_balance+0x796/0x937 ? __pfx_sched_clock_cpu+0x10/0x10 ? __pfx_newidle_balance+0x10/0x10 ? __kasan_check_read+0x11/0x1f ? psi_group_change+0x8bc/0x944 ? _raw_spin_unlock+0xe/0x24 ? raw_spin_rq_unlock+0x47/0x54 ? raw_spin_rq_unlock_irq+0x9/0x1f ? finish_task_switch.isra.0+0x347/0x586 ? __schedule+0x27bf/0x2892 ? mutex_unlock+0x80/0xd0 ? do_raw_spin_lock+0x75/0xdb ? __pfx___schedule+0x10/0x10 process_scheduled_works+0x58c/0x821 worker_thread+0x4c7/0x586 ? __kasan_check_read+0x11/0x1f kthread+0x285/0x294 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x6f ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Fixes: 895907779752 ("rtw89: 8852a: add ieee80211_ops::hw_scan") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250107114254.6769-1-pkshih@realtek.com
2025-01-12wifi: rtw89: mcc: consider time limits not divisible by 1024Zong-Zhe Yang
For each MCC role, time limits, including max_tob_us, max_toa_us, and mac_dur_us, are calculated if there are NoA attributes. The relation between these time limits is "max_dur_us = max_tob_us + max_toa_us". Then, the unit is converted from us to TU. However, originally, each time limit was divided by 1024 independently. It missed to consider the cases that max_tob_us or max_toa_us is not divisible by 1024. It causes the result breaks "max_dur (TU) = max_tob (TU) + max_toa (TU)". Finally, when MCC calculates pattern parameters based on these kinds of time limits, it might not perform well. Fixes: b09df09b55fb ("wifi: rtw89: mcc: initialize start flow") Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250103074412.124066-1-pkshih@realtek.com
2025-01-12wifi: rtw89: pci: treat first receiving part as first segment for 8922AEPing-Ke Shih
For early chips, the RX BD info contains FS/LS bits for first/last segments of a receiving packet. For 8922AE, the FS bit should be ignored, or it may throw warning: rtw89_8922ae 0000:1a:00.0: skb should not be ready before first segment start To have compatible logic, FS determined by what pending skb is existing (!new) or not. Since we expect every single receiving packet in single one segment, enlarge 4 bytes for RX BD info, and add a debug message to note if RX buffer is possibly smaller than expected size. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250103025126.15378-1-pkshih@realtek.com
2025-01-12wifi: rtw89: avoid to init mgnt_entry list twice when WoWLAN failedChih-Kang Chang
If WoWLAN failed in resume flow, the rtw89_ops_add_interface() triggered without removing the interface first. Then the mgnt_entry list init again, causing the list_empty() check in rtw89_chanctx_ops_assign_vif() useless, and list_add_tail() again. Therefore, we have added a check to prevent double adding of the list. rtw89_8852ce 0000:01:00.0: failed to check wow status disabled rtw89_8852ce 0000:01:00.0: wow: failed to check disable fw ready rtw89_8852ce 0000:01:00.0: wow: failed to swap to normal fw rtw89_8852ce 0000:01:00.0: failed to disable wow rtw89_8852ce 0000:01:00.0: failed to resume for wow -110 rtw89_8852ce 0000:01:00.0: MAC has already powered on i2c_hid_acpi i2c-ILTK0001:00: PM: acpi_subsys_resume+0x0/0x60 returned 0 after 284705 usecs list_add corruption. prev->next should be next (ffff9d9719d82228), but was ffff9d9719f96030. (prev=ffff9d9719f96030). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:34! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 2 PID: 6918 Comm: kworker/u8:19 Tainted: G U O Hardware name: Google Anraggar/Anraggar, BIOS Google_Anraggar.15217.514.0 03/25/2024 Workqueue: events_unbound async_run_entry_fn RIP: 0010:__list_add_valid_or_report+0x9f/0xb0 Code: e8 56 89 ff ff 0f 0b 48 c7 c7 3e fc e0 96 48 89 c6 e8 45 89 ff ... RSP: 0018:ffffa51b42bbbaf0 EFLAGS: 00010246 RAX: 0000000000000075 RBX: ffff9d9719d82ab0 RCX: 13acb86e047a4400 RDX: 3fffffffffffffff RSI: 0000000000000000 RDI: 00000000ffffdfff RBP: ffffa51b42bbbb28 R08: ffffffff9768e250 R09: 0000000000001fff R10: ffffffff9765e250 R11: 0000000000005ffd R12: ffff9d9719f95c40 R13: ffff9d9719f95be8 R14: ffff9d97081bfd78 R15: ffff9d9719d82060 FS: 0000000000000000(0000) GS:ffff9d9a6fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007e7d029a4060 CR3: 0000000345e38000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: <TASK> ? __die_body+0x68/0xb0 ? die+0xaa/0xd0 ? do_trap+0x9f/0x170 ? __list_add_valid_or_report+0x9f/0xb0 ? __list_add_valid_or_report+0x9f/0xb0 ? handle_invalid_op+0x69/0x90 ? __list_add_valid_or_report+0x9f/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x9f/0xb0 rtw89_chanctx_ops_assign_vif+0x1f9/0x210 [rtw89_core cbb375c44bf28564ce479002bff66617a25d9ac1] ? __mutex_unlock_slowpath+0xa0/0xf0 rtw89_ops_assign_vif_chanctx+0x4b/0x90 [rtw89_core cbb375c44bf28564ce479002bff66617a25d9ac1] drv_assign_vif_chanctx+0xa7/0x1f0 [mac80211 6efaad16237edaaea0868b132d4f93ecf918a8b6] ieee80211_reconfig+0x9cb/0x17b0 [mac80211 6efaad16237edaaea0868b132d4f93ecf918a8b6] ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed] ? dev_printk_emit+0x51/0x70 ? _dev_info+0x6e/0x90 wiphy_resume+0x89/0x180 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed] ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed] dpm_run_callback+0x37/0x1e0 device_resume+0x26d/0x4b0 ? __pfx_dpm_watchdog_handler+0x10/0x10 async_resume+0x1d/0x30 async_run_entry_fn+0x29/0xd0 worker_thread+0x397/0x970 kthread+0xed/0x110 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x38/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Fixes: 68ec751b2881 ("wifi: rtw89: chan: manage active interfaces") Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250103024500.14990-1-pkshih@realtek.com
2025-01-12wifi: rtw89: correct header conversion rule for MLO onlyPo-Hao Huang
Header conversion should only be used with MLO connections. Otherwise P2P connection fails due to wrong probe responses sent. Fix it accordingly. Fixes: b8499664fca9 ("wifi: rtw89: Add header conversion for MLO connections") Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241231004811.8646-4-pkshih@realtek.com
2025-01-12wifi: rtw89: chan: fix soft lockup in rtw89_entity_recalc_mgnt_roles()Zong-Zhe Yang
During rtw89_entity_recalc_mgnt_roles(), there is a normalizing process which will re-order the list if an entry with target pattern is found. And once one is found, should have aborted the list_for_each_entry. But, `break` just aborted the inner for-loop. The outer list_for_each_entry still continues. Normally, only the first entry will match the target pattern, and the re-ordering will change nothing, so there won't be soft lockup. However, in some special cases, soft lockup would happen. Fix it by `goto fill` to break from the list_for_each_entry. The following is a sample of kernel log for this problem. watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [wpa_supplicant:2055] [...] RIP: 0010:rtw89_entity_recalc ([...] chan.c:392 chan.c:479) rtw89_core [...] Fixes: 68ec751b2881 ("wifi: rtw89: chan: manage active interfaces") Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241231004811.8646-3-pkshih@realtek.com
2025-01-12wifi: rtw89: fix proceeding MCC with wrong scanning state after sequence changesZong-Zhe Yang
When starting/proceeding MCC, it will abort an ongoing hw scan process. In the proceeding cases, it unexpectedly tries to abort a non-exist hw scan process. Then, a trace shown at the bottom will happen. This problem is caused by a previous commit which changed some call sequence inside rtw89_hw_scan_complete() to fix some coex problems. These changes lead to our scanning flag was not cleared when proceeding MCC. To keep the fixes on coex, and resolve the problem here, re-consider the related call sequence. The known sequence requirements are listed below. * the old sequence: A. notify coex B. clear scanning flag C. proceed chanctx C-1. set channel C-2. proceed MCC (the problem: A needs to be after C-1) * the current sequence: C. proceed chanctx C-1. set channel C-2. proceed MCC A. notify coex B. clear scanning flag (the problem: C-2 needs to be after B) So, now let hw scan caller pass a callback to proceed chanctx if needed. Then, the new sequence will be like the below. C-1. set channel A. notify coex B. clear scanning flag C-2. proceed MCC The following is the kernel log for the problem in current sequence. rtw89_8852be 0000:04:00.0: rtw89_hw_scan_offload failed ret -110 ------------[ cut here ]------------ [...] CPU: 2 PID: 3991 Comm: kworker/u16:0 Tainted: G OE 6.6.17 #3 Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018 Workqueue: events_unbound wiphy_work_cancel [cfg80211] RIP: 0010:ieee80211_sched_scan_stopped+0xaea/0xd80 [mac80211] Code: 9c 24 d0 11 00 00 49 39 dd 0f 85 46 ff ff ff 4c 89 e7 e8 09 2d RSP: 0018:ffffb27783643d48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff8a2280964bc0 RSI: 0000000000000000 RDI: ffff8a23df580900 RBP: ffffb27783643d88 R08: 0000000000000001 R09: 0000000000000400 R10: 0000000000000000 R11: 0000000000008268 R12: ffff8a23df580900 R13: ffff8a23df581b00 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8a258e680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f26a0654000 CR3: 000000002ea2e002 CR4: 00000000001706e0 Call Trace: <TASK> ? show_regs+0x68/0x70 ? ieee80211_sched_scan_stopped+0xaea/0xd80 [mac80211] ? __warn+0x8f/0x150 ? ieee80211_sched_scan_stopped+0xaea/0xd80 [mac80211] ? report_bug+0x1f5/0x200 ? handle_bug+0x46/0x80 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? ieee80211_sched_scan_stopped+0xaea/0xd80 [mac80211] ieee80211_scan_work+0x14a/0x650 [mac80211] ? __queue_work+0x10f/0x410 wiphy_work_cancel+0x2fb/0x310 [cfg80211] process_scheduled_works+0x9d/0x390 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x15b/0x2d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x108/0x140 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> ---[ end trace 0000000000000000 ]--- Fixes: f16c40acd319 ("wifi: rtw89: Fix TX fail with A2DP after scanning") Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241231004811.8646-2-pkshih@realtek.com
2025-01-07wifi: rtw89: pci: disable PCI completion timeout controlChin-Yen Lee
Realtek's chips follow suggestion of PCIe spec to design the max timeout of PCI completion, but some PCIe host reply too slow to meet it and lead PCI AER. Disable PCI completion timeout function via PCI configuration to avoid the AER. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241225122804.10214-1-pkshih@realtek.com
2024-12-30wifi: rtw89: debug: print regd for QATAR/UK/THAILANDZong-Zhe Yang
The regd enum was extended for these countries. But, the dbgfs doesn't recognize them yet. So, add 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/20241219014545.9157-1-pkshih@realtek.com
2024-12-30wifi: rtw89: adjust thermal protection step and more RTL8852BE-VT IDChih-Kang Chang
To have better tuning of TX duty for fields usage, adjust thermal protection step to 5, then TX duty reduce to 75% at most. Add RTL8852BE-VT ID to enable this function by the way. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241219014511.9056-1-pkshih@realtek.com
2024-12-12wifi: rtw89: phy: add dummy C2H event handler for report of TAS powerPing-Ke Shih
The newer firmware, lik RTL8852C version 0.27.111.0, will notify driver report of TAS (Time Averaged SAR) power by new C2H events. This is to assist in higher accurate calculation of TAS. For now, driver doesn't use the report yet, so add a dummy handler to avoid it throws info like: rtw89_8852ce 0000:03:00.0: c2h class 9 func 6 not support Also add "MAC" and "PHY" to the message to disambiguate the source of C2H event. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241209042127.21424-1-pkshih@realtek.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-05 10:50:40 +0000