summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek/rtw89/phy.c
AgeCommit message (Collapse)Author
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: phy: add C2H event handler for report of FW scanKuan-Chung Chen
Newer firmware will notify driver of the Packet Detection (PD) value on the channel after switch channels during FW scan. 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-2-pkshih@realtek.com
2025-03-31wifi: rtw89: sar: add skeleton for SAR configuration via ACPIZong-Zhe Yang
To support SAR configuration in BIOS via ACPI, add related subbnad/band converting/handling function and define SW format to store result after parsing. Then, register a new SAR source, i.e. ACPI, into SAR flow and implement its query function. Besides, tweak priority of common SAR to be the highest. And, ACPI SAR can just be configured once when no other sources is already working. For now, evaluating SAR via ACPI returns -ENOENT, i.e. ACPI SAR doesn't really work yet. The evaluating flow will be implemented 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/20250326020643.14487-5-pkshih@realtek.com
2025-03-31wifi: rtw89: sar: introduce structure to wrap query parametersZong-Zhe Yang
The following implementations will support SAR source from ACPI/BIOS. And when querying, it needs to take more parameters into account. To avoid changing function prototype of querying SAR everytime when new SAR source is introduced, wrap query parameters into a structure first. 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-4-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-13wifi: rtw89: enable dynamic antenna gain based on countryKuan-Chung Chen
The dynamic antenna gain (DAG) considers the country, meaning DAG can be activated only when countries and regulatory domains allow it. 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-4-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-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: 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: 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-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
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
2024-12-12wifi: rtw89: disable firmware training HE GI and LTFKuan-Chung Chen
Given the performance trade-off associated with firmware training HE GI/LTF, especially in high attenuation environments, we have decided to utilize a constant value instead. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241206055716.18598-5-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-05wifi: rtw89: add crystal_cap check to avoid setting as overflow valueChih-Kang Chang
In the original flow, the crystal_cap might be calculated as a negative value and set as an overflow value. Therefore, we added a check to limit the calculated crystal_cap value. Additionally, we shrank the crystal_cap adjustment according to specific CFO. 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-7-pkshih@realtek.com
2024-12-05wifi: rtw89: refine link handling for link_sta_rc_updateZong-Zhe Yang
The original handling will iterate all active links under the given sta and apply the changes to each. Now, stack tweaks ops from sta_rc_update to link_sta_rc_update, which means targeting a given link. Then, our link iteration looks redundant. So, refine it to apply the changes to the link directly. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241128055433.11851-6-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-05wifi: rtw89: debug: add beacon RSSI for debuggingPing-Ke Shih
In range test, the RSSI is helpful to check attenuation of cable and align difference between environments. Since data packets can be transmitted with different rate and power, the RSSI of all packets can be variant. Oppositely beacon is transmitted with the same rate and power, so beacon RSSI will be relatively invariant, and more helpful to diagnose problems. The output of beacon RSSI in unit of dBm looks like: Beacon: 19 (-33 dBm), TF: 0 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240927013512.7106-1-pkshih@realtek.com
2024-10-01wifi: rtw89: initialize dual HW bands for MLO and control them by linkZong-Zhe Yang
To support MLO, we initialize things on dual HW bands of Wi-Fi 7 chip. And, each link will indicate which HW band it's bound to. So, in link control flow, we control major things based on target link's HW band instead of hardcode like RTW89_PHY_X or RTW89_MAC_X. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240925020119.13170-2-pkshih@realtek.com
2024-09-24wifi: rtw89: tweak driver architecture for impending MLO supportZong-Zhe Yang
The drv_priv hooked to mac80211 become as below. (drv_priv) (instance-0) +---------------+ +-----------+ +----------------+ | ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link | +---------------+ +-----------+ | +----------------+ | | (instance-1) | +----------------+ +---> | rtw89_vif_link | +----------------+ (drv_priv) (instance-0) +---------------+ +-----------+ +----------------+ | ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link | +---------------+ +-----------+ | +----------------+ | | (instance-1) | +----------------+ +---> | rtw89_sta_link | +----------------+ The relation bewteen mac80211 link_id and our link instance is like below. |\ (link_id) | \ 0 -------- | | 1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0 2 -------- | | ... | | ------ instance-1 (link_id: Y) -> work on HW band 1 14 -------- | | | / |/ N.B. For cases of non-MLD connection, we set our link instance-0 active with link_id 0. So, our code flow can be compatible between non-MLD connection and MLD connection. Based on above, we tweak entire driver architecture first. But, we don't dynamically enable multiple links here. That will be handled separately. Most of the things changed here are changing flows to iterate all active links and read bss_conf/link_sta data according to target link. And, for cases of scan, ROC, WOW, we use instance-0 to deal with the request. There are some things listed below, which work for now but need to extend before multiple active links. 1. tx path select suitable link instance among multiple active links 2. rx path determine rx link by PPDU instead of always link instance-0 3. CAM apply MLD pairwise key to any active links dynamically Besides, PS code cannot easily work along with tweaking architecture. With supporting MLO flag (currently false), we disable PS first and will fix it by another commit 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/20240916053158.47350-8-pkshih@realtek.com
2024-09-24wifi: rtw89: refactor STA related func ahead for MLOZong-Zhe Yang
Refactor STA related functions, e.g. add/assoc/disassoc/disconnect/remove to separate most link stuffs into sub-functions for MLO reuse. 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-7-pkshih@realtek.com
2024-09-24wifi: rtw89: refactor VIF related func ahead for MLOZong-Zhe Yang
Refactor VIF related functions, e.g. add/remove/assoc/mapping to separate most link stuffs into sub-functions for MLO reuse. 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-6-pkshih@realtek.com
2024-09-24wifi: rtw89: read link_sta corresponding to the linkZong-Zhe Yang
Tweak code to not always access sta->deflink directly. Instead, according to link_id, read target link_sta from sta->link[]. For now, rtwsta_link->link_id keeps 0. When driver starts to support MLO, the link_id will be assigned. 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-5-pkshih@realtek.com
2024-09-24wifi: rtw89: read bss_conf corresponding to the linkZong-Zhe Yang
Tweak code to not always access vif->bss_conf directly. Instead, according to link_id, read target bss_conf from vif->link_conf[]. For now, rtwvif_link->link_id keeps 0. When driver starts to support MLO, the link_id will be assigned. 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-4-pkshih@realtek.com
2024-09-24wifi: rtw89: rename rtw89_sta to rtw89_sta_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_sta_link *sta_to_rtwsta_safe(struct ieee80211_sta *sta) 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-3-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-20wifi: rtw89: rfk: update firmware debug log of DACK to v2Ping-Ke Shih
Update DACK (digital-to-analog converters calibration) log to v2 by firmware C2H events. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240913071340.41822-6-pkshih@realtek.com
2024-09-20wifi: rtw89: rfk: add firmware debug log of IQKPing-Ke Shih
Print out IQ signal calibration log from firmware C2H events. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240913071340.41822-5-pkshih@realtek.com
2024-09-20wifi: rtw89: rfk: add firmware debug log of TSSIPing-Ke Shih
TSSI is short for transmitter signal strength indication. Print out the TSSI log from firmware C2H events. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240913071340.41822-4-pkshih@realtek.com
2024-09-20wifi: rtw89: 8922a: rfk: support firmware command RX DCK v1 formatPing-Ke Shih
RX DCK stands for receiver DC calibration. The v1 format adds a field to indicate the calibration is for operation channel or an average value for all scanning channels. Update the format accordingly, and increase firmware format sequence to 2. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240913071340.41822-3-pkshih@realtek.com
2024-09-05wifi: rtw89: adjust DIG threshold to reduce false alarmEric Huang
Use RSSI without subtracting offset as packet detection lower bound and set an absolute minimal threshold. It's equivalent to setting a higher noise floor, thereby reducing false alarm and improving interference endurance. Signed-off-by: Eric Huang <echuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240828055217.10263-2-pkshih@realtek.com
2024-08-27wifi: rtw89: 8922a: 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 RTL8922A 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-7-pkshih@realtek.com
2024-08-16wifi: rtw89: correct base HT rate mask for firmwarePing-Ke Shih
Coverity reported that u8 rx_mask << 24 will become signed 32 bits, which casting to unsigned 64 bits will do sign extension. For example, putting 0x80000000 (signed 32 bits) to a u64 variable will become 0xFFFFFFFF_80000000. The real case we meet is: rx_mask[0...3] = ff ff 00 00 ra_mask = 0xffffffff_ff0ff000 After this fix: rx_mask[0...3] = ff ff 00 00 ra_mask = 0x00000000_ff0ff000 Fortunately driver does bitwise-AND with incorrect ra_mask and supported rates (1ss and 2ss rate only) afterward, so the final rate mask of original code is still correct. Addresses-Coverity-ID: 1504762 ("Unintended sign extension") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240809072012.84152-5-pkshih@realtek.com
2024-08-07wifi: rtw89: correct VHT TX rate on 20MHz connectionDian-Syuan Yang
It may get wrong bitrate when connecting to AP set VHT 20MHz, and thus we fix it to follow Wi-Fi spec. Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240731070506.46100-6-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: fix typo of rtw89_phy_ra_updata_XXXZong-Zhe Yang
`updata` should be `update` Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240724052626.12774-5-pkshih@realtek.com
2024-07-05wifi: rtw89: unify the selection logic of RFK table when MCCZong-Zhe Yang
Driver will notify FW the target index of RFK table to use at some moments. When MCC (multi-channel concurrent), the correctness of the notification is especially important. We now unify the selection logic of RFK table as below among chips. 1. check each table if it matches target channel 2. check all tables if any is idle by iterating active channels 3. replace the first table if all are busy unexpectedly Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240702124452.18747-2-pkshih@realtek.com
2024-07-02wifi: rtw89: constrain TX power according to Transmit Power EnvelopeZong-Zhe Yang
Calculate a TX power constraint based on content of ieee80211 Transmit Power Envelope (TPE). Since HW control registers aren't designed as many as all kinds of TPE fields, we strictly intersect all TPE inputs in driver. Then, according to result, constrain TX power via TX power limit/limit_RU. Besides, extend dbgfs txpwr_table to show info about 6 GHz regulatory. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240626023237.7901-1-pkshih@realtek.com
2024-06-17wifi: rtw89: 885xbx: apply common settings to 8851B, 8852B and 8852BTPing-Ke Shih
Many common settings can share to 8851B, 8852B and 8852BT, so add an inline function rtw89_is_rtl885xb() to be concise. Meanwhile review and align settings for existing chips. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240607070659.80263-4-pkshih@realtek.com
2024-04-29wifi: rtw89: Remove the redundant else branch in the function ↵Jiapeng Chong
rtw89_phy_get_kpath The assignment of the else and if branches is the same in the "case: MLO_2_PLUS_0_1RF" branch of the function rtw89_phy_get_kpath, so we remove it and add comments here to make the code easier to understand. ./drivers/net/wireless/realtek/rtw89/phy.c:6406:2-4: WARNING: possible condition with no effect (if == else). Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=8812 Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240422072922.50940-1-jiapeng.chong@linux.alibaba.com
2024-03-12wifi: rtw89: Correct EHT TX rate on 20MHz connectionDian-Syuan Yang
We used EHT capability of 20MHz-only as rate mask to RA (rate adaptive) H2C command when connecting with AP set EHT 20MHz. It would get the wrong rate mask and the MCS rate can only reach MCS11. According to the description of 802.11be spec, if all supported channel bandwidth field of HE PHY capabilities are zero, then the EHT capability of 20MHz-only is valid. As a result, we adjust the code to set correct rate mask based on HE PHY bandwidth capability. Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240305004502.6655-1-pkshih@realtek.com
generated by cgit (git 2.34.1) at 2025-07-25 19:21:47 +0000