summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek
AgeCommit message (Collapse)Author
2024-02-12wifi: rtw89: load BB parameters to PHY-1Ping-Ke Shih
We are going to support MLO/DBCC, so need to load parameter table to PHY-1 as well. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-3-pkshih@realtek.com
2024-02-12wifi: rtw89: correct PHY register offset for PHY-1Ping-Ke Shih
PHY-1 can be seen as a copy of PHY-0, and the difference is their base register address, so add a function to get offset to access PHY-1. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-2-pkshih@realtek.com
2024-02-12wifi: rtw89: chan: MCC take reconfig into accountZong-Zhe Yang
During mac80211 reconfig, chanctx ops of multiple channels might not be called in order as normal cases. However, we expect the first active chanctx always to be put at our sub entity index 0. So, if it does not, we do a swap there. Besides, reconfig won't allocate a new chanctx object. So, we should reset the reference count when ops add chanctx. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240206030624.23382-7-pkshih@realtek.com
2024-02-12wifi: rtw89: chan: move handling from add/remove to assign/unassign for MLOZong-Zhe Yang
After MLO, we will need to consider not only active chanctx but also active interfaces (roles) to decide entity things. So in advance, we move handling from chanctx_ops::add/remove to chanctx_ops::assign_vif/unassign_vif. Then, we can recalculate and aware active interfaces' changes. For now, behavior should not be really different, since active chanctx and active interface are one-to-one mapping before MLO. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240206030624.23382-6-pkshih@realtek.com
2024-02-12wifi: rtw89: chan: tweak weight recalc ahead before MLOZong-Zhe Yang
Originally, we consider weight only based on how many chanctxs that mac80211 sets. However, we need to consider both active chanctxs and active interfaces to distinguish MCC (multiple channel concurrent) from impending MLO. Although the logic of handling is extended, for now, behavior might not be different under current condition. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240206030624.23382-5-pkshih@realtek.com
2024-02-12wifi: rtw89: chan: tweak bitmap recalc ahead before MLOZong-Zhe Yang
Originally, we just declared two sub-entity, and according to rolling down mechanism, we ensured that index 0 contained sub-entity as long as there are sub-entity. So, we could use for-loop after deciding the last index. But, we are preparing to expand num of sub-entity for MLO. Then, there won't be just two sub-entity. And, there might be holes between two bits in the bitmap. So, we cannot simply do for-loop as before. Instead, we need to follow the set bits. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240206030624.23382-4-pkshih@realtek.com
2024-02-12wifi: rtw89: chan: add sub-entity swap function to cover replacingZong-Zhe Yang
Originally, we replaced sub-entity of index 0 with another one in some cases. However, we will need a swap here in following implementations. So, we introduce it ahead and change code from replacing to swapping. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240206030624.23382-3-pkshih@realtek.com
2024-02-12wifi: rtw89: drop TIMING_BEACON_ONLY and sync beacon TSF by selfZong-Zhe Yang
Some of our calculation during concurrent mode depend on last beacon TSF. Originally, we just set IEEE80211_HW_TIMING_BEACON_ONLY and get what we want from mac80211. But, IEEE80211_HW_TIMING_BEACON_ONLY will be restricted once we declare MLO. Since we are about to consider the MLO stuffs, so sync beacon TSF by ourselves now and unset IEEE80211_HW_TIMING_BEACON_ONLY. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240206030624.23382-2-pkshih@realtek.com
2024-02-08wifi: mac80211: add support to call csa_finish on a linkAditya Kumar Singh
Currently ieee80211_csa_finish() function finalizes CSA by scheduling a finalizing worker using the deflink. With MLO, there is a need to do it on a given link basis. Pass link ID of the link on which CSA needs to be finalized. Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240130140918.1172387-6-quic_adisi@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: cfg80211/mac80211: move puncturing into chandefJohannes Berg
Aloka originally suggested that puncturing should be part of the chandef, so that it's treated correctly. At the time, I disagreed and it ended up not part of the chandef, but I've now realized that this was wrong. Even for clients, the RX, and perhaps more importantly, CCA configuration needs to take puncturing into account. Move puncturing into the chandef, and adjust all the code accordingly. Also add a few tests for puncturing in chandef compatibility checking. Link: https://lore.kernel.org/linux-wireless/20220214223051.3610-1-quic_alokad@quicinc.com/ Suggested-by: Aloka Dixit <quic_alokad@quicinc.com> Link: https://msgid.link/20240129194108.307183a5d2e5.I4d7fe2f126b2366c1312010e2900dfb2abffa0f6@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: introduce 'channel request'Johannes Berg
For channel contexts, mac80211 currently uses the cfg80211 chandef struct (control channel, center freq(s), width) to define towards drivers and internally how these behave. In fact, there are _two_ such structs used, where the min_def can reduce bandwidth according to the stations connected. Unfortunately, with EHT this is longer be sufficient, at least not for all hardware. EHT requires that non-AP STAs that are connected to an AP with a lower bandwidth than it (the AP) advertises (e.g. 160 MHz STA connected to 320 MHz AP) still be able to receive downlink OFDMA and respond to trigger frames for uplink OFDMA that specify the position and bandwidth for the non-AP STA relative to the channel the AP is using. Therefore, they need to be aware of this, and at least for some hardware (e.g. Intel) this awareness is in the hardware. As a result, use of the "same" channel may need to be split over two channel contexts where they differ by the AP being used. As a first step, introduce a concept of a channel request ('chanreq') for each interface, to control the context it requests. This step does nothing but reorganise the code, so that later the AP's chandef can be added to the request in order to handle the EHT case described above. Link: https://msgid.link/20240129194108.2e88e48bd2e9.I4256183debe975c5ed71621611206fdbb69ba330@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-08wifi: mac80211: simplify non-chanctx driversJohannes Berg
There are still surprisingly many non-chanctx drivers, but in mac80211 that code is a bit awkward. Simplify this by having those drivers assign 'emulated' ops, so that the mac80211 code can be more unified between non-chanctx/chanctx drivers. This cuts the number of places caring about it by about 15, which are scattered across - now they're fewer and no longer in the channel context handling. Link: https://msgid.link/20240129194108.6d0ead50f5cf.I60d093b2fc81ca1853925a4d0ac3a2337d5baa5b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-06wifi: rtl8xxxu: update rate mask per staMartin Kaistra
Until now, rtl8xxxu_watchdog_callback() only fetches RSSI and updates the rate mask in station mode. This means, in AP mode only the default rate mask is used. In order to have the rate mask reflect the actual connection quality, extend rtl8xxxu_watchdog_callback() to iterate over every sta. Like in the rtw88 driver, add a function to collect all currently present stas and then iterate over a list of copies to ensure no RCU lock problems for register access via USB. Remove the existing RCU lock in rtl8xxxu_refresh_rate_mask(). Since the currently used ieee80211_ave_rssi() is only for 'vif', add driver-level tracking of RSSI per sta. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240205093040.1941140-1-martin.kaistra@linutronix.de
2024-02-06wifi: rtw89: fw: download firmware with key data for secure bootPing-Ke Shih
Since firmware header contains multiple secure sections, we need to trim ignored sections, and then download firmware header with single one secure section. For secure boot, when downloading secure section, copy security key data from MSS poll by key_idx read from efuse. If non-secure boot, no need this extra copy. +---------------------------+ -\ | firmware header | | | | | | +-----------------------+ | | only preserve single one secure | | section type/size * N | | | section | | ... | | | | +-----------------------+ | | +---------------------------+ -/ : : +---------------------------+ -\ | secure section type (ID:9)| | | | | +----|-> [ security key data ] | | | +---------------------------+ -/ | |MSS Pool for above section | | | [ security key data 0 ] | +----|- [ security key data 1 ] | by key_idx | [ security key data 2 ] | | ... | +---------------------------+ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240204012627.9647-5-pkshih@realtek.com
2024-02-06wifi: rtw89: fw: parse secure section from firmware filePing-Ke Shih
A firmware file can contains more than one section with secure type, so use secure information from efuse to choose the one with matched cryptography method. Then choose key data from MSS poll (multiple security section pool; see below picture) according to key_index from efuse. Note that the size of MSS pool isn't included in section size defined in firmware header, so we also need to parse header of MSS pool to get its size as shift to parse next section. If secure boot isn't supported by current hardware, the first secure section will be adopted, and no need additional process to key data. +---------------------------+ | firmware header | | | | +-----------------------+ | | | section type/size * N-|-|-------+ | | ... | | | | +-----------------------+ | | +---------------------------+ | : : | +---------------------------+ -\ | | secure section type (ID:9)| | | | | | <--+ | | | +---------------------------+ -/ |MSS Pool for above section | | | | | +---------------------------+ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240204012627.9647-4-pkshih@realtek.com
2024-02-06wifi: rtw89: fw: read firmware secure information from efusePing-Ke Shih
To support firmware secure boot, read secure information from efuse to know if current hardware module can support secure boot with certain cryptography method. This information should be prepared before downloading firmware, so read efuse right after power on at probe stage. The secure information includes secure cryptography method and secure key index that are used to choose proper key material when downloading firmware. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240204012627.9647-3-pkshih@realtek.com
2024-02-06wifi: rtw89: fw: consider checksum length of security dataPing-Ke Shih
The newer firmware file provides security data with checksum, so we need to consider the length. Otherwise it will fail to validate total firmware length resulting in failed to probe. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240204012627.9647-2-pkshih@realtek.com
2024-02-06wifi: rtw89: 8922a: add chip_ops::rfk_hw_initPing-Ke Shih
Add a chip_ops for WiFi 7 chips to set additional RF configurations including MLO and PLL settings. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240202030642.108385-12-pkshih@realtek.com
2024-02-06wifi: rtw89: 8922a: add chip_ops::rfk_init_late to do initial RF ↵Ping-Ke Shih
calibrations later The RF calibrations are moved into firmware, so we trigger calibrations by H2C commands and wait for C2H completion events. However, these events can be received only after HCI (i.e. PCI for now) starts, so we should do initial RF calibrations after that. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240202030642.108385-11-pkshih@realtek.com
2024-02-06wifi: rtw89: 8922a: rfk: implement chip_ops to call RF calibrationsPing-Ke Shih
Calling RF calibrations when interface up, connection, switching bands and going to scan. For 8922AE, RF calibrations are moved to firmware, so use H2C commands to trigger RF calibrations and wait for a C2H event to indicate completion. Then, do next RF calibration. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240202030642.108385-10-pkshih@realtek.com
2024-02-06wifi: rtw89: rfk: add H2C command to trigger TSSIPing-Ke Shih
TSSI is short for transmitter signal strength indication, which is a close-loop hardware circuit to feedback actual transmitting power as a reference to adjust power for next transmission. When connecting and switching bands or channels, do TSSI calibration and reset hardware status to output expected power. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240202030642.108385-9-pkshih@realtek.com
2024-02-06wifi: rtw89: rfk: add H2C command to trigger TXGAPKPing-Ke Shih
TXGAPK stands for TX power gap calibration. Use this calibration to compensate TX power gap to output expected power. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240202030642.108385-8-pkshih@realtek.com
2024-02-06wifi: rtw89: rfk: add H2C command to trigger DACKPing-Ke Shih
DACK (digital-to-analog converters calibration) is used to calibrate DAC to output signals with expected quality. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240202030642.108385-7-pkshih@realtek.com
2024-02-06wifi: rtw89: rfk: add H2C command to trigger DPKPing-Ke Shih
DPK is short for digital pre-distortion calibration. It can adjusts digital waveform according to PA linear characteristics dynamically to enhance TX EVM. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240202030642.108385-6-pkshih@realtek.com
2024-02-06wifi: rtw89: rfk: add H2C command to trigger RX DCKPing-Ke Shih
RX DCK is receiver DC calibration. This will calibrate DC offset to reflect correct received signal strength indicator, so mechanisms like CCA can have normalized values. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240202030642.108385-5-pkshih@realtek.com
2024-02-06wifi: rtw89: rfk: add H2C command to trigger IQKPing-Ke Shih
IQ signal calibration is a basic and important calibration to yield good RF performance. Do this calibration on AP channel if we are going to connect. During scanning phase, it transmits with low data rate, so without IQK RF performance is still acceptable. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240202030642.108385-4-pkshih@realtek.com
2024-02-06wifi: rtw89: rfk: send channel information to firmware for RF calibrationsPing-Ke Shih
We are going to do RF calibrations in firmware, so driver needs to provide channel information for calibrations, which can do the same things as they did in driver. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240202030642.108385-3-pkshih@realtek.com
2024-02-06wifi: rtw89: rfk: add a completion to wait RF calibration report from C2H eventPing-Ke Shih
The RF calibrations should be executed one by one, so add a completion to ensure one is finish before next. The report from C2H event contains state and optional version, and we only check the state for now. We also care about the time a RF calibration takes, so record start time before asking firmware to do calibration and get the delta time when receiving report. Consider SER recovery, we can't receive C2H event, use half of argument 'ms' as fixed delay that is 2 times of measured maximum time of calibrations. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240202030642.108385-2-pkshih@realtek.com
2024-02-05wifi: rtl8xxxu: Add TP-Link TL-WN823N V2Chun Qiu
TP-Link TL-WN823N V2 (2357:0135) is based on rtl8192fu and has been tested to work with the rtl8xxxu driver. Signed-off-by: Chun Qiu <cqca@cock.lu> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240129053030.16369-1-cqca@cock.lu
2024-02-01wifi: rtl8xxxu: fix error messagesDan Carpenter
The first parameter of WARN_ONCE() is a condition so this code will end up printing the function name instead of the proper message. Fixes: 3ff7a05996f9 ("wifi: rtl8xxxu: support setting bssid register for multiple interfaces") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/7b144531-a8da-4725-8911-9b614a525a35@moroto.mountain
2024-02-01wifi: rtw89: 8922a: add more fields to beacon H2C command to support multi-linksPo-Hao Huang
To support multi-links beacon, it needs more fields. But currently we still only support legacy AP mode. Only update struct to fit expected size of firmware. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240126063356.17857-8-pkshih@realtek.com
2024-02-01wifi: rtw89: update ps_state register for chips with different generationChin-Yen Lee
The ps_state register is used for driver to check if the WiFi chip leave power save mode successfully. The register is changed for new generation, so update it. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240126063356.17857-7-pkshih@realtek.com
2024-02-01wifi: rtw89: add new H2C for PS mode in 802.11be chipChin-Yen Lee
Because 802.11be chip support MLO mode, driver needs to send new H2C to pass more connected channel information to firmware, to ensure PS mode work fine. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240126063356.17857-6-pkshih@realtek.com
2024-02-01wifi: rtw89: 8922a: add ieee80211_ops::hw_scanPo-Hao Huang
This adds support for hardware scan after FW version 0.34.35. Currently we only support scanning on single hardware band and support of dual band scan will be added in the future. Adjust the current flow to make driver compatible with different generation ICs. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240126063356.17857-5-pkshih@realtek.com
2024-02-01wifi: rtw89: prepare scan leaf functions for wifi 7 ICsPo-Hao Huang
The channel field slightly differs between WiFi 6 and WiFi 7. So we prepare some required functions in advance, this doesn't change existing wifi 6 ICs behavior. This H2C prepares the channel list to be scanned for. With layout as the following: +--------+--------------------+-------------------+-----------------------+ | header | number of channels | channel info size | channel_info * number | +--------+--------------------+-------------------+-----------------------+ Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240126063356.17857-4-pkshih@realtek.com
2024-02-01wifi: rtw89: debug: add FW log component for scanPo-Hao Huang
This allows scan related logs when FW log debug mode is on. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240126063356.17857-3-pkshih@realtek.com
2024-02-01wifi: rtw89: update scan C2H messages for wifi 7 ICPo-Hao Huang
Add definition and parsing for wifi 7 extended fields. These fields include hardware index which is current reporting, timestamp and self defined sequences for debug purposes. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240126063356.17857-2-pkshih@realtek.com
2024-02-01wifi: rtw89: 8922a: set chip_ops FEM and GPIO to NULLPing-Ke Shih
The chip_ops::fem_setup is to get if a hardware module type contains PA and LNA that will affect how RF calibrations do. The chip_ops::rfe_gpio is to set GPIO PIN MUX according to hardware module type too. 8922A doesn't have these special module types yet, so leave them as NULL. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240124033813.12562-1-pkshih@realtek.com
2024-02-01wifi: rtw89: 8922a: add chip_ops to get thermal valuePing-Ke Shih
Get thermal value as a clue to do RF calibration if the delta is larger than a threshold, but 8922A doesn't need this, so we only read out the value when debugging to reduce IO. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240124033802.12508-1-pkshih@realtek.com
2024-02-01wifi: rtw89: 8922a: add RF read/write v2Ping-Ke Shih
Implement indirect interface v2 to read/write RF registers via PHY registers for 8922A. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240124033637.12330-5-pkshih@realtek.com
2024-02-01wifi: rtw89: 8922a: add chip_ops::cfg_txrx_pathPing-Ke Shih
This function is to set TX/RX path. Especially for 1SS rate, it can select to TX on one or two antenna. Before this operation, stop hardware to prevent transmitting/receiving unexpected packets. After that, restore settings and reset hardware to prevent it stays on abnormal state. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240124033637.12330-4-pkshih@realtek.com
2024-02-01wifi: rtw89: 8922a: implement {stop,resume}_sch_tx and cfg_ppduPing-Ke Shih
To set TX/RX path or set channel, we need these helpers to stop TX and restore settings. The sch_tx stands for scheduler TX channel, and the cfg_ppdu is to stop reporting PPDU status, so we should stop them during setting. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240124033637.12330-3-pkshih@realtek.com
2024-02-01wifi: rtw89: 8922a: hook handlers of TX/RX descriptors to chip_opsPing-Ke Shih
Hook implemented handlers to chip_ops, and fill packet frequency and signal strength to RX status from RX PPDU status packet. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240124033637.12330-2-pkshih@realtek.com
2024-02-01wifi: rtw89: pci: enlarge RX DMA buffer to consider size of RX descriptorPing-Ke Shih
Hardware puts RX descriptor and packet in RX DMA buffer, so it could be over one buffer size if packet size is 11454, and then it will be split into two segments. WiFi 7 chips use larger size of RX descriptor, so enlarge DMA buffer size according to RX descriptor to have better performance and simple flow. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240121071826.10159-5-pkshih@realtek.com
2024-02-01wifi: rtw89: pci: validate RX tag for RXQ and RPQPing-Ke Shih
PCI RX ring is a kind of read/write index ring, and DMA and ring index are asynchronous, so suddenly driver gets newer index ahead before DMA. To resolve this rare situation, we use a RX tag as helpers to make sure DMA is done. The RX tag is a 13-bit value, and range is from 1 ~ 0x1FFF, but 0 isn't used so should be skipped. Only enable this validation to coming WiFi 7 chips, because existing chips use different design and don't really meet this situation. Add missed rx_ring_eq_is_full for 8851BE by the way. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240121071826.10159-4-pkshih@realtek.com
2024-02-01wifi: rtw89: pci: interrupt v2 refine IMR for SERZong-Zhe Yang
During SER (system error recovery), expect to deal with only ISR related to halt. So, refine IMR configuration. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240121071826.10159-3-pkshih@realtek.com
2024-02-01wifi: rtw89: pci: update SER timer unit and timeout timePing-Ke Shih
Be higher resolution of SER timer unit from 32ms to 16ms to detect abnormal situation more accurately, and set hardware watchdog timer to 4ms. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240121071826.10159-2-pkshih@realtek.com
2024-01-23wifi: rtw89: fix disabling concurrent mode TX hang issueChih-Kang Chang
When disabling concurrent mode and switching to a single interface, the TX might stuck. The reason is TBTT prohibit area circuit still enable to block TX. To disable tbtt prohibit area circuit need to delay 2ms to make it effective. However, we only delay 2us in original code. So we fix it. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240119081501.25223-9-pkshih@realtek.com
2024-01-23wifi: rtw89: fix HW scan timeout due to TSF sync issueChih-Kang Chang
When STA connects to an AP and doesn't receive any beacon yet, the hardware scan is triggered. This scan begins with the default TSF value. Once STA receives a beacon when switches back to the operating channel, its TSF synchronizes with the AP. However, if there is a significant difference in TSF values between the default value and the synchronized value, it will cause firmware fail to trigger interrupt, and the C2H won't be sent out. As a result, the scan continues until a timeout occurs. To fix this issue, we disable TSF synchronization during scanning to prevent drastic TSF changes, and enable TSF synchronization after scan. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240119081501.25223-8-pkshih@realtek.com
2024-01-23wifi: rtw89: add wait/completion for abort scanPo-Hao Huang
When aborting scan, wait until FW is done to keep both states aligned. This prevents driver modifying channel then gets overwritten by FW. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240119081501.25223-7-pkshih@realtek.com
generated by cgit (git 2.34.1) at 2025-07-19 12:14:30 +0000