summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-05-10wifi: rtw89: send nullfunc based on the given linkPo-Hao Huang
The nullfunc sender function is link specific. Use core_tx_write_link with sw_mld flag to TX the nullfunc via the given link. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250505072440.45113-4-pkshih@realtek.com
2025-05-10wifi: rtw89: allow driver to do specific band TX for MLOPo-Hao Huang
For data packets that can be sent on any band, fill in main mac_id and let HW decide. For packets that we wish to transmit on specific band, fill in sw_mld field so HW would only send it on that band. Main mac_id is the corresponding mac_id on band 0. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250505072440.45113-3-pkshih@realtek.com
2025-05-10wifi: rtw89: extract link part from core tx write functionZong-Zhe Yang
Extract core_tx_write_link from core_tx_write to accept given links as parameters. To make the follow-up changes of TX description more clear, tweak SW functions to split things ahead. (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> Link: https://patch.msgid.link/20250505072440.45113-2-pkshih@realtek.com
2025-05-10wifi: rtw88: rtw8822bu VID/PID for BUFFALO WI-U2-866DMYuuki NAGAO
Add VID/PID 0411/03d1 for recently released BUFFALO WI-U2-866DM USB WiFi adapter. Signed-off-by: Yuuki NAGAO <wf.yn386@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250503003227.6673-1-wf.yn386@gmail.com
2025-05-10wifi: rtw88: Handle RTL8723D(S) with blank efuseBitterblue Smith
Some users have RTL8723DS chips with nearly blank efuse. Currently these chips cannot connect when using rtw88, but they do work using the old out-of-tree driver. Use reasonable default values for TX power, antenna configuration, and crystal cap if the chip's efuse is missing these things. RTL8723D can use the same default values as RTL8703B, so simply move the code from rtl8703b_read_efuse() to the shared function __rtl8723x_read_efuse(). Link: https://github.com/lwfinger/rtw88/issues/157 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/5734afe7-0870-40b2-acd4-5657a02d7c56@gmail.com
2025-05-10wifi: rtw88: Fix RX aggregation settings for RTL8723DSBitterblue Smith
Use the same RX aggregation size and timeout used by the out-of-tree RTL8723DS driver. Also set mystery bit 31 of REG_RXDMA_AGG_PG_TH. This improves the RX speed from ~44 Mbps to ~67 Mbps. 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/4c79fdc1-54bc-4986-9931-bb3ceb418b97@gmail.com
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-05-05wifi: rtw89: Fix inadverent sharing of struct ieee80211_supported_band dataOndrej Jirman
Internally wiphy writes to individual channels in this structure, so we must not share one static definition of channel list between multiple device instances, because that causes hard to debug breakage. For example, with two rtw89 driven devices in the system, channel information may get incoherent, preventing channel use. Signed-off-by: Ondrej Jirman <megi@xff.cz> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250429122916.1734879-3-megi@xff.cz
2025-05-05wifi: rtw89: Convert rtw89_core_set_supported_band to use devm_*Ondrej Jirman
The code can be simplified by using device managed memory allocations. Simplify it. Signed-off-by: Ondrej Jirman <megi@xff.cz> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250429122916.1734879-2-megi@xff.cz
2025-05-05wifi: rtw89: introduce helper to get designated link for MLOZong-Zhe Yang
A link bound to HW band 0 was previously always assumed to exist, because it's true on non-MLD connection, and MLO connection is not supported yet. Now, start to consider MLO cases and prepare to enable MLO support in the following. Add skeleton of designated link. For single-link cases, helper returns the one. For multi-link cases, priorities can be scheduled. Then, drop assumption of link bound to HW band 0. One exception is that MCC doesn't work with MLD yet, so it still expects link on HW band 0 somewhere. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-11-pkshih@realtek.com
2025-05-05wifi: rtw89: roc: dynamically handle link id and link instance indexZong-Zhe Yang
Originally, a macro, RTW89_ROC_BY_LINK_INDEX, is used to decide the link which deals with the ROC process. Before enabling MLO support, it's fine to hard-code RTW89_ROC_BY_LINK_INDEX as 0 since the link instance-0 (on HW-0) is always active. But, for the impending enablement of MLO support, tweak the leaf functions to dynamically handle ROC link instance index. Besides, in the follow-up, ROC caller will get a designated link and will then drop RTW89_ROC_BY_LINK_INDEX. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-10-pkshih@realtek.com
2025-05-05wifi: rtw89: Fill in correct Rx link ID for MLOPo-Hao Huang
For MLO connections, RX link ID is required to do address conversion. Fill it in by the hardware info. 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-9-pkshih@realtek.com
2025-05-05wifi: rtw89: add MLD capabilities declarationPo-Hao Huang
Add MLD capabilities so association requests can carry multi-link element with correct content. 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-8-pkshih@realtek.com
2025-05-05wifi: rtw89: extend join_info H2C command for MLO fieldsPo-Hao Huang
The join_info H2C command is used to indicate a station is connected and tell FW to create/maintain an instance for it. Extend to fill MLO fields. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-7-pkshih@realtek.com
2025-05-05wifi: rtw89: Configure scan band when mlo_dbcc_mode changesPo-Hao Huang
Previously only the first band is used for scanning. With MLO, update scan parameters accordingly by so we can choose to scan from either band. C2H event return value reflects current scanning band, mask it out so we don't treat correct return value as fail. 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-6-pkshih@realtek.com
2025-05-05wifi: rtw89: extend mapping from Qsel to DMA ch for MLOZong-Zhe Yang
After impending MLO support, TX Qsel would come from other HW band rather than HW-0. For example, when working on HW-1, TX release report may fill QSEL_XX_1 and cause warning "Cannot map qsel to dma: ...". So, extend the mapping to recognize multiple HW bands. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-5-pkshih@realtek.com
2025-05-05wifi: rtw89: Adjust management queue mapping for [MLO, HW-1]Po-Hao Huang
Adjust mapping of management packets accordingly to send it on the second hardware band. Previously only single band is used and we plan to enable MLO, so the second band will be needed. Data packets will be steered by hardware so no related changes are required. 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-4-pkshih@realtek.com
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-05-05wifi: rtw89: 8922a: rfk: adjust timeout time of RX DCKPing-Ke Shih
The RX DCK in firmware could retry 3 times if calibration value is not stable. Roughly each calibration can be done within 16 ms, so expect 16 * 4 (with additional 16 ms) will be enough. More, in coming MLO, it will do calibration on two path, so multiply 2. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-2-pkshih@realtek.com
2025-05-05wifi: rtw89: fw: Remove "const" on allocation typeKees Cook
In preparation for making the kmalloc family of allocators type aware, we need to make sure that the returned type from the allocation matches the type of the variable being assigned. (Before, the allocator would always return "void *", which can be implicitly cast to any pointer type.) The assigned type is "struct rtw89_reg2_def *" but the returned type, while technically matching, will be const qualified. As there isn't a general way to discard "const" qualifiers, adjust the returned type to match the assigned type. No change in allocation size results. Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250426060935.work.049-kees@kernel.org
2025-05-05wifi: rtlwifi: Remove unused rtl_bb_delay()Dr. David Alan Gilbert
The last use of rtl_bb_delay() was removed in 2014's commit 5c99f04fec93 ("rtlwifi: rtl8723be: Update driver to match Realtek release of 06/28/14") Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250425235340.288340-4-linux@treblig.org
2025-05-05wifi: rtlwifi: Remove uncalled stub rtl*_phy_ap_calibrateDr. David Alan Gilbert
rtl92d_phy_ap_calibrate(), rtl92du_phy_ap_calibrate(), rtl92ee_phy_ap_calibrate(), and rtl8821ae_phy_ap_calibrate() are all empty function stubs that are never called anywhere. Remove them. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250425235340.288340-3-linux@treblig.org
2025-05-05wifi: rtlwifi: Remove unused rtl_usb_{resume|suspend}Dr. David Alan Gilbert
rtl_usb_resume() and rtl_usb_suspend() are trivial stubs that were added in 2011's commit 2ca20f79e0d8 ("rtlwifi: Add usb driver") but aren't wired up anywhere (though commit 442888c706e9 ("rtlwifi: rtl8192cu: Add routines dm, fw, led and sw") added commented out assignments). Remove them. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250425235340.288340-2-linux@treblig.org
2025-04-28wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723Mingcong Bai
RTL8723BE found on some ASUSTek laptops, such as F441U and X555UQ with subsystem ID 11ad:1723 are known to output large amounts of PCIe AER errors during and after boot up, causing heavy lags and at times lock-ups: pcieport 0000:00:1c.5: AER: Correctable error message received from 0000:00:1c.5 pcieport 0000:00:1c.5: PCIe Bus Error: severity=Correctable, type=Physical Layer, (Receiver ID) pcieport 0000:00:1c.5: device [8086:9d15] error status/mask=00000001/00002000 pcieport 0000:00:1c.5: [ 0] RxErr Disable ASPM on this combo as a quirk. This patch is a revision of a previous patch (linked below) which attempted to disable ASPM for RTL8723BE on all Intel Skylake and Kaby Lake PCIe bridges. I take a more conservative approach as all known reports point to ASUSTek laptops of these two generations with this particular wireless card. Please note, however, before the rtl8723be finishes probing, the AER errors remained. After the module finishes probing, all AER errors would indeed be eliminated, along with heavy lags, poor network throughput, and/or occasional lock-ups. Cc: <stable@vger.kernel.org> Fixes: a619d1abe20c ("rtlwifi: rtl8723be: Add new driver") Reported-by: Liangliang Zou <rawdiamondmc@outlook.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218127 Link: https://lore.kernel.org/lkml/05390e0b-27fd-4190-971e-e70a498c8221@lwfinger.net/T/ Tested-by: Liangliang Zou <rawdiamondmc@outlook.com> Signed-off-by: Mingcong Bai <jeffbai@aosc.io> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250422061755.356535-1-jeffbai@aosc.io
2025-04-28wifi: rtw89: mcc: avoid that loose pattern sets negative timing for auxiliary GOZong-Zhe Yang
A MCC (multi-channel concurrency) schedule is like the following. |< mcc interval >| |< duration ref >|< duration aux >| |< tob ref >|< toa ref >|< tob aux >|< toa aux >| V V tbtt ref tbtt aux |< beacon offset >| Original logic might unexpectedly calculate toa (time offset ahead) of auxiliary role to be negative even when there is no role timing limit. If toa-aux is negative, TBTT-aux would in logic fall into duration-ref. Then, if auxiliary role is GO unfortunately, it cannot guarantee that beacons will TX well. So now, when deciding the lower bound of toa-ref, take toa-aux into account. Make toa-aux at least be zero in normal cases. 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-13-pkshih@realtek.com
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-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
generated by cgit (git 2.34.1) at 2025-07-16 18:04:38 +0000