summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek
AgeCommit message (Collapse)Author
2025-03-31wifi: rtw88: sdio: Remove redundant 'flush_workqueue()' callsChen Ni
'destroy_workqueue()' already drains the queue before destroying it, so there is no need to flush it explicitly. Remove the redundant 'flush_workqueue()' calls. This was generated with coccinelle: @@ expression E; @@ - flush_workqueue(E); destroy_workqueue(E); Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250324075910.407999-1-nichen@iscas.ac.cn
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: 8852c: support different SAR configs by antennaZong-Zhe Yang
Set SAR configs to the corresponding CRs (control registers) according to RF path. Then, declare to support SAR by antenna in 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-12-pkshih@realtek.com
2025-03-31wifi: rtw89: 8922a: support different SAR configs by antennaZong-Zhe Yang
Set SAR configs to the corresponding CRs (control registers) according to RF path. Then, declare to support SAR by antenna in 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-11-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-31wifi: rtw89: acpi: support loading GEO SAR tablesZong-Zhe Yang
Support to load GEO (geography) SAR tables with ACPI RWGS method. When SAR values could be different by regulatory, GEO SAR can be used. The format of GEO SAR is like the following, where regulatory number, band number, and delta number are determined by header of either static SAR or dynamic SAR. (It also means that no GEO SAR will be considered when neither static SAR nor dynamic SAR is configured.) delta number / \ + +-----+-----------------+ / | | max | delta... | \ / | +-----+-----------------+ band / | | max | delta... | number / | +-----+-----------------+ / | |... | / + +-----+-----------------+ | | max | delta... | \ regulatory | +-----+-----------------+ band number | | max | delta... | number | +-----+-----------------+ | |... | / + +-----+-----------------+ \ | |... | \ | |... | \ | |... | \ | | | \ | | | + +-----+-----------------+ Each entry of GEO SAR contains delta field(s), which are offset(s) used to tweak the loaded static/dynamic SAR table(s) by antenna, and one max field, which describes the maximum of the final SAR values after tweaked. Different entries should be configured based on both regulatory and band. 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-9-pkshih@realtek.com
2025-03-31wifi: rtw89: acpi: support loading dynamic SAR tables and indicatorZong-Zhe Yang
Support to load dynamic SAR tables with ACPI RWRD method. The content format of a single dynamic SAR table is basically the same as static SAR table. However, it's able to carry multiple dynamic SAR tables at one time. And, its header contains one more field to describe how many dynamic SAR tables are filled in the content. Either static SAR table or dynamic SAR tables can be supported, but not both simultaneously. Besides, also support to load indicator of dynamic SAR with ACPI RWSI method. The indicator will describe a target dynamic SAR table, which should be followed currently, by antenna. It can be changed at runtime according to platform mode. For example, tablet mode can use different SAR from normal mode. So, track indicator configuration if dynamic SAR is configured. 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-8-pkshih@realtek.com
2025-03-31wifi: rtw89: acpi: support loading static SAR tableZong-Zhe Yang
Support to load static SAR table with ACPI WRDS method. The format of a static SAR table is like the following, where according to header, antenna number could be either 2 or 4 and subband number could either contain 6 GHz or not. And then, an entry of it describes a TX power limitation with a given unit, which is also based on header, for the antenna under the subband. Though things can be determined by header, still not all combinations are allowed in content. For the recognizing flow, there is a list of allowed combinations. +--------------------------------+ | header | +--------------------------------+ +---+---+---+---+---+------------+ + / | | | | | | ... | | \ +---+---+---+---+---+------------+ | antenna | | | | | | ... | | number +---+---+---+---+---+------------+ | content |...| | | | | ... | | +---+---+---+---+---+------------+ | \ |...| | | | | ... | | / +---+---+---+---+---+------------+ + \ / subband number Following the format above, try to load a static SAR table and normalize its content into SW structure. If any recognized is loaded, SW SAR flow is then set up with source from ACPI. 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-7-pkshih@realtek.com
2025-03-31wifi: rtw89: acpi: introduce method evaluation function for reuseZong-Zhe Yang
The following implementations will evaluate different ACPI methods, but the pre-process flow of them are the same. So, introduce a function for these pre-process things. Besides, also change ACPI RTAG method to call this function. 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-6-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-31wifi: rtw89: regd: introduce string getter for reuseZong-Zhe Yang
Introduce a function to get the string for a given regulatory. It will be used in the following. Besides, drop similar things in debug code and use this too. 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-3-pkshih@realtek.com
2025-03-31wifi: rtw89: fix typo of "access" in rtw89_sar_info descriptionZong-Zhe Yang
The "acces" should be "access". So, fix 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/20250326020643.14487-2-pkshih@realtek.com
2025-03-31wifi: rtw89: phy: reset value of force TX power for MAC IDPing-Ke Shih
The force TX power function is disabled, but the force TX power value is preserved, causing misunderstand the behavior in debug. Clear all values. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250325031021.15619-1-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: rtw88: Add __nonstring annotations for unterminated stringsKees Cook
When a character array without a terminating NUL character has a static initializer, GCC 15's -Wunterminated-string-initialization will only warn if the array lacks the "nonstring" attribute[1]. Mark the arrays with __nonstring to and correctly identify the char array as "not a C string" and thereby eliminate the warning. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 [1] Cc: Ping-Ke Shih <pkshih@realtek.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: linux-wireless@vger.kernel.org Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250310222257.work.866-kees@kernel.org
2025-03-13wifi: rtw88: Enable the new RTL8814AE/RTL8814AU driversBitterblue Smith
RTL8814A is a wifi 5 chip with 4 RF paths (chains), 3 spatial streams, and probably no Bluetooth. The USB-based RTL8814AU can reach 800 Mbps in the 5 GHz band in USB 3 mode. In USB 2 mode it only uses 2 spatial streams. The PCI-based RTL8814AE is not as popular and didn't get as much testing so it's unclear how fast it goes. It's more like a bonus on top of the RTL8814AU support. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/5795b0a7-511e-40b5-ac36-476b63f174c7@gmail.com
2025-03-13wifi: rtw88: Add rtw8814au.cBitterblue Smith
This is the entry point for the new module rtw88_8814au. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/71457787-5a9e-4ead-a62c-22ca44e00b89@gmail.com
2025-03-13wifi: rtw88: Add rtw8814ae.cBitterblue Smith
This is the entry point for the new module rtw88_8814ae. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/74ebab2f-a23e-4d87-935f-0af2b5cba672@gmail.com
2025-03-13wifi: rtw88: Add rtw8814a.{c,h}Bitterblue Smith
These contain all the logic for the RTL8814A chip. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/5d3b8c03-63c1-4f20-860a-89d424badad8@gmail.com
2025-03-13wifi: rtw88: Add rtw8814a_table.c (part 2/2)Bitterblue Smith
This contains various tables for initialising the RTL8814A, plus TX power limits. Also add rtw8814a_table.h. Split into two patches because they are big. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/4c48e35e-1b04-42ed-940e-0e931693def6@gmail.com
2025-03-13wifi: rtw88: Add rtw8814a_table.c (part 1/2)Bitterblue Smith
This contains various tables for initialising the RTL8814A, plus TX power limits. Split into two patches because they are big. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/df0b8ceb-2c2f-4bda-906f-a05c7b4d424c@gmail.com
2025-03-13wifi: rtw88: Add some definitions for RTL8814AUBitterblue Smith
Add various register definitions which will be used by the new driver. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/1dcb5abb-26f8-4db5-be36-057de56465e5@gmail.com
2025-03-13wifi: rtw89: coex: Update Wi-Fi/Bluetooth coexistence version to 7.0.4Ching-Te Ku
RTL8852BE-VT support for firmware 29.122. Add parser for Bluetooth channel map report version 7. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250308025832.10400-5-pkshih@realtek.com
2025-03-13wifi: rtw89: coex: Add parser for Bluetooth channel map report version 7Ching-Te Ku
In order to rearrange the structure member, the format update to version 7. And to parse the report correctly, add the related logic. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250308025832.10400-4-pkshih@realtek.com
2025-03-13wifi: rtw89: coex: Fix coexistence report not show as expectedChing-Te Ku
This report will feedback some basic information from firmware(PTA counter, report counter, mailbox counter etc). And the report version need to match driver & firmware both side. The original logic break the switch case logic before driver update the report version. It made the report can not be parsed correctly. Delete the break at the version 7 and 8. Add logic to count C2H event report. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250308025832.10400-3-pkshih@realtek.com
2025-03-13wifi: rtw89: coex: RTL8852BT coexistence Wi-Fi firmware support for 0.29.122.0Ching-Te Ku
Add format version of Wi-Fi firmware commands/events for firmware version 0.29.122.0. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250308025832.10400-2-pkshih@realtek.com
2025-03-13wifi: rtw89: set force HE TB mode when connecting to 11ax APDian-Syuan Yang
Some of 11ax AP set the UL HE-SIG-A2 reserved subfield to all 0s, which will cause the 11be chip to recognize trigger frame as EHT. We propose a method to bypass the "UL HE-SIG-A2 reserved subfield" and always uses HE TB in response to the AP's trigger frame. Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250306021144.12854-6-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-03-13wifi: rtw89: add support for negative values of dBm to linear conversionKuan-Chung Chen
Enhanced the dBm to linear conversion function to accommodate negative dBm values and improved the precision from 1 dBm to 0.25 dBm. 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-2-pkshih@realtek.com
2025-03-05wifi: rtw89: pci: correct ISR RDU bit for 8922AEPing-Ke Shih
The interrupt status (ISR) bits of RX desc unavailable (RDU) for 8922AE are B_BE_RDU_CH1_INT_V1 and B_BE_RDU_CH0_INT_V1. With wrong bits, if it happens, driver can't recognize the situation and prompt a message. Fix the definition accordingly. Fixes: aa70f76120ee ("wifi: rtw89: pci: generalize interrupt status bits of interrupt handlers") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250227131907.9864-1-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-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: rtw88: Extend rtw_debugfs_get_tx_pwr_tbl() for RTL8814AUBitterblue Smith
Make it print the TX power details for all RF paths, not just A and B, and for all the rates supported by the chip, not just 1SS and 2SS rates. Also skip the RF paths and rates not supported by the chip. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/ea65a978-a735-4c97-af82-d7fe26f95da1@gmail.com
2025-02-21wifi: rtw88: Extend rtw_debugfs_get_phy_info() for RTL8814AUBitterblue Smith
Print information about the 3rd and 4th RF paths and about the 3rd spatial stream. Also, fix a small bug: don't show the average SNR and EVM for the OFDM and HT/VHT rates when the rate is actually CCK 11M. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/7c8e94e2-e034-40f3-bdaf-b000018b5573@gmail.com
2025-02-21wifi: rtw88: Extend rtw_phy_config_swing_table() for RTL8814AUBitterblue Smith
Select the TX power tracking tables for RF paths C and D as well. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/e1e532c9-8733-4ec8-84fe-ced4af6c08da@gmail.com
2025-02-21wifi: rtw88: Fix rtw_rx_phy_stat() for RTL8814AUBitterblue Smith
Record statistics for the 3SS rates too. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/39e3c7cf-37ed-4c0e-af00-dcd9eab351f0@gmail.com
2025-02-21wifi: rtw88: Fix rtw_init_vht_cap() for RTL8814AUBitterblue Smith
Set the MCS maps and the highest rates according to the number of spatial streams the chip has. For RTL8814AU that is 3. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/e86aa009-b5bf-4b3a-8112-ea5e3cd49465@gmail.com
2025-02-21wifi: rtw88: Fix rtw_init_ht_cap() for RTL8814AUBitterblue Smith
Set the RX mask and the highest RX rate according to the number of spatial streams the chip can receive. For RTL8814AU that is 3. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/4e786f50-ed1c-4387-8b28-e6ff00e35e81@gmail.com
2025-02-21wifi: rtw88: Fix rtw_desc_to_mcsrate() to handle MCS16-31Bitterblue Smith
This function translates the rate number reported by the hardware into something mac80211 can understand. It was ignoring the 3SS and 4SS HT rates. Translate them too. Also set *nss to 0 for the HT rates, just to make sure it's initialised. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/d0a5a86b-4869-47f6-a5a7-01c0f987cc7f@gmail.com
2025-02-21wifi: rtw88: Fix rtw_mac_power_switch() for RTL8814AUBitterblue Smith
rtw_mac_power_switch() checks bit 8 of REG_SYS_STATUS1 to see if the chip is powered on. This bit appears to be always on in the RTL8814AU, so ignore it. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/2f0fcffb-3067-4d95-a68c-f2f3a5a47921@gmail.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
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-04 22:43:40 +0000