summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek/rtw89/fw.c
AgeCommit message (Collapse)Author
2025-05-16wifi: rtw89: fix firmware scan delay unit for WiFi 6 chipsChin-Yen Lee
The scan delay unit of firmware command for WiFi 6 chips is microsecond, but is wrong set now and lead to abnormal work for net-detect. Correct the unit to avoid the error. Fixes: e99dd80c8a18 ("wifi: rtw89: wow: add delay option for net-detect") Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250513125203.6858-1-pkshih@realtek.com
2025-05-16wifi: rtw89: mcc: pass whom to stop at when pausing chanctxZong-Zhe Yang
When stopping MCC, FW can stop at a given MCC role following H2C command. When pausing chanctx during MCC, in general, the caller expects to process things with its chanctx. So, pass the caller as target and let FW stop MCC at 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/20250511035217.10410-2-pkshih@realtek.com
2025-05-10wifi: rtw89: debug: add FW log component for MLOPo-Hao Huang
This allows showing MLO related logs when FW debug mode is on. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250505072440.45113-10-pkshih@realtek.com
2025-05-10wifi: rtw89: add MLO track for MLSR switch decisionPo-Hao Huang
Add MLSR switch mechanism based on tracking RSSI. Switch to a 2 GHz link (if any) when average RSSI is lower than threshold -53. And, switch out from a 2 GHz link when average RSSI is larger than threshold -38. The sequence of MLSR switch handling is like the following. 1. initialize target link and configure to PS mode 2. configure current designated link to PS mode 3. configure target link to non-PS mode 4. deinitialize currently active links except target link The above flow also implies that target link becomes new designated link. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250505072440.45113-7-pkshih@realtek.com
2025-05-10wifi: rtw89: add handling of mlo_link_cfg H2C command and C2H eventZong-Zhe Yang
The mlo_link_cfg H2C command is used to tell FW to enter/leave PS mode on a given link. And, need to wait for status of C2H event to ensure if FW deals with it successfully. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250505072440.45113-6-pkshih@realtek.com
2025-05-05wifi: rtw89: constrain TX power according to dynamic antenna power tableKuan-Chung Chen
Dynamic Antenna Gain (DAG) adjusts TX power based on antenna gain. To prevent signal distortion from excessive power increases, a dynamic antenna power table limits the maximum adjustable TX power. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250430055157.13623-3-pkshih@realtek.com
2025-05-05wifi: rtw89: extend join_info H2C command for MLO fieldsPo-Hao Huang
The join_info H2C command is used to indicate a station is connected and tell FW to create/maintain an instance for it. Extend to fill MLO fields. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-7-pkshih@realtek.com
2025-05-05wifi: rtw89: Configure scan band when mlo_dbcc_mode changesPo-Hao Huang
Previously only the first band is used for scanning. With MLO, update scan parameters accordingly by so we can choose to scan from either band. C2H event return value reflects current scanning band, mask it out so we don't treat correct return value as fail. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-6-pkshih@realtek.com
2025-05-05wifi: rtw89: fw: Remove "const" on allocation typeKees Cook
In preparation for making the kmalloc family of allocators type aware, we need to make sure that the returned type from the allocation matches the type of the variable being assigned. (Before, the allocator would always return "void *", which can be implicitly cast to any pointer type.) The assigned type is "struct rtw89_reg2_def *" but the returned type, while technically matching, will be const qualified. As there isn't a general way to discard "const" qualifiers, adjust the returned type to match the assigned type. No change in allocation size results. Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250426060935.work.049-kees@kernel.org
2025-04-28wifi: rtw89: mcc: make GO announce one-time NoA for HW scan processZong-Zhe Yang
Since FW cannot handle HW scan process and MCC (multi-channel concurrency) mode simultaneously, if a HW scan is requested during MCC, MCC mode will be paused temporarily. Then, the GO role if any might be absent. So, calculate an estimated time for the requested HW scan process and search for existing GO roles to fill one-time NoA. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250422014620.18421-6-pkshih@realtek.com
2025-04-28wifi: rtw89: refactor flow that hw scan handles channel listZong-Zhe Yang
FW has a limited amount of channels that can be dealt with by one HW scan H2C command. Based on the limit, channels in scan request might be parsed into SW structure piece by piece along with multiple HW scan H2C commands. But, in order to estimate things of entire HW scan process, it's required to have the whole parsed channel list when HW scan is going to start. So, tweak HW scan flow to prepare the whole channel list ahead. Still, each HW scan H2C command takes allowed amount of channels from the list according to the limit. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250422014620.18421-5-pkshih@realtek.com
2025-04-28wifi: rtw89: add suffix "_ax" to Wi-Fi 6 HW scan struct and funcZong-Zhe Yang
These stuffs have no suffix, but not universal, and only work for Wi-Fi 6. Since the corresponding HW scan struct/func of Wi-Fi 7 have suffix "_be", to avoid misunderstanding and improve readability, also add suffix "_ax" to these Wi-Fi 6 stuffs. (No logic is changed.) Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250422014620.18421-4-pkshih@realtek.com
2025-04-28wifi: rtw89: 8922a: increase beacon loss to 6 secondsKuan-Chung Chen
Intermittent beacon loss from specific AP triggers disconnection and reconnection. Increasing the beacon loss count will make the connection more stable. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250422014620.18421-2-pkshih@realtek.com
2025-03-31wifi: rtw89: fw: cast mfw_hdr pointer from address of zeroth byte of ↵Ping-Ke Shih
firmware->data The firmware->size is validated before using firmware->data, but Coverity still reports: Downcasting "firmware->data" from "u8 const *" to "struct rtw89_mfw_hdr" implies that the data that this pointer points to is tainted." Using &firmware->data[0] to avoid the warning. No change logic at all. Addresses-Coverity-ID: 1494046 ("Untrusted loop bound") Addresses-Coverity-ID: 1544385 ("Untrusted array index read") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250325025424.14079-1-pkshih@realtek.com
2025-03-31wifi: rtw89: set 2TX for 1SS rate by defaultPing-Ke Shih
To improve performance in range, for 1SS rate, transmit the same signal on 2 antenna, which is called 2TX. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250321034736.6269-1-pkshih@realtek.com
2025-03-13wifi: rtw89: 8922a: enable dynamic antenna gainKuan-Chung Chen
The 8922A now supports dynamic antenna gain. However, in firmware before v0.35.64.0, different transmit powers cannot be applied to each RF path. To comply with regulatory limits in these older firmware, the lower of the two requested transmit powers will be used for both paths when they differ. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250306021144.12854-5-pkshih@realtek.com
2025-03-05wifi: rtw89: fw: don't reject firmware in blacklist to prevent breaking usersPing-Ke Shih
Once update driver blacklist of firmware, users' firmware might be in the list, and then driver stops working. Since breaking users is not expected, report a significant message instead of stopping. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250227131228.8457-5-pkshih@realtek.com
2025-03-05wifi: rtw89: fw: correct debug message format in ↵Ping-Ke Shih
rtw89_build_txpwr_trk_tbl_from_elm() The format should be "%08x". Fix the mistakes. Fixes: d60e73e5dd70 ("wifi: rtw89: fw: load TX power track tables from fw_element") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250227131228.8457-4-pkshih@realtek.com
2025-03-05wifi: rtw89: fw: update role_maintain H2C command for roles operating on band 1Po-Hao Huang
Add new fields band and port ID to make chips operating on the band and port ID other than 0, so that multiple vif(s) can be working at the same time. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250227131228.8457-3-pkshih@realtek.com
2025-03-05wifi: rtw89: fw: use struct to fill role_maintain H2C commandPo-Hao Huang
The role_maintain H2C command is to align operating mode of WiFi role, such as STA or AP modes, between driver and firmware. Use a struct to fill fields of this H2C command. Don't change logic at all. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250227131228.8457-2-pkshih@realtek.com
2025-02-21wifi: rtw89: fw: safely cast mfw_hdr pointer from firmware->dataPing-Ke Shih
Check size of struct mfw_hdr within firmware->size before type casting to ensure to validly dereference fields from mfm_hdr pointer. Then, check if signature field is equal to RTW89_MFW_SIG to assert current is multi-firmware. Addresses-Coverity-ID: 1494046 ("Untrusted loop bound") Addresses-Coverity-ID: 1544385 ("Untrusted array index read") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250217064308.43559-6-pkshih@realtek.com
2025-02-21wifi: rtw89: fw: add debug message for unexpected secure firmwarePing-Ke Shih
If failed to load a non-secure firmware with a secure chip, it only throws a unclear message: rtw89_8922ae 0000:03:00.0: parse fw header fail To address this case simpler, add a message to point out this. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250217064308.43559-5-pkshih@realtek.com
2025-02-21wifi: rtw89: fw: propagate error code from rtw89_h2c_tx()Ping-Ke Shih
The error code should be propagated to callers during downloading firmware header and body. Remove unnecessary assignment of -1. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250217064308.43559-4-pkshih@realtek.com
2025-02-21wifi: rtw89: fw: get sb_sel_ver via get_unaligned_le32()Ping-Ke Shih
The sb_sel_ver is selection version for secure boot recorded in firmware binary data, and its size is 4 and offset is 58 (not natural alignment). Use get_unaligned_le32() to get this value safely. Find this by reviewing. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250217064308.43559-3-pkshih@realtek.com
2025-02-21wifi: rtw89: fw: add blacklist to avoid obsolete secure firmwarePing-Ke Shih
To ensure secure chip only runs expected secure firmware, stop using obsolete firmware in blacklist which weakness or flaw was found. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250217064308.43559-2-pkshih@realtek.com
2025-02-21wifi: rtw89: add H2C command of TX time for WiFi 7 chipsPing-Ke Shih
BT-coexistence configure WiFi TX time to share time slots with Bluetooth devices. Since the format is different from WiFi 6 chips, add the new format accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250217063053.38936-3-pkshih@realtek.com
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-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-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: 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: 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: 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-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-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 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
2024-12-12wifi: rtw89: 8922a: update format of RFK pre-notify H2C command v2Chih-Kang Chang
The RFK pre-notify H2C command is to tell firmware the channels driver is using. Since the format is changed after 0.35.49.0, update it accordingly. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241206055716.18598-8-pkshih@realtek.com
2024-12-12wifi: rtw89: ps: update data for firmware and settings for hardware ↵Eric Huang
before/after PS For MLO supported IC, send H2C command to firmware before PS with link information for each PHY for MLO to work properly. And re-init hardware settings regarding to RX descriptor information after PS. Signed-off-by: Eric Huang <echuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241206055716.18598-4-pkshih@realtek.com
2024-12-12wifi: rtw89: ps: refactor channel info to firmware before entering PSPing-Ke Shih
In PS mode, firmware needs hardware parameters related to channel info to configure hardware itself. Before entering PS, driver prepares these info to firmware via firmware H2C command. Since firmware only consider PS for single one vif, change the argument of entry function to rtwvif, and only consider first link for this old H2C command that only support legacy. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241206055716.18598-3-pkshih@realtek.com
2024-12-05wifi: rtw89: 8852bt: add beacon filter and CQM supportPo-Hao Huang
Declare beacon filter and connection monitor for 8852BT. This offloads connection monitor mechanism to firmware, and this is required for the MCC feature. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241128055433.11851-4-pkshih@realtek.com
2024-12-05wifi: rtw89: 8852b: add beacon filter and CQM supportPo-Hao Huang
Declare beacon filter and connection monitor for 8852B. This offloads connection monitor mechanism to firmware, and this is required for the MCC feature. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241128055433.11851-3-pkshih@realtek.com
2024-12-05wifi: rtw89: 8922a: Extend channel info field length for scanPo-Hao Huang
Extend the bitfield for duration in channel info to 16 bits. Update the related format in H2C and C2H, then increase firmware format sequence to 3. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241128055433.11851-2-pkshih@realtek.com
2024-11-27wifi: rtw89: pass target link_id to ieee80211_nullfunc_get()Zong-Zhe Yang
When calling ieee80211_nullfunc_get(), pass the target link_id instead of always -1. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241120034054.13575-7-pkshih@realtek.com
2024-11-27wifi: rtw89: 8922a: configure AP_LINK_PS if FW supportsZong-Zhe Yang
After FW v0.35.46.0, for AP mode, RTL8922A FW supports a new FW feature, called NOTIFY_AP_INFO, to notify driver information related to AP mode. And, one function of it is to monitor PS states of remote stations. Once one of them changes, FW will send a C2H event to tell driver. With this FW feature, we can declare AP_LINK_PS. For now, driver still needs to determine if a frame is ps-poll or U-APSD trigger. So, add the corresponding RX handling in driver, which activates only when at least one AP is running. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241120034054.13575-2-pkshih@realtek.com
2024-11-06wifi: rtw89: fw: use common function to parse security section for WiFi 6 chipsPing-Ke Shih
The MSSC (multiple security section count) can be regular number (shown in below figure) or 0xFF (supported already). For WiFi 7 or newer WiFi 6 chips, the MSSC will be 0xFF. But early WiFi 6 chip such as RTL8852B could be either one of the cases. Extend __parse_security_section() to support both with/without secure boot mode accordingly. +---------------------------+ -\ | firmware header | | | | | | +-----------------------+ | | | | section type/size * N | | | | +-----------------------+ | | +---------------------------+ -/ : : +---------------------------+ -\ | secure section type (ID:9)| | | | | +----|-> [ security key data ] | | | +---------------------------+ -/ | |MSS Pool for above section | | | [ security key data 1 ] | +----|- [ security key data 2 ] | by mss_idx | [ security key data 3 ] | | ... M | * M = MSSC (MSSC != 0xFF) +---------------------------+ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-8-pkshih@realtek.com
2024-11-06wifi: rtw89: fw: move v1 MSSC out of __parse_security_section() to share with v0Ping-Ke Shih
The security section can be a common parser for v0 and v1 format of firmware header, so move retrieval code of v1 MSSC from the function, and then sharing becomes possible. Not logic change at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-7-pkshih@realtek.com
generated by cgit (git 2.34.1) at 2025-07-25 13:05:10 +0000