summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek
AgeCommit message (Collapse)Author
2025-04-28wifi: rtw89: mcc: refine filling function of start TSFZong-Zhe Yang
Since tob (time offset behind) could be negative, change the type of tob in microsecond to s32. And, refine accumulation with while-loop by calculation with roundup_u64(). Besides, as long as one of the MCC roles is GO, use the short MCC start time. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250422014620.18421-12-pkshih@realtek.com
2025-04-28wifi: rtw89: mcc: support courtesy mechanism on both roles at the same timeZong-Zhe Yang
MCC has a courtesy mechanism which allows one role to use another's duration in a given cycle. Originally, this courtesy mechanism only supports in one direction. However, in some field cases, both of MCC roles may simultaneously have timing configurations that are not good enough. So, support courtesy mechanism in both directions. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250422014620.18421-11-pkshih@realtek.com
2025-04-28wifi: rtw89: mcc: update entire plan when courtesy config changesZong-Zhe Yang
MCC has a courtesy mechanism which allows one role to use another's duration in a given cycle. Courtesy mechanism will be enabled when one role has a not perfect duration. Otherwise, not. When MCC updates, duration of each role will be re-calculated. And then, the new courtesy config might be different from the old one. However, to change courtesy config, the entire MCC plan requires to be renewed when MCC updates. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250422014620.18421-10-pkshih@realtek.com
2025-04-28wifi: rtw89: mcc: handle the case where NoA start time has passedZong-Zhe Yang
MCC will limit the time a role can use in a schedule according to the periodic NoA. Original logic didn't consider the case where NoA start time has passed. It might lead to inaccurate result. So, tweak 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/20250422014620.18421-9-pkshih@realtek.com
2025-04-28wifi: rtw89: mcc: make GO+STA mode calculate dynamic beacon offsetZong-Zhe Yang
There are two roles during MCC and the offset between their TBTT is called beacon offset. Originally, when MCC runs GO+STA mode, it used fixed beacon offset to simplify some logic because GO role can master its TSF. However, if MCC is stopped and restarted before a same GO is down, its TSF might be discontinuous. Then, there might be undefined behavior happens in GC sides. So, to let a same GO have a continuous TSF, MCC no longer changes its TSF to meet a fixed beacon offset. Instead, GO+STA mode also calculates beacon offset dynamically as what GC+STA mode did. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250422014620.18421-8-pkshih@realtek.com
2025-04-28wifi: rtw89: don't re-randomize TSF of AP/GOZong-Zhe Yang
When APs or GOs are up, their TSF start point are randomized to avoid collisions. However, the TSF of an existing AP/GO would be randomized multiple times. It caused the TSF is discontinuous to the corresponding STA/GC sides. So, once TSF has been randomized, don't re-randomize it unless SER (system error recovery) happens unfortunately. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250422014620.18421-7-pkshih@realtek.com
2025-04-28wifi: rtw89: mcc: make GO announce one-time NoA for HW scan processZong-Zhe Yang
Since FW cannot handle HW scan process and MCC (multi-channel concurrency) mode simultaneously, if a HW scan is requested during MCC, MCC mode will be paused temporarily. Then, the GO role if any might be absent. So, calculate an estimated time for the requested HW scan process and search for existing GO roles to fill one-time NoA. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250422014620.18421-6-pkshih@realtek.com
2025-04-28wifi: rtw89: refactor flow that hw scan handles channel listZong-Zhe Yang
FW has a limited amount of channels that can be dealt with by one HW scan H2C command. Based on the limit, channels in scan request might be parsed into SW structure piece by piece along with multiple HW scan H2C commands. But, in order to estimate things of entire HW scan process, it's required to have the whole parsed channel list when HW scan is going to start. So, tweak HW scan flow to prepare the whole channel list ahead. Still, each HW scan H2C command takes allowed amount of channels from the list according to the limit. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250422014620.18421-5-pkshih@realtek.com
2025-04-28wifi: rtw89: add suffix "_ax" to Wi-Fi 6 HW scan struct and funcZong-Zhe Yang
These stuffs have no suffix, but not universal, and only work for Wi-Fi 6. Since the corresponding HW scan struct/func of Wi-Fi 7 have suffix "_be", to avoid misunderstanding and improve readability, also add suffix "_ax" to these Wi-Fi 6 stuffs. (No logic is changed.) Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250422014620.18421-4-pkshih@realtek.com
2025-04-28wifi: rtw89: acpi: introduce country specific TAS enablingKuan-Chung Chen
A new ACPI table entry format for TAS is defined, which includes a "specific country" field. In this field, determine which country can enable TAS. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250422014620.18421-3-pkshih@realtek.com
2025-04-28wifi: rtw89: 8922a: increase beacon loss to 6 secondsKuan-Chung Chen
Intermittent beacon loss from specific AP triggers disconnection and reconnection. Increasing the beacon loss count will make the connection more stable. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250422014620.18421-2-pkshih@realtek.com
2025-04-26wifi: rtw89: set pre-calculated antenna matrices for HE trigger frameKuan-Chung Chen
Pre-calculated antenna matrices can improve 160MHz uplink OFDMA performance, but they are only needed for the HE trigger frame. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250416081241.36138-5-pkshih@realtek.com
2025-04-26wifi: rtw89: regd: indicate if regd_UK TX power settings follow regd_ETSIZong-Zhe Yang
Before adopting regd_UK TX power settings, some certifications are needed and might be platform-level. Without that, should adopt regd_ETSI TX power settings. But for now, there is no way to inform driver of it yet. So, add a flag first. But for now, comprehensively use regd_ETSI TX power settings to restrict regd_UK. Plan to define an ACPI DSM function to inform driver whether to use regd_UK own TX power settings or not afterwards. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250416081241.36138-4-pkshih@realtek.com
2025-04-26wifi: rtw89: 8922a: fix TX fail with wrong VCO settingKuan-Chung Chen
An incorrect Voltage Controlled Oscillator (VCO) setting may cause Synthesizer (SYN) unlock, which may lead to a failure in the TX authentication request. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250416081241.36138-3-pkshih@realtek.com
2025-04-26wifi: rtw89: 8852c: update supported firmware format to 2Ping-Ke Shih
After firmware 0.27.125.0, it adds more fields to support firmware secure boot. Though current driver has supported the format, old driver can't recognize the new format, increase firmware format to 2 to avoid failed to load the firmware by old driver. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250416081241.36138-2-pkshih@realtek.com
2025-04-17wifi: rtw88: do not ignore hardware read error during DPKDmitry Antipov
In 'rtw8822c_dpk_cal_coef1()', do not ignore error returned by 'check_hw_ready()' but issue a warning to denote possible DPK issue. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 5227c2ee453d ("rtw88: 8822c: add SW DPK support") Suggested-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250415090720.194048-1-dmantipov@yandex.ru
2025-04-17wifi: rtw88: sdio: call rtw_sdio_indicate_tx_status unconditionallyZhen XIN
The rtw88-sdio do not work in AP mode due to the lack of TX status report for management frames. Make the invocation of rtw_sdio_indicate_tx_status unconditional and cover all packet queues Tested-on: rtl8723ds Fixes: 65371a3f14e7 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets") Signed-off-by: Zhen XIN <zhen.xin@nokia-sbell.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250410154217.1849977-2-zhen.xin@nokia-sbell.com
2025-04-17wifi: rtw88: sdio: map mgmt frames to queue TX_DESC_QSEL_MGMTZhen XIN
The rtw88-sdio do not work in AP mode due to the lack of TX status report for management frames. Map the management frames to queue TX_DESC_QSEL_MGMT, which enables the chip to generate TX reports for these frames Tested-on: rtl8723ds Fixes: 65371a3f14e7 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets") Signed-off-by: Zhen XIN <zhen.xin@nokia-sbell.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250410154217.1849977-3-zhen.xin@nokia-sbell.com
2025-04-09wifi: rtw88: Fix the module names printed in dmesgBitterblue Smith
The rtw88 module names all start with the "rtw88_" prefix, but the messages in dmesg mostly use the "rtw_" prefix. The messages from rtw88_8723cs don't even have the underscore. Use the KBUILD_MODNAME macro in every driver. This ensures that the messages in dmesg will always use the module name. Before: Mar 17 15:54:19 ideapad2 kernel: rtw_8814au 2-4:1.0: Firmware version 33.6.0, H2C version 6 After: Mar 17 16:33:35 ideapad2 kernel: rtw88_8814au 2-4:1.0: Firmware version 33.6.0, H2C version 6 Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/29cd29ba-bc51-4d5b-ad48-a43c6ce72d56@gmail.com
2025-04-09wifi: rtw88: Don't set SUPPORTS_AMSDU_IN_AMPDU for RTL8814AUBitterblue Smith
RTL8814AU doesn't work well with SUPPORTS_AMSDU_IN_AMPDU. The RX speed is noticeably lower and the VHT RX statistics are strange. Typical values with SUPPORTS_AMSDU_IN_AMPDU: Reverse mode, remote host 192.168.0.1 is sending [ 5] local 192.168.0.50 port 60710 connected to 192.168.0.1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 74.6 MBytes 626 Mbits/sec [ 5] 1.00-2.00 sec 79.2 MBytes 665 Mbits/sec [ 5] 2.00-3.00 sec 84.9 MBytes 712 Mbits/sec [ 5] 3.00-4.00 sec 83.8 MBytes 703 Mbits/sec [ 5] 4.00-5.00 sec 85.9 MBytes 720 Mbits/sec [ 5] 5.00-6.00 sec 78.9 MBytes 662 Mbits/sec [ 5] 6.00-7.00 sec 81.2 MBytes 682 Mbits/sec [ 5] 7.00-8.00 sec 80.5 MBytes 675 Mbits/sec [ 5] 8.00-9.00 sec 79.4 MBytes 666 Mbits/sec [ 5] 9.00-10.00 sec 82.2 MBytes 689 Mbits/sec [ 5] 10.00-11.00 sec 82.0 MBytes 688 Mbits/sec [ 5] 11.00-12.00 sec 84.2 MBytes 707 Mbits/sec [ 5] 12.00-13.00 sec 71.0 MBytes 596 Mbits/sec [ 5] 13.00-14.00 sec 69.4 MBytes 582 Mbits/sec [ 5] 14.00-15.00 sec 80.2 MBytes 673 Mbits/sec [ 5] 15.00-16.00 sec 74.5 MBytes 625 Mbits/sec [Rx Counter]: * CCA (CCK, OFDM, Total) = (0, 2455, 2455) * False Alarm (CCK, OFDM, Total) = (0, 69, 69) * CCK cnt (ok, err) = (0, 0) * OFDM cnt (ok, err) = (1239, 2) * HT cnt (ok, err) = (0, 0) * VHT cnt (ok, err) = (21, 12109) The "VHT ok" number is not believable. And without SUPPORTS_AMSDU_IN_AMPDU: Reverse mode, remote host 192.168.0.1 is sending [ 5] local 192.168.0.50 port 50030 connected to 192.168.0.1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 70.5 MBytes 591 Mbits/sec [ 5] 1.00-2.00 sec 86.9 MBytes 729 Mbits/sec [ 5] 2.00-3.00 sec 98.6 MBytes 827 Mbits/sec [ 5] 3.00-4.00 sec 97.4 MBytes 817 Mbits/sec [ 5] 4.00-5.00 sec 98.6 MBytes 827 Mbits/sec [ 5] 5.00-6.00 sec 96.9 MBytes 813 Mbits/sec [ 5] 6.00-7.00 sec 98.2 MBytes 824 Mbits/sec [ 5] 7.00-8.00 sec 98.0 MBytes 822 Mbits/sec [ 5] 8.00-9.00 sec 99.9 MBytes 838 Mbits/sec [ 5] 9.00-10.00 sec 99.2 MBytes 833 Mbits/sec [ 5] 10.00-11.00 sec 98.0 MBytes 822 Mbits/sec [ 5] 11.00-12.00 sec 98.1 MBytes 823 Mbits/sec [ 5] 12.00-13.00 sec 97.0 MBytes 814 Mbits/sec [ 5] 13.00-14.00 sec 98.2 MBytes 824 Mbits/sec [ 5] 14.00-15.00 sec 98.5 MBytes 826 Mbits/sec [ 5] 15.00-16.00 sec 97.4 MBytes 817 Mbits/sec [Rx Counter]: * CCA (CCK, OFDM, Total) = (0, 3860, 3860) * False Alarm (CCK, OFDM, Total) = (0, 2, 2) * CCK cnt (ok, err) = (0, 0) * OFDM cnt (ok, err) = (1486, 0) * HT cnt (ok, err) = (0, 0) * VHT cnt (ok, err) = (7399, 9118) Add a new member "amsdu_in_ampdu" in struct rtw_chip_info and use it to set SUPPORTS_AMSDU_IN_AMPDU only for the other chips. 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/6202ccfb-feb0-4107-a08d-db2699e179f0@gmail.com
2025-04-09wifi: rtw88: Set AMPDU factor to hardware for RTL8814ABitterblue Smith
Tell the chip the maximum AMPDU size supported by the AP. This greatly improves the TX speed of RTL8814AU in the 2.4 GHz band. Before: ~90 Mbps. After: ~300 Mbps. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/4edc2a63-81b3-431c-9a37-5a7d899a6cc2@gmail.com
2025-04-09wifi: rtw88: usb: Enable RX aggregation for RTL8814AUBitterblue Smith
Let the chip transfer several frames in a single USB Request Block. This is supposed to improve the RX speed. It can use the same code used for RTL8822CU, RTL8822BU, and RTL8821CU. 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/672397ac-dd4d-4420-8b3e-7011578e2243@gmail.com
2025-04-09wifi: rtw88: usb: Enable switching the RTL8814AU to USB 3Bitterblue Smith
The Realtek wifi 5 devices which support USB 3 are weird: when first plugged in, they pretend to be USB 2. The driver needs to send some commands to the device, which make it disappear and come back as a USB 3 device. The method used to switch the RTL8812AU also works for the RTL8814AU. 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/d3608f70-e04f-4f6b-987a-022c8e317165@gmail.com
2025-04-05treewide: Switch/rename to timer_delete[_sync]()Thomas Gleixner
timer_delete[_sync]() replaces del_timer[_sync](). Convert the whole tree over and remove the historical wrapper inlines. Conversion was done with coccinelle plus manual fixups where necessary. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2025-03-31wifi: rtw88: usb: 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/20250324080303.408084-1-nichen@iscas.ac.cn
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
generated by cgit (git 2.34.1) at 2025-07-15 00:58:24 +0000