summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek/rtw89/rtw8852b.c
AgeCommit message (Collapse)Author
2025-05-05wifi: rtw89: 8922a: use SW CRYPTO when broadcast in MLO modePo-Hao Huang
8922A doesn't support broadcast/multicast traffic under MLO mode. So let mac80211 do the encryption/decryption for us when the connection is in MLO mode. Future BE ICs fixes this issue. 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-3-pkshih@realtek.com
2025-03-31wifi: rtw89: 8852bx: support different SAR configs by antennaZong-Zhe Yang
Calculate difference of SAR configs between RF path A and RF path B. And then, based on the calculated result, set the TX power reference CR (control register). Finally, declare to support SAR by antenna in 8852b/8852bt chip info. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250326020643.14487-13-pkshih@realtek.com
2025-03-31wifi: rtw89: sar: add skeleton for different configs by antennaZong-Zhe Yang
Some SAR sources, e.g. ACPI, may allow different SAR configs by antenna. Previously, the minimum config between antennas was taken. Because there are differences between HW design, different chips might have different solutions to achieve this. So, it cannot be done through a single common handling. Now, add the relevant skeleton for this purpose ahead. First, add a flag into chip info to describe whether it has implemented this function or not. Second, support to query SAR config for a given RF path. With it, each chip can implement its own handling. Then, if a chip declares to support this function, when it queries SAR config without a given RF path, it gets a maximum config between antennas. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250326020643.14487-10-pkshih@realtek.com
2025-03-13wifi: rtw89: refine mechanism of TASKuan-Chung Chen
TAS state switching mechanism now incorporates the TX ratio as a decision parameter. The average power calculation has been improved by using a higher resolution conversion from dBm to linear. During scan or MCC operations, TAS state is forced to static SAR and suspend the average power calculation. Additionally, TAS window size depends on the regulatory domain and band to ensure compliance. TAS is enabled when permitted by the regulatory domain and is currently supported on the 8852CE. For debugging, add a flag to disable_dm that can stop TAS mechanism. Co-developed-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> 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-3-pkshih@realtek.com
2025-02-27wifi: rtw89: Parse channel from IE to correct invalid hardware reports ↵Chih-Kang Chang
during scanning For some packets, we could not get channel information from PPDU status. And this causes wrong frequencies being reported. Parse the channel information from IE if provided by AP to fix this. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250220064357.17962-1-pkshih@realtek.com
2025-02-27wifi: rtw89: add support for HW TKIP cryptoKuan-Chung Chen
For 8852BTE, 8852CE, and 8922AE, TKIP encryption and decryption will be handled by hardware. All other chips will retain their existing software-based encryption and decryption. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250220062344.15836-1-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-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-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
2024-12-05wifi: rtw89: 8922a: use RSSI from PHY report in RX descriptorChih-Kang Chang
The PPDU status of probe response will fail to parse the IE due to being filtered by the to_self check. Therefore, we parse RSSI from PHY report in RX descriptor. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241128055433.11851-5-pkshih@realtek.com
2024-11-18wifi: rtw89: handle different TX power between RF pathKuan-Chung Chen
The dynamic antenna gain (DAG) may independently apply different TX powers for each RF path. This can be accomplished by using the larger TX power as the reference path and adjusting the TX power of the other path based on the difference. Currently only 8852BE/8852BTE/ 8852CE are supported. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241111065132.19587-4-pkshih@realtek.com
2024-11-18wifi: rtw89: introduce dynamic antenna gain featureKuan-Chung Chen
Dynamic Antenna Gain (DAG) adjusts the transmit power based on the platform's antenna gain. This allows for higher transmit power when the antenna gain is lower, while still complying with regulatory limits. The driver reads the Realtek Antenna Gain (RTAG) data from BIOS, and DAG is only enabled when the regulatory domain allows it. Currently, it only supports 8852BE/8852BTE/8852CE. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241111065132.19587-3-pkshih@realtek.com
2024-10-25wifi: rtw89: add thermal protectionPing-Ke Shih
To prevent chip overheating, reduce TX duty as the mechanism of thermal protection. When temperature is raising over a threshold, send a firmware command to reduce TX duty. If temperature is still raising, higher level is adopted to have lower active duration. The equation and unit of thermal values are different from chip to chip, so define constant thresholds of thermal value to corresponding absolute temperature of 110 and 120 degree Celsius. Latter patch will decide which thermal threshold is adopted, and current is still not enable thermal protection. For debugging, add a flag to disable_dm that thermal protection can be disabled to clarify low throughput in field. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241016133735.7571-2-pkshih@realtek.com
2024-10-20wifi: rtw89: 8852b: use 'int' as return type of error code pwr_{on,off}_func()Ping-Ke Shih
The return type of error code of rtw8852b_pwr_{on,off}_func() and its callee is 'int'. Correct it. Addresses-Coverity-ID: 1622433 ("Overflowed constant") Addresses-Coverity-ID: 1630710 ("Overflowed constant") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241009004300.8144-5-pkshih@realtek.com
2024-09-24wifi: rtw89: rename rtw89_vif to rtw89_vif_link ahead for MLOZong-Zhe Yang
This is an intermediate version that is separated from subsequent major MLO changes, so some functions' namings are not really determined here. e.g. struct rtw89_vif_link *vif_to_rtwvif_safe(struct ieee80211_vif *vif) 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/20240916053158.47350-2-pkshih@realtek.com
2024-09-05wifi: rtw89: use frequency domain RSSIEric Huang
To get more accurate RSSI, this commit includes frequency domain RSSI info in RSSI calculation. Add correspond physts parsing and macro to get frequency domain RSSI information for supported IC. Signed-off-by: Eric Huang <echuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240828055217.10263-3-pkshih@realtek.com
2024-08-27wifi: rtw89: introduce chip support link number and driver MLO capabilityZong-Zhe Yang
Configure supported link number by chip. And, introduce driver capability flag for MLO. Driver should depend on runtime FW features and chip info to determine whether to set the MLO capability flag or not. Once the MLO flag is set, driver will consider/register/initialize things for MLO usages. However, we just add the driver MLO capability flag ahead and don't really set it. Then, we can start to tweak driver architecture for MLO. Some code should depend on this flag. And after tweaking driver architecture is done, we will set it based on runtime conditions as mentioned above. Besides, MLD number supported by HW should be chip supported mac_id number / chip supported link number Without driver MLO capability flag, we allocate stations based on supported mac_id number. With driver MLO capability flag, we allocate stations based on supported MLD number. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240819091724.33730-9-pkshih@realtek.com
2024-08-27wifi: rtw89: 8852bx: use right chanctx whenever possible in RFK flowZong-Zhe Yang
No longer access chan with hard-code RTW89_CHANCTX_X whenever possible. Instead, obtain the right chanctx from somewhere and use it in RTL8852BX RFK (RF calibration) related code. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240819091724.33730-5-pkshih@realtek.com
2024-08-27wifi: rtw89: pass chan to rfk_band_changed()Zong-Zhe Yang
Originally, all chips have implemented rfk_band_changed() and access chan with hard-code RTW89_CHANCTX_0 in it. But, it's problematic when the chip supports multiple channels. So, change the prototype of rfk_band_changed() and pass chan ahead. And, we will refine the implementation of each chip in the following. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240819091724.33730-2-pkshih@realtek.com
2024-08-16wifi: rtw89: 8922a: add digital compensation to avoid TX EVM degradeKuan-Chung Chen
TX EVM will significantly decrease for long packets when the TX idle time increases. Introduce digital compensation based on TX idle time, to mitigate TX EVM degradation, and TX throughput improved from 1871 to 1947 Mbps. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240809072012.84152-3-pkshih@realtek.com
2024-08-07wifi: rtw89: add support for HW encryption in unicast management framesKuan-Chung Chen
Add hardware encryption support for unicast management frames for 8922AE and 8852CE. Other chips will continue to use software encryption for unicast management frames. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240731070506.46100-5-pkshih@realtek.com
2024-08-02wifi: rtw89: pass rtwvif to RFK scanZong-Zhe Yang
For chips supporting multiple channels, they need to get target info from rtwvif, e.g. PHY index and Chanctx index. So, change rfk_scan prototype and pass rtwvif ahead. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-6-pkshih@realtek.com
2024-08-02wifi: rtw89: pass rtwvif to RFK channelZong-Zhe Yang
For chips supporting multiple channels, they need to get target info from rtwvif, e.g. PHY index and Chanctx index. So, change rfk_channel prototype and pass rtwvif ahead. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-5-pkshih@realtek.com
2024-08-02wifi: rtw89: add support for hardware rfkillKuan-Chung Chen
Add support for ieee80211::rfkill_poll ops. This enables periodic monitoring of the hardware rfkill state, triggering updates when the status changes. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240724052626.12774-3-pkshih@realtek.com
2024-07-05wifi: rtw89: 8852bx: move BTC common code from 8852b to 8852b_commonPing-Ke Shih
The BT coexistence part of 8852B and 8852BT are similar, so move shared code into common module. Don't change logic for existing RTL8852BE. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240701014619.7300-1-pkshih@realtek.com
2024-06-27wifi: rtw89: 8852b: set AMSDU limit to 5000Ping-Ke Shih
Enlarge AMSDU limit to improve MAC efficient to get better TX throughput from 851 to 895 Mbps. No change for RX throughput 902 Mbps. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240621123617.6687-1-pkshih@realtek.com
2024-06-27wifi: rtw89: wow: update WoWLAN reason register for different FWChih-Kang Chang
Need to update WoWLAN wakeup reason register after firmware version 0.35.22.0 for RTL8922A, and 0.27.80.0 for RTL8852CE. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240620055825.17592-3-pkshih@realtek.com
2024-06-17wifi: rtw89: 8852bx: move common code from 8852b to 8852b_commonPing-Ke Shih
New upcoming chip is RTL8852BE-VT (or RTL8852BTE; 8852BT PCIE interface), which is a variant of 8852B, and many codes excepting to RF calibration can be shared, so move common code to an new kernel module named rtw89_8852b_common.ko. No logic change. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240607070659.80263-2-pkshih@realtek.com
2024-05-23wifi: rtw89: 8852b: restore setting for RFE type 5 after device resumePing-Ke Shih
The RFE type 5 set SPS analog parameters only once at probe stage, but the setting is missing after suspend/resume, so remove restriction and set the value when card power on/off. Fixes: 3ef60f44830a ("wifi: rtw89: 8852b: update hardware parameters for RFE type 5") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240517013543.11533-1-pkshih@realtek.com
2024-05-14wifi: rtw89: support mac_id number according to chipZong-Zhe Yang
On 802.11be chips, to consider MLO, HW doesn't design number of support mac_id as large as before. And, it might be various according to chip. For example, old chips support mac_id up to 128, but RTL8922a only supports mac_id up to 32. Besides, the mac_id acquiring function will be extended when impending MLO support. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240509090646.35304-5-pkshih@realtek.com
2024-05-02wifi: rtw89: reset AFEDIG register in power off sequenceChin-Yen Lee
Some Wi-Fi chips meet card lost issue due to unstable hardware signal of GPIO pins during power off. Reset AFEDIG register before BB reset in power off sequence could avoid unstable signal and fix the issue. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240426061200.44262-1-pkshih@realtek.com
2024-04-29wifi: rtw89: 8852b: update hardware parameters for RFE type 5Ping-Ke Shih
RFE type 5 of 8852B is a type of hardware module, which can use different external components, so update register settings accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240423121247.24714-2-pkshih@realtek.com
2024-04-03wifi: rtw89: 8922a: download template probe requests for 6 GHz bandPo-Hao Huang
8922a FW supports RNR parsing, provide template probe requests and let FW do the replacement for SSID/BSSID/short SSIDs. Don't declare WIPHY_FLAG_SPLIT_SCAN_6GHZ so proper IEs such as 6 GHz capabilities can be passed down within the same scan request. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240328052656.18823-3-pkshih@realtek.com
2024-03-05wifi: rtw89: wow: update WoWLAN reason register for different chipsChin-Yen Lee
The WoWLAN reason register is used for driver to get the wakeup reason for reporting to cfg80211, and it is different from chips. So put it into chip information. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240302005828.13666-2-pkshih@realtek.com
2024-03-05wifi: rtw89: coex: add init_info H2C command format version 7Ching-Te Ku
To avoid using bit fields for H2C command, rearrange the structure. And also patch the corresponding code for the using of this structure. No logic changes for existing chips. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240229074514.219276-4-pkshih@realtek.com
2024-02-06wifi: rtw89: 8922a: add chip_ops::rfk_hw_initPing-Ke Shih
Add a chip_ops for WiFi 7 chips to set additional RF configurations including MLO and PLL settings. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240202030642.108385-12-pkshih@realtek.com
2024-02-06wifi: rtw89: 8922a: add chip_ops::rfk_init_late to do initial RF ↵Ping-Ke Shih
calibrations later The RF calibrations are moved into firmware, so we trigger calibrations by H2C commands and wait for C2H completion events. However, these events can be received only after HCI (i.e. PCI for now) starts, so we should do initial RF calibrations after that. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240202030642.108385-11-pkshih@realtek.com
2024-01-23wifi: rtw89: 8922a: add chip_ops related to BB initPing-Ke Shih
The chip_ops::bb_preinit and ::bb_postinit are called before and after loading BB parameters from tables of firmware file. The ::bb_reset is used to reset hardware state, and currently it is not needed by 8922AE so leave it as empty. The ::bb_sethw is to implement conditional parameters. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240120003831.7014-4-pkshih@realtek.com
2024-01-18wifi: rtw89: fw: add H2C command to reset DMAC table for WiFi 7Ping-Ke Shih
Reset DMAC table, so we get expected behavior instead of random values at early stage. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240115033742.16372-7-pkshih@realtek.com
2024-01-18wifi: rtw89: fw: add H2C command to reset CMAC table for WiFi 7Ping-Ke Shih
Do reset on CMAC tables by mac_id, so we don't get random values when powering on. Therefore, add the same function for WiFi 7 chips. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240115033742.16372-6-pkshih@realtek.com
2024-01-18wifi: rtw89: fw: update TX AMPDU parameter to CMAC tablePing-Ke Shih
The CMAC table is used to define how hardware TX a certain packet, and we can specify TX AMPDU size, so hardware can prepare proper retry window buffer. Otherwise, it can't transmit with expected aggregation number. Since each TID could have different aggregation number, the smallest number is adopted to prevent over peer's receiving buffer. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240115033742.16372-5-pkshih@realtek.com
2024-01-18wifi: rtw89: fw: add chip_ops to update CMAC table to associated stationPing-Ke Shih
For WiFi 7 chips, we add H2C command with rich fields to support MLO, so add a chip_ops to generalize calling of update CMAC table. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240115033742.16372-4-pkshih@realtek.com
2024-01-18wifi: rtw89: change supported bandwidths of chip_info to bit maskPing-Ke Shih
Basically, all chips can support 20/40/80MHz bandwidth, and 8952C can support 160MHz bandwidth, which is why we introduced support_bw160 before. The coming WiFi 7 chips will support 320MHz optionally, so change it to bit mask instead of adding another support_bw320. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240112062640.36922-3-pkshih@realtek.com
2024-01-12wifi: rtw89: add chip_ops::update_beacon to abstract update beacon operationPing-Ke Shih
Since coming WiFi 7 and existing chips use different update_beacon() format, add to abstract selection of H2C command. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240108091359.67636-1-pkshih@realtek.com
2024-01-12wifi: rtw89: add chip_ops::h2c_ba_cam() to configure BA CAMPing-Ke Shih
Since chips could use different version of BA CAM H2C command, add a chip_ops to abstract the operation. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240108091134.67007-4-pkshih@realtek.com
2024-01-10wifi: rtw89: phy: move bb_gain_info used by WiFi 6 chips to unionPing-Ke Shih
WiFi 7 chips use different bb_gain_info struct, so move existing struct to a union in advance. This doesn't change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240105064228.36580-2-pkshih@realtek.com
2023-12-07wifi: rtw89: 8922a: add SER IMR tablesPing-Ke Shih
To activate SER (system error recovery) in firmware, we have to configure IMR to trigger interrupts, and then SER can check registers to know if it need to reset hardware or notify driver to re-configure whole settings. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231204080751.15354-4-pkshih@realtek.com
2023-12-01wifi: rtw89: refine element naming used by queue empty checkZong-Zhe Yang
In queue empty check, one group contains 32 queues. And, the two elements, wde_qempty_acq_num and wde_qempty_mgq_sel, are number of group and select of group. To avoid confusing them with queue number and queue selection, we refine their naming. (don't change logic at all) Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231124071703.132549-5-pkshih@realtek.com
2023-11-30wifi: rtw89: phy: dynamically adjust EDCCA thresholdYi-Chen Chen
Add dynamic mechanism EDCCA (Energy Detection Clear Channel Assessment) in track work. Using a fixed-value threshold will make EDCCA particularly sensitive and cause failure to transmit under certain circumstances. Therefore, the threshold is dynamically adjusted to make EDCCA suitable for any situation. However, in some cases, we will adjust the EDCCA threshold to the highest level so that urgent transmissions can be performed successfully, such as scanning. Finally, in order to observe the EDCCA report in time, add the EDCCA perIC register macro and EDCCA HW report analysis. EDCCA logs can be displayed by using the EDCCA debug mask. Signed-off-by: Yi-Chen Chen <jamie_chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231122060458.30878-3-pkshih@realtek.com
generated by cgit (git 2.34.1) at 2025-07-31 05:13:55 +0000