summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek/rtw89/rtw8851b.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: 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: 8851b: use 'int' as return type of error code pwr_{on,off}_func()Ping-Ke Shih
The return type of error code of rtw8851b_pwr_{on,off}_func() and its callee is 'int'. Correct it. Addresses-Coverity-ID: 1624679 ("Overflowed constant") Addresses-Coverity-ID: 1630970 ("Overflowed constant") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241009004300.8144-4-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: 8851b: 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 RTL8851B 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-3-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: rename sub_entity to chanctxZong-Zhe Yang
Originally, we planed to fill MAC_0/1 indicators with chanctx and use sub_entity_xxx for these things. However, there are some reasons listed below which make us give up this plan after we know our Wi-Fi 7 HW design. 1. one link is bound to one HW band during its life time but, one link might change chanctx dynamically 2. in concurrent mode, assume 1st vif is MLD 1st vif's 2nd link might use the same chanctx as 2nd vif but, they are not on the same HW band So, we let sub_entity_xxx stuffs deal with only chanctx now. And, to be more readable, we rename sub_entity related words to chanctx. 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/20240727080650.12195-4-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-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-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-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
2023-11-22wifi: rtw89: mac: add to access efuse for WiFi 7 chipsPing-Ke Shih
MAC address, hardware type, calibration values and etc are stored in efuse, so we read them at probe stage and use them as capabilities to register hardware. There are two physical efuse -- one is the main efuse for digital hardware part, and the other is for analog part. Because they are very similar, we only describe the main efuse below. The main efuse is split into two regions -- one is for logic map, and the other is for physical map. For both regions, we use the same method to read data, but need additional parser to get logic map. To allow reading operation, we need to convert power state to active, and turn to idle state after reading. For WiFi 7 chips, we introduce efuse blocks to define feature group easier, and these blocks are discontinue. For example, RF block is from 0x1_0000 ~ 0x1_0240, and the next block PCIE_SDIO is starting from 0x2_0000. Comparing to old one used by WiFi 6 chips, there is only single one logic map, it would be a little hard to add an new field to a group if we don't reserve a room in advance. The relationship between efuse, region and block is shown as below: (logical map) +------------+ +---------------+ +-----------------+ | main efuse | | region 1 | | block 0x1_0000~ | | (digital) | |(to logcal map)| +-----------------+ | | | | => +-----------------+ | | => | | | block 0x2_0000~ | | | | | +-----------------+ | | |---------------| : | | | region 2 | +------------+ +---------------+ +------------+ +-----------------+ | 2nd efuse | ======================> | block 0x7_0000~ | | (analog) | +-----------------+ +------------+ The parser converting from raw data to logic map is to decode block page, block page offset, and word_en bits. Each word_en bit indicates two following bytes as data of logic map, so total four word_en bits can represent eight bytes. Thus, block page offset is 8-byte alignment. The layout of a tuple is shown as below +--------+--------+--------+--------+--------+--------+ | fixed 3 byte header | | | | | | | | | | [19:17] block_page | | | ... | | [16:4] block_page_offset| | | | | [3:0] word_en | ^ | ^ | | +----|---+--------+--------+---|----+----|---+--------+ | | | +-------------------------+---------+ a word_en bit indicates two bytes as data For example, block_page = 0x3 block_page_offset = 0x80 (must 8-byte alignment) word_en = 0x6 (b'0110; 0 means data is presented) following 4 bytes = 34 56 78 90 Then, 0x3_0080 = 34 56 0x3_0086 = 78 90 A special block page is RTW89_EFUSE_BLOCK_ADIE (7) that uses different but similar format, because its real efuse size is smaller than main efuse. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231117024029.113845-4-pkshih@realtek.com
2023-10-30wifi: rtw89: configure PPDU max user by chipZong-Zhe Yang
Different chip can support different max user in one PPDU report. So, we now configure it in chip info. 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/20231027015059.10032-3-pkshih@realtek.com
2023-10-19wifi: rtw89: phy: generalize valid bit of BSS colorPing-Ke Shih
The register fields of BSS color map and valid bit are in the same register for existing chips, but coming WiFi 7 chips define another register to set valid bit, so add a field to chip_info to reuse the code. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231016065115.751662-3-pkshih@realtek.com
2023-10-19wifi: rtw89: phy: change naming related BT coexistence functionsChung-Hsuan Hung
Change naming to disambiguate the functions because their names are common and not clear about the purpose. Not change logic at all. These functions are to control baseband AGC while BT coexists with WiFi. Among these functions, ctrl_btg_bt_rx is used to control AGC related settings, which is affected by BT RX, while BT shares the same path with wifi; ctrl_nbtg_bt_tx is used to control AGC settings under non-shared path condition, which is affected by BT TX. Signed-off-by: Chung-Hsuan Hung <hsuan8331@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/20231016065115.751662-2-pkshih@realtek.com
2023-10-03wifi: rtw89: refine bandwidth 160MHz uplink OFDMA performancePo-Hao Huang
This improves 160MHz performance degradation with certain APs. Some ICs transmit preamble that are hard to decode by others, continuous retries then yield low throughput. Fix it with pre-calculated antenna matrices. Signed-off-by: Po-Hao Huang <phhuang@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/20230929004024.7504-3-pkshih@realtek.com