#
6ee10fcd |
|
29-Feb-2024 |
Ching-Te Ku <ku920601@realtek.com> |
wifi: rtw89: coex: Reorder H2C command index to align with firmware Wi-Fi firmware need some driver information to do decision or do some real-time control. Driver will update these information by H2C command. The chip 8922a H2C command index is different from before chips/branch, so need to assign the correct index to let firmware parsing. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240229074514.219276-6-pkshih@realtek.com
|
#
9d27596f |
|
29-Feb-2024 |
Ching-Te Ku <ku920601@realtek.com> |
wifi: rtw89: coex: add BTC ctrl_info version 7 and related logic Change structure member from bit field to normal variable to reduce unnecessary translation. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240229074514.219276-5-pkshih@realtek.com
|
#
652c9642 |
|
29-Feb-2024 |
Ching-Te Ku <ku920601@realtek.com> |
wifi: rtw89: coex: add init_info H2C command format version 7 To avoid using bit fields for H2C command, rearrange the structure. And also patch the corresponding code for the using of this structure. No logic changes for existing chips. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240229074514.219276-4-pkshih@realtek.com
|
#
dc10dadd |
|
21-Feb-2024 |
Kuan-Chung Chen <damon.chen@realtek.com> |
wifi: rtw89: advertise missing extended scan feature Add support for random serial number in probe request and configure channel dwell time. Advertise corresponding feature flag NL80211_EXT_FEATURE_SCAN_RANDOM_SN and NL80211_EXT_FEATURE_SET_SCAN_DWELL. Use the scan request duration as channel dwell time when it is non-zero, otherwise use the default value. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240222064258.59782-2-pkshih@realtek.com
|
#
63d94f74 |
|
13-Feb-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: remove unnecessary rcu_read_unlock() for punctured The rcu_read_unlock() is accidentally added, and sparse warn: drivers/net/wireless/realtek/rtw89/fw.c:2807:17: warning: context imbalance in 'rtw89_fw_h2c_assoc_cmac_tbl_g7' - unexpected unlock Fixes: b82730bf57b5 ("wifi: cfg80211/mac80211: move puncturing into chandef") Cc: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240213122556.9593-1-pkshih@realtek.com
|
#
9de7829a |
|
13-Feb-2024 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: fw: implement MRC H2C command functions Implement MRC (multiple role concurrent) H2C commands. Mainly deal with H2C format, LE type built from CPU value, default setting on some fields, and then sending the command to FW. Besides, MRC start, MRC delete, and MRC request TSF need to wait for a report from C2H events. 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/20240213073514.23796-4-pkshih@realtek.com
|
#
b82730bf |
|
29-Jan-2024 |
Johannes Berg <johannes.berg@intel.com> |
wifi: cfg80211/mac80211: move puncturing into chandef 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>
|
#
43f8a4dc |
|
03-Feb-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: download firmware with key data for secure boot 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
|
#
12ff5e1c |
|
03-Feb-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: parse secure section from firmware file 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
|
#
dedf78ef |
|
03-Feb-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: consider checksum length of security data 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
|
#
bd6f5f27 |
|
01-Feb-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: rfk: add H2C command to trigger TSSI 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
|
#
af41e89e |
|
01-Feb-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: rfk: add H2C command to trigger TXGAPK 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
|
#
1a0cba5d |
|
01-Feb-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: rfk: add H2C command to trigger DACK 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
|
#
b835141b |
|
01-Feb-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: rfk: add H2C command to trigger DPK 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
|
#
32919a04 |
|
01-Feb-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: rfk: add H2C command to trigger RX DCK 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
|
#
9c66da3b |
|
01-Feb-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: rfk: add H2C command to trigger IQK 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
|
#
80f47f82 |
|
01-Feb-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: rfk: send channel information to firmware for RF calibrations 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
|
#
e58e3117 |
|
25-Jan-2024 |
Chin-Yen Lee <timlee@realtek.com> |
wifi: rtw89: add new H2C for PS mode in 802.11be chip 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
|
#
4ba24331 |
|
25-Jan-2024 |
Po-Hao Huang <phhuang@realtek.com> |
wifi: rtw89: 8922a: add ieee80211_ops::hw_scan 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
|
#
a412920b |
|
25-Jan-2024 |
Po-Hao Huang <phhuang@realtek.com> |
wifi: rtw89: prepare scan leaf functions for wifi 7 ICs 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
|
#
ac54faf5 |
|
25-Jan-2024 |
Po-Hao Huang <phhuang@realtek.com> |
wifi: rtw89: debug: add FW log component for scan 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
|
#
f59a98c8 |
|
19-Jan-2024 |
Chih-Kang Chang <gary.chang@realtek.com> |
wifi: rtw89: fix HW scan timeout due to TSF sync issue 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
|
#
bcbefbd0 |
|
19-Jan-2024 |
Po-Hao Huang <phhuang@realtek.com> |
wifi: rtw89: add wait/completion for abort scan 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
|
#
7cf6b676 |
|
19-Jan-2024 |
Po-Hao Huang <phhuang@realtek.com> |
wifi: rtw89: Set default CQM config if not present When wpa_supplicant is initiated by users and not by NetworkManager, the CQM configuration might not be set. Without this setting, ICs with connection monitor handled by driver won't detect connection loss. To fix this we prepare a default setting upon associated at first, then update again if any is given later. 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-4-pkshih@realtek.com
|
#
49d15855 |
|
19-Jan-2024 |
Po-Hao Huang <phhuang@realtek.com> |
wifi: rtw89: refine add_chan H2C command to encode_bits Use struct filling style instead of pointer casting. This does not change the original behavior. 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-2-pkshih@realtek.com
|
#
3832a9c4 |
|
14-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: extend JOIN H2C command to support WiFi 7 chips WiFi 7 chips will support MLD, so there are more fields about that. But currently we don't support MLD yet, just define fields and bits by this patch ahead, and fill STA_TYPE only. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240115033742.16372-9-pkshih@realtek.com
|
#
85eacdca |
|
14-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: use struct to fill JOIN H2C command The JOIN command is used to tell firmware an new station is joining, and create an entry for it. This patch is only to convert to set data via struct, and don't change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240115033742.16372-8-pkshih@realtek.com
|
#
011e2768 |
|
14-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: add H2C command to reset DMAC table for WiFi 7 Reset DMAC table, so we get expected behavior instead of random values at early stage. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240115033742.16372-7-pkshih@realtek.com
|
#
3d49ed07 |
|
14-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: add H2C command to reset CMAC table for WiFi 7 Do reset on CMAC tables by mac_id, so we don't get random values when powering on. Therefore, add the same function for WiFi 7 chips. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240115033742.16372-6-pkshih@realtek.com
|
#
999db6f4 |
|
14-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: update TX AMPDU parameter to CMAC table The CMAC table is used to define how hardware TX a certain packet, and we can specify TX AMPDU size, so hardware can prepare proper retry window buffer. Otherwise, it can't transmit with expected aggregation number. Since each TID could have different aggregation number, the smallest number is adopted to prevent over peer's receiving buffer. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240115033742.16372-5-pkshih@realtek.com
|
#
7e24cc86 |
|
14-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: add chip_ops to update CMAC table to associated station For WiFi 7 chips, we add H2C command with rich fields to support MLO, so add a chip_ops to generalize calling of update CMAC table. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240115033742.16372-4-pkshih@realtek.com
|
#
79926193 |
|
14-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: fill CMAC table to associated station for WiFi 7 chips When a station get connected, fill hardware CMAC table via H2C command to tell hardware arguments related to transmit, such as the lowest rate, packet padding and so on. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240115033742.16372-3-pkshih@realtek.com
|
#
8d666e57 |
|
14-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: add H2C command to update security CAM v2 To have secure connection, set key information into security CAM including key index, entry index and valid map. This new introduced H2C command can support MLO, but currently not implement yet. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240115033742.16372-2-pkshih@realtek.com
|
#
bcd1ae78 |
|
08-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: add chip_ops::update_beacon to abstract update beacon operation Since coming WiFi 7 and existing chips use different update_beacon() format, add to abstract selection of H2C command. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240108091359.67636-1-pkshih@realtek.com
|
#
a880b928 |
|
08-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: add H2C command to download beacon frame for WiFi 7 chips The firmware of coming WiFi 7 chips can support more AP functions, like virtual AP, so extend format of download beacon frame to configure them. Currently rtw89 only enables AP mode as old chips, so leave new fields zeros. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240108091333.67484-1-pkshih@realtek.com
|
#
69466b97 |
|
08-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: use struct to fill H2C command to download beacon frame Download beacon frame via H2C command for AP mode, and then firmware can issues beacon periodically. Originally TIM offset minus fixed 24 bytes of frame header implicitly in macro, and this patch explicitly uses ieee80211_hdrlen() to get header length, but expected to change nothing at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240108091325.67424-1-pkshih@realtek.com
|
#
c313c31f |
|
08-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: add new H2C command to pause/sleep transmitting by MAC ID New H2C command is introduced to pause/sleep transmitting. That extends more bits to support more MAC ID, and currently we still configure 256 MAC ID at most. This new command is always used by coming WiFi 7 chips, and existing chips can use old or new command because firmware still preserves the old one. Add a firmware feature flag to determine which command is adopted according to firmware version. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240108091315.67358-1-pkshih@realtek.com
|
#
e3552b37 |
|
08-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: refine H2C command that pause transmitting by MAC ID To reuse this function to support extended H2C command that is used by newer chip, change to use a pointer to fill pause ID and mask. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240108091307.67296-1-pkshih@realtek.com
|
#
cdd368ce |
|
08-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: use struct to fill BA CAM H2C commands The WiFi 6 chips use these commands to create BA CAM entry when RX BA session is established, this BA CAM can record whether packets are received or not, then reply BA for current status. This patch doesn't change logic. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240108091245.67220-1-pkshih@realtek.com
|
#
5d461dba |
|
08-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: add chip_ops::h2c_ba_cam() to configure BA CAM Since chips could use different version of BA CAM H2C command, add a chip_ops to abstract the operation. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240108091134.67007-4-pkshih@realtek.com
|
#
3b96833a |
|
08-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: mac: add feature_init to initialize BA CAM V1 Add a call of feature_init() when bringing interface up. For now, the feature is to reset BA CAM V1 that is only used by upcoming 8922A. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240108091134.67007-3-pkshih@realtek.com
|
#
6f066439 |
|
08-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: add firmware H2C command of BA CAM V1 BA CAM is used to generate BA frame for received AMPDU packets. To support WiFi 7, change format from V0 to have more fields and enlarge entry number for new need. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240108091134.67007-2-pkshih@realtek.com
|
#
293f7bdc |
|
11-Dec-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: add DBCC H2C to notify firmware the status To support MLO of WiFi 7, we should configure hardware as DBCC mode, and notify this status to firmware. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231211083341.118047-6-pkshih@realtek.com
|
#
178b8e7d |
|
12-Dec-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: add C2H event handlers of RFK log and report Trigger a RFK (RF calibration) in firmware by a H2C command, and in progress it reports log and a result finally by C2H events. Firstly, add prototype of the C2H event handlers to have a simple picture of framework. The callers who trigger H2C will wait until a C2H event is received, so we must process these C2H events in receiving process. Thus, mark this kind of C2H events as atomic. Also, timestamp is also useful for debugging, mark C2H events carrying RFK log as atomic as well. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231213005054.10568-5-pkshih@realtek.com
|
#
7a9192ee |
|
12-Dec-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: load RFK log format string from firmware file To debug RFK (RF calibration) in firmware, it sends log via firmware C2H events to driver with string format ID and four arguments. Load formatted string from firmware file, and the string ID can get back its string. Then, use regular print format to show the message. This firmware element layout looks like +============================================+ | elm ID | elm size | version | | +----------+----------+----------+-----------+ | | nr |rsvd |rfk_id|rsvd| +--------------------------------------------+ | offset[] (__le16 * nr) | | ... | +--------------------------------------------+ | formatted string with null termintor (*nr) | | ... | +============================================+ * a firmware file can contains more than one elements with this element ID named RTW89_FW_ELEMENT_ID_RFKLOG_FMT (19), because many RFK needs its own formatted strings, so add 'rfk_id' to know it belongs to which RFK. * the 'formatted string' just follow 'offset[]' without padding to align 32bits. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231213005054.10568-4-pkshih@realtek.com
|
#
344c066f |
|
12-Dec-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: add version field to BB MCU firmware element 8922AE has more than one hardware version, and they use different BB MCU firmware, so occupy a byte from element priv[] to annotate version. Since there are more than one firmware and only matched version is adopted, return 1 to ignore not matched firmware. +===========================================+ | elm ID | elm size | version | | +----------+----------+----------+----------+ | | element_priv[] | +-------------------------------------------+ change to | v +===========================================+ | elm ID | elm size | version | | +----------+----------+----------+----------+ | | cv | element_rsvd[] | +-------------------------------------------+ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231213005054.10568-3-pkshih@realtek.com
|
#
d60e73e5 |
|
12-Dec-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: load TX power track tables from fw_element The TX power track tables are used to define compensation power reflected to thermal value. Currently, we have 16 (2 * 4 * 2) tables made by combinations of {negative/positive thermal value, 2GHz/2GHz-CCK/5GHz/6GHz, path A/B} Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231213005054.10568-2-pkshih@realtek.com
|
#
2a68a27c |
|
04-Dec-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: fw: extend program counter dump for Wi-Fi 7 chip Extend FW program counter dump for Wi-Fi 7 chip. They poll different addresses. 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://lore.kernel.org/r/20231204080751.15354-3-pkshih@realtek.com
|
#
c5ece8d8 |
|
04-Dec-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: 8922a: configure CRASH_TRIGGER FW feature RTL8922A FW supports CRASH_TRIGGER feature from v0.34.30.0. After it, debugfs fw_crash can accept type 1 on RTL8922A to trigger firmware crash and verify L2 recovery. Besides, RTL8922A sync address offset of reserved payload engine. And, SER (system error recovery) tweaks conversion from WCPU address to indirect access address for RTL8922A. The new conversion works for all supported chips. 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://lore.kernel.org/r/20231204080751.15354-2-pkshih@realtek.com
|
#
756b3120 |
|
29-Nov-2023 |
Chih-Kang Chang <gary.chang@realtek.com> |
wifi: rtw89: fix misbehavior of TX beacon in concurrent mode In concurrent mode, when STA interface is scanning, it causes AP interface TX beacon on wrong channel. We modified it to scan with the operating channel when one of the interfaces is already connected. Additionally, STA interface need to stop scan when AP interface is starting to avoid TX beacon on wrong channel. Finally, AP interface need to stop TX beacon when STA interface is scanning and switching to non-OP channel,This prevent other device to get beacons on wrong channel. 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://lore.kernel.org/r/20231129070046.18443-5-pkshih@realtek.com
|
#
2f3eaccc |
|
29-Nov-2023 |
Po-Hao Huang <phhuang@realtek.com> |
wifi: rtw89: Refine active scan behavior in 6 GHz The interval between sending each probe request is regulated. Before this patch, some packets are not sent out properly because of our HW limit. Extend the 6 GHz channel dwell time to cope with this. 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://lore.kernel.org/r/20231129070046.18443-3-pkshih@realtek.com
|
#
7d7b6f29 |
|
19-Oct-2023 |
Dmitry Antipov <dmantipov@yandex.ru> |
wifi: rtw89: cleanup firmware elements parsing When compiling with clang-18, I've noticed the following: drivers/net/wireless/realtek/rtw89/fw.c:389:28: warning: cast to smaller integer type 'enum rtw89_fw_type' from 'const void *' [-Wvoid-pointer-to-enum-cast] 389 | enum rtw89_fw_type type = (enum rtw89_fw_type)data; | ^~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/realtek/rtw89/fw.c:569:13: warning: cast to smaller integer type 'enum rtw89_rf_path' from 'const void *' [-Wvoid-pointer-to-enum-cast] 569 | rf_path = (enum rtw89_rf_path)data; | ^~~~~~~~~~~~~~~~~~~~~~~~ So avoid brutal everything-to-const-void-and-back casts, introduce 'union rtw89_fw_element_arg' to pass parameters to element handler callbacks, and adjust all of the related bits accordingly. Compile tested only. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231020040940.33154-1-dmantipov@yandex.ru
|
#
5f499ce6 |
|
20-Sep-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: pause/proceed MCC for ROC and HW scan During (TDMA-based) MCC (multi-channel concurrency), the below two cases might not have a good behavior on channel usage. * ROC (remain on channel) * HW scan So, we tend to separate them from MCC. The two cases would expect to operate the channel to which they want. However, during MCC, channels are scheduled by FW MCC state mechanism. So, channels cannot be controlled explicitly. To avoid the two cases from operating wrong channels with chance, we pause MCC (essentially stop FW MCC) once the two cases are coming. And then, we proceed MCC again (essentially restart FW MCC) once the two cases finish. 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://lore.kernel.org/r/20230921003559.11588-3-pkshih@realtek.com
|
#
5ee7b2ea |
|
20-Sep-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: load TX power related tables from FW elements The following FW elements are recognized, and then the valid entries in them are loaded into SW struct case by case. * TX power by rate * TX power limit 2 GHz * TX power limit 5 GHz * TX power limit 6 GHz * TX power limit RU 2 GHz * TX power limit RU 5 GHz * TX power limit RU 6 GHz * TX shape limit * TX shape limit RU One single firmware file can contain multiples of each of the above FW elements. Each of them is configured with a target RFE (RF front end) type. We choose one of the multiples to load based on RFE type. If there are multiples of the same FW elements with the same target RFE type. The last one will be applied. We don't want to have many loading variants for above FW elements. Even if between different chips or between different generations, we would like to maintain only one single set of loadings. So, the loadings are designed to consider compatibility. The main concepts are listed below. * The driver structures, which are used to cast binary entry from FW, cannot insert new members in the middle. If there are something new, they should always be appended at the tail. * Each binary entry from FW uses a dictionary way containing a key set and a data. The keys in the key set indicate where to put the data. * If size of driver struct and size of binary entry do not match when loading, it means the number of keys in the key set are different. Then, we deal with compatibility. No matter which one has more keys, we take/use zero on those mismatched keys. If driver struct is bigger (backward compatibility): e.g. SW uses two keys, but FW is built with one key. Then, put the data of FW(keyX) into SW[keyX][0]. If binary entry is bigger (forward compatibility): e.g. FW is built with two keys, but SW uses one key. Then, only take the data of FW(keyX, keyY = 0) into SW[keyX] Besides, chip info setup flow is tweaked a bit for the following. * Before loading FW elements, we need to determine chip RFE via efuse. * Setting up RFE parameters depends on loading FW elements ahead. 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://lore.kernel.org/r/20230920074322.42898-8-pkshih@realtek.com
|
#
74b45618 |
|
07-Sep-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: 52c: rfk: refine MCC channel info notification RF calibration will notify FW to backup the calibration result after it is done on a channel. For MCC (multi-channel concurrency) flow, when we at RTW89_ENTITY_MODE_MCC_PREPARE mode, RF calibration should execute on second channel of MCC, i.e. RTW89_SUB_ENTITY_1, and then, notify FW to backup the result for the second one. Originally, the RF calibration flow only fit single channel case. We are planning to support MCC on RTL8852C, so we refine its RF calibration flow to fit MCC case. 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://lore.kernel.org/r/20230908031145.20931-2-pkshih@realtek.com
|
#
b227c990 |
|
01-Sep-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: 8922a: set memory heap address for secure firmware Secure firmware is protected by public/private key cryptography. To help firmware self verify integrity, configure a heap address for these data before downloading firmware. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-9-pkshih@realtek.com
|
#
38bae445 |
|
01-Sep-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: refine download flow to support variant firmware suits To support download more than one firmware, adjust flow to download firmware by unit of firmware suit. Then, flow becomes 1. initial setup - disable/enable_wcpu 2. for all firmware suits 2.1. download WiFi CPU, and check ready 2.2. download BB MCU, and check ready 3. check status code to make sure all ready Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-8-pkshih@realtek.com
|
#
a712eef6 |
|
01-Sep-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: propagate an argument include_bb for BB MCU firmware Though WiFi 7 chips need BB MCU firmware, we don't download it in probe stage. Instead, only bring interface up under normal operation or WoWLAN mode. So, add an argument to assist download flow to setup download settings properly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-6-pkshih@realtek.com
|
#
fa31a8c5 |
|
01-Sep-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: add checking type for variant type of firmware For WiFi 6 chips, there is only single one firmware i.e. WiFi CPU firmware, so no need an argument to discriminate them. For WiFi 7 chips, BB MCU firmware is introduced, and we need to check it ready after downloading. For each type of firmware, we need to check corresponding hardware ready bit. After downloading all firmware, check status code to determine if all things are ready. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-5-pkshih@realtek.com
|
#
ae4dc23d |
|
01-Sep-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: generalize download firmware flow by mac_gen pointers In order to reuse the flow to download firmware, define some mac_gen::ops to implement them for WiFi 6 and 7 chips individually. This doesn't change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-3-pkshih@realtek.com
|
#
80e706a8 |
|
01-Sep-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: move polling function of firmware path ready to an individual function To download firmware, we need to check path is ready. There are two kinds of path -- one is to download firmware header, and the other is to download firmware body. Since the polling method is different from WiFi 7 chips, make it to be an individual function, and then we can reuse the download flow. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-2-pkshih@realtek.com
|
#
980d4215 |
|
30-Aug-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: fix typo of rtw89_fw_h2c_mcc_macid_bitmap() Fix a typo where `bitamp` should be `bitmap`. Don't change functionality at all. 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://lore.kernel.org/r/20230831053133.24015-6-pkshih@realtek.com
|
#
9d87e7dc |
|
22-Aug-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: mac: define register address of rx_filter to generalize code rx_filter is used to decide which kind of packets are received to driver, or just dropped by MAC layer to reduce bus traffic. The bit definitions of old and new chips are the sames, but only address is changed, so define a field to generalize usage. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230822125822.23817-5-pkshih@realtek.com
|
#
c220d08e |
|
22-Aug-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: mac: add mac_gen_def::band1_offset to map MAC band1 register address There are two copies of MAC hardware called band0 and band1. Basically, the only difference between them is base address, so we can share functions with a 'band' (or 'mac_idx') argument. The offset of base address of WiFi 6 and 7 are 0x2000 and 0x4000 respectively, so add band1_offset field to new introduced struct mac_gen_def to possibly reuse functions. Using below spatch script to convert callers: @@ expression reg, band; @@ - rtw89_mac_reg_by_idx(reg, band) + rtw89_mac_reg_by_idx(rtwdev, reg, band) @@ expression reg, port, band; @@ - rtw89_mac_reg_by_port(reg, port, band) + rtw89_mac_reg_by_port(rtwdev, reg, port, band) Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230822125822.23817-2-pkshih@realtek.com
|
#
51383fd7 |
|
16-Aug-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: provide functions to configure NoA for beacon update Callers call renew function when wanting to generate a new P2P NoA information element, and call append function to append NoA attribute one by one. Then, updating beacon work will fetch the P2P NoA information element configured by callers and add it to beacon. The use case of MCC (multi-channel concurrent) <GO + STA> for example: * start MCC - GO part renew P2P NoA append period NoA after calculation * download beacon for GO fetch P2P NoA and add to beacon content * stop MCC - GO part renew P2P NoA (reset) 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://lore.kernel.org/r/20230816082133.57474-6-pkshih@realtek.com
|
#
ad3dc722 |
|
16-Aug-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: call rtw89_chan_get() by vif chanctx if aware of vif We adjust these processes which can work accodrding to vif but call rtw89_chan_get() with static RTW89_SUB_ENTITY_0. After multi-channel support, chanctx of vif won't always be on RTW89_SUB_ENTITY_0. So, we make them call rtw89_chan_get() with rtwvif->sub_entity_idx. 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://lore.kernel.org/r/20230816082133.57474-5-pkshih@realtek.com
|
#
e2a61151 |
|
07-Aug-2023 |
Dan Carpenter <dan.carpenter@linaro.org> |
wifi: rtw89: fix a width vs precision bug The "buf" is skb->data that comes from the firmware. We want to print "len" number of bytes. But there is a missing period so the "len" variable is used for formatting (width) instead of limiting the output (precision). Fixes: cad2bd8a136c ("wifi: rtw89: support firmware log with formatted text") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/0700c7b9-bfd3-4aa6-82bf-5bf3c74644e1@moroto.mountain
|
#
dd59c6a3 |
|
31-Jul-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: return failure if needed firmware elements are not recognized WiFi 7 chips doesn't have static const tables defined in driver. If tables aren't loaded properly from firmware file, driver can get NULL pointer access exception. One way is to add the checking statements when trying to access these tables, but I choose to check them right after loading firmware elements from firmware file, so I don't need to add error handlers everywhere. Currently, the needed firmware elements of WiFi 6 chips are all zero, and coming WiFi 7 chip will need at least BB MCU, parameters of BB and RF. We will add them after 8922AE is verified. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230801021127.15919-9-pkshih@realtek.com
|
#
89474720 |
|
31-Jul-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: add to parse firmware elements of BB and RF tables The tables of BB and RF parameters are pairs of {addr, value}. Load them and convert from little-endian to CPU order, and show the version to clear which version we are using. rtw89_8922ae 0000:03:00.0: Firmware element BB version: 00 04 00 00 rtw89_8922ae 0000:03:00.0: Firmware element radio A version: 00 13 00 00 rtw89_8922ae 0000:03:00.0: Firmware element NCTL version: 00 05 00 00 We use tables defined in firmware elements with higher priority than original static const tables defined in driver, because WiFi 7 chips will not define the tables in driver, and existing chips can possibly migrate to the new design one by one. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230801021127.15919-8-pkshih@realtek.com
|
#
a337d433 |
|
31-Jul-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: introduce infrastructure of firmware elements In order to pack more data into firmware file, we introduce firmware elements and append BB_MCU firmware first. The first part of new firmware file is still unchanged firmware of WiFi CPU, so the new firmware format can be backward compatible to old format. The new elements part consists of ID and size basically, which can append more elements simply. To avoid unaligned access in certain platform and be easy to read, headers of all elements start at 16-byte aligned address. +===========================================+ | original firmware | | +-------------+ | | padding | +===========================================+ | elm ID 1 | elm size | other header data | +----------+----------+ | | | +-------------------------------------------+ | content (variable length) | | +-------------+ | | padding | +===========================================+ | elm ID 2 | elm size | other header data | +----------+----------+ | | | +-------------------------------------------+ | content (variable length) | | +-----------------------+ | | (no padding for the last one) +===================+ More detail of element header is shown below. The additional fields 'version' and 'element_priv[]' are meta data of elements, so that we can know element version easily, and element_priv[] provide specific fields for certain element, such as RF path index for RF parameter tables. +===========================================+ | elm ID | elm size | version | rsvd0 | +----------+----------+----------+----------+ | rsvd1/2 | element_priv[] | +-------------------------------------------+ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230801021127.15919-7-pkshih@realtek.com
|
#
12b1a125 |
|
31-Jul-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: add firmware parser for v1 format A firmware with v1 format contains many sections to download. Add parser to read section type, target address, length, checksum and so on, and then download the section to WiFi CPU with proper location. The additional dynamic header length named dynamic_hdr_len is used to skip content of dynamic header containing compiler flags of firmware, which can help to determine variant firmware build, but currently rtw89 only use single one variant. So, just skip the content. The layout of a WiFi CPU firmware with v1 format looks like: +---------------------------------------+ | Header (12 words) | +---------------------------------------+ | Section header 1 (4 words) | | Section header 2 (4 words) | | Section header 3 (4 words) | | ... | +---------------------------------------+ | Dynamic header (variable length) | +---------------------------------------+ | Data used & pointed by section | | ... | +---------------------------------------+ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230801021127.15919-5-pkshih@realtek.com
|
#
1b073b35 |
|
31-Jul-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: introduce v1 format of firmware header New firmware header is used by upcoming WiFi 7 chips to have more information, so use common field w3[31:24] to determine header version, and then use corresponding function to read firmware version and commit ID: rtw89_8852be 0000:03:00.0: Firmware version 0.29.29.1 (799134c3), cmd version 1, type 5 rtw89_8852be 0000:03:00.0: Firmware version 0.29.29.1 (799134c3), cmd version 1, type 3 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230801021127.15919-4-pkshih@realtek.com
|
#
cad2bd8a |
|
31-Jul-2023 |
Chin-Yen Lee <timlee@realtek.com> |
wifi: rtw89: support firmware log with formatted text Original firmware log which is sent via C2H message bloats code size of firmware and is also length-limited. So we put some common log into format file, and firmware could use a log ID and some variables in C2H message to map a formatted text via pre-designed rule. 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://lore.kernel.org/r/20230801021127.15919-3-pkshih@realtek.com
|
#
05208419 |
|
31-Jul-2023 |
Chin-Yen Lee <timlee@realtek.com> |
wifi: rtw89: recognize log format from firmware file Firmware log format is an element of multi-firmware file and used for firmware to provide log with formatted text. Driver needs to recognize it in advance if it exists. 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://lore.kernel.org/r/20230801021127.15919-2-pkshih@realtek.com
|
#
c342ac21 |
|
28-Jul-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: use struct to access firmware C2H event header Firmware C2H events contain two-word header which can indicate category, class, function and length of received events. Use struct to access them, and doesn't change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230728070252.66525-7-pkshih@realtek.com
|
#
c97683ff |
|
28-Jul-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: add H2C RA command V1 to support WiFi 7 chips H2C RA V1 command adds two words to support WiFi 7 chips, which can possibly support up to 4SS rates. Because current chips have only 2SS rates, leave the fields blank for now. The main changes are to set extended bits of EHT mode and bandwidth -- add a bit for EHT mode; add a bit to enumerate 320MHz channel bandwidth. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230728070252.66525-6-pkshih@realtek.com
|
#
401b0c16 |
|
28-Jul-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: use struct to set RA H2C command RA (rate adaptive) H2C command is used to tell firmware which rates can be used for specified MAC ID. Basically, this commit doesn't change result. Only change to set two 32-bit instead of continual 8-byte rate masks one by one. Originally, we only set 5-byte masks, because existing WiFi 6 2SS chips only need 5-byte masks. Setting two 32-bit masks will be more efficient and also can support coming WiFi 7 2SS chips containing more rates. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230728070252.66525-5-pkshih@realtek.com
|
#
942999c4 |
|
24-Jul-2023 |
Larry Finger <Larry.Finger@lwfinger.net> |
wifi: rtw89: Fix loading of compressed firmware When using compressed firmware, the early firmware load feature will fail. In most cases, the only downside is that if a device has more than one firmware version available, only the last one listed will be loaded. In at least two cases, there is no firmware loaded, and the device fails initialization. See https://github.com/lwfinger/rtw89/issues/259 and https://bugzilla.opensuse.org/show_bug.cgi?id=1212808 for examples of the failure. When firmware_class.dyndbg=+p" added to the kernel boot parameters, the following is found: finger@localhost:~/rtw89>sudo dmesg -t | grep rtw89 firmware_class: __allocate_fw_priv: fw-rtw89/rtw8852b_fw-1.bin fw_priv=00000000638862fb rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/5.14.21-150500.53-default/rtw89/rtw8852b_fw-1.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/rtw89/rtw8852b_fw-1.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/5.14.21-150500.53-default/rtw89/rtw8852b_fw-1.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/rtw89/rtw8852b_fw-1.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: Direct firmware load for rtw89/rtw8852b_fw-1.bin failed with error -2 firmware_class: __free_fw_priv: fw-rtw89/rtw8852b_fw-1.bin fw_priv=00000000638862fb data=00000000307c30c7 size=0 firmware_class: __allocate_fw_priv: fw-rtw89/rtw8852b_fw.bin fw_priv=00000000638862fb rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/5.14.21-150500.53-default/rtw89/rtw8852b_fw.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/rtw89/rtw8852b_fw.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/5.14.21-150500.53-default/rtw89/rtw8852b_fw.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/rtw89/rtw8852b_fw.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: Direct firmware load for rtw89/rtw8852b_fw.bin failed with error -2 firmware_class: __free_fw_priv: fw-rtw89/rtw8852b_fw.bin fw_priv=00000000638862fb data=00000000307c30c7 size=0 rtw89_8852be 0000:02:00.0: failed to early request firmware: -2 firmware_class: __allocate_fw_priv: fw-rtw89/rtw8852b_fw.bin fw_priv=00000000638862fb rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/5.14.21-150500.53-default/rtw89/rtw8852b_fw.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/rtw89/rtw8852b_fw.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/5.14.21-150500.53-default/rtw89/rtw8852b_fw.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/rtw89/rtw8852b_fw.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/5.14.21-150500.53-default/rtw89/rtw8852b_fw.bin.xz failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/rtw89/rtw8852b_fw.bin.xz failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/5.14.21-150500.53-default/rtw89/rtw8852b_fw.bin.xz failed for no such file or directory. rtw89_8852be 0000:02:00.0: Loading firmware from /lib/firmware/rtw89/rtw8852b_fw.bin.xz rtw89_8852be 0000:02:00.0: f/w decompressing rtw89/rtw8852b_fw.bin firmware_class: fw_set_page_data: fw-rtw89/rtw8852b_fw.bin fw_priv=00000000638862fb data=000000004ed6c2f7 size=1035232 rtw89_8852be 0000:02:00.0: Firmware version 0.27.32.1, cmd version 0, type 1 rtw89_8852be 0000:02:00.0: Firmware version 0.27.32.1, cmd version 0, type 3 The key is that firmware version 0.27.32.1 is loaded. With this patch, the following is obtained: firmware_class: __free_fw_priv: fw-rtw89/rtw8852b_fw.bin fw_priv=000000000849addc data=00000000fd3cabe2 size=1035232 firmware_class: fw_name_devm_release: fw_name-rtw89/rtw8852b_fw.bin devm-000000002d8c3343 released firmware_class: __allocate_fw_priv: fw-rtw89/rtw8852b_fw-1.bin fw_priv=000000009e1a6364 rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/6.4.3-1-default/rtw89/rtw8852b_fw-1.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/rtw89/rtw8852b_fw-1.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/6.4.3-1-default/rtw89/rtw8852b_fw-1.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/rtw89/rtw8852b_fw-1.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/6.4.3-1-default/rtw89/rtw8852b_fw-1.bin.zst failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/rtw89/rtw8852b_fw-1.bin.zst failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/6.4.3-1-default/rtw89/rtw8852b_fw-1.bin.zst failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/rtw89/rtw8852b_fw-1.bin.zst failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/6.4.3-1-default/rtw89/rtw8852b_fw-1.bin.xz failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/rtw89/rtw8852b_fw-1.bin.xz failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/6.4.3-1-default/rtw89/rtw8852b_fw-1.bin.xz failed for no such file or directory. rtw89_8852be 0000:02:00.0: Loading firmware from /lib/firmware/rtw89/rtw8852b_fw-1.bin.xz rtw89_8852be 0000:02:00.0: f/w decompressing rtw89/rtw8852b_fw-1.bin firmware_class: fw_set_page_data: fw-rtw89/rtw8852b_fw-1.bin fw_priv=000000009e1a6364 data=00000000fd3cabe2 size=1184992 rtw89_8852be 0000:02:00.0: Loaded FW: rtw89/rtw8852b_fw-1.bin, sha256: 8539efc75f513f4585cf0cd6e79e6507da47fce87225f2d0de391a03aefe9ac8 rtw89_8852be 0000:02:00.0: loaded firmware rtw89/rtw8852b_fw-1.bin rtw89_8852be 0000:02:00.0: Firmware version 0.29.29.1, cmd version 0, type 5 rtw89_8852be 0000:02:00.0: Firmware version 0.29.29.1, cmd version 0, type 3 Now, version 0.29.29.1 is loaded. Fixes: ffde7f3476a6 ("wifi: rtw89: add firmware format version to backward compatible with older drivers") Cc: Ping-Ke Shih <pkshih@realtek.com> Cc: Takashi Iwai <tiwai@suse.de> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230724183927.28553-1-Larry.Finger@lwfinger.net
|
#
f072eb39 |
|
16-Jun-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: use struct to parse firmware header A firmware contains basic header, sections and optional dynamic header. Define them by a struct, so it will be easier to understand the layout, and also simply access these elements. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230616060601.28460-1-pkshih@realtek.com
|
#
57369e2a |
|
31-May-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: 8851b: configure CRASH_TRIGGER feature for 8851B RTL8851B firmware supports CRASH_TRIGGER feature from v0.29.41.0. After this is configured, debugfs fw_crash can support type 1 on RTL8851B to trigger firmware crash and verify L2 recovery through simulation. 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://lore.kernel.org/r/20230531060713.57203-5-pkshih@realtek.com
|
#
9c52e8bf |
|
31-May-2023 |
Po-Hao Huang <phhuang@realtek.com> |
wifi: rtw89: 8851b: enable hw_scan support This enables hw_scan for 8851b after firmware version 0.29.37.1. Extend the channel info struct with padding zeros so newer firmware can work properly, this change is backward compatible with older 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://lore.kernel.org/r/20230531060713.57203-2-pkshih@realtek.com
|
#
68012b44 |
|
22-May-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: use struct to access register-based H2C/C2H The register-based H2C/C2H are used to exchange commands and events with firmware. The exchange data is limited, but it is relatively simple, because it can work before HCI initialization. To make these code clean, use struct to access them. This patch doesn't change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230522122513.13559-6-pkshih@realtek.com
|
#
c4ff5014 |
|
18-May-2023 |
Chin-Yen Lee <timlee@realtek.com> |
wifi: rtw89: add tx_wake notify for 8851B 8851B has the same issue: management frames get stuck when WiFi chip enters low PS mode, so we also add notify wake function to trigger WiFi chip wake before forwarding management frames. 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://lore.kernel.org/r/20230519031500.21087-7-pkshih@realtek.com
|
#
8b21c08e |
|
16-May-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: refine packet offload handling under SER H2C of packet offload needs to wait FW ACK by C2H. But, it's possible that packet offload happens during SER (system error recovery), e.g. SER L2 which restarts HW. More, packet offload flow isn't deferrable. So, the H2C wait may get `ret == 1` (unreachable). However, the logic FW deals with packet offload is simple enough, just clone content. It means that as long as the H2C is issued successfully, the thing will succeed sooner or later. Therefore, after we add a debug log when receiving ACK to packet offload, it would be acceptable that during SER, packet offload don't really wait for ACK. And, if debugging, we can still check its debug logs. Besides, we can expect that if we see SER before receiving ACK to packet offload, those debug logs of the ACK have a time difference. 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://lore.kernel.org/r/20230516082441.11154-4-pkshih@realtek.com
|
#
b79a84fb |
|
16-May-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: tweak H2C TX waiting function for SER Some specific H2C (host to chip command) needs waiting until FW ACK by C2H (chip to host event). However, during SER (system error recovery), most interrupts are disabled, so we can't receive C2H immediately. It causes this kind of H2C TX waits will always time out during SER. To save time spent by SER, we don't do these redundant waits. And, to make a difference from -ETIMEDOUT in other cases, we make the function return 1 for SER case. When some H2C callers really catch `ret == 1` at runtime, they can determine whether it's reasonable or not, and consider how to resolve their flow if needed. 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://lore.kernel.org/r/20230516082441.11154-3-pkshih@realtek.com
|
#
b6335d91 |
|
20-Apr-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: change naming of BA CAM from V1 to V0_EXT BA CAM of 8852C has more entries and more fields of H2C, and needs initialization before using. Due to differences from 8852A/8852B, we name it as V1 before. However, real V1 of BA CAM is introduced now, so change it to V0_EXT to avoid confusing with firmware design. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230421024551.29994-7-pkshih@realtek.com
|
#
b9b632f4 |
|
19-Apr-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: scan offload wait for FW done ACK The following are scan offload related H2C (host to chip) function types. * H2C_FUNC_ADD_SCANOFLD_CH * H2C_FUNC_SCANOFLD Before doing FW scan, we will continuously send multiple H2Cs with above types which are used to tell FW the scan configuration of this time. But, if FW doesn't handle one of these H2Cs well, the FW scan process might not run as expected and driver should notice it early. So, this commits makes scan offload related H2Cs wait for FW done ACK via rtw89_wait_for_cond() and rtw89_complete_cond(). And, we check the return code of these H2Cs from FW. 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://lore.kernel.org/r/a15f4bd594f71d7602ea67698b035805143700c9.camel@realtek.com
|
#
8febd68b |
|
19-Apr-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: packet offload wait for FW response The H2Cs (host to chip packets) related to packet offload functions need to wait for FW responses in case FW state machine gets wrong and makes driver status no longer able to align FW one. In flow, driver may continuously send multiple H2Cs of packet offload series. If somehow FW doesn't deal with the former yet but the latter has gotten in, it might cause the problem mentioned above. So, we block these H2Cs by rtw89_wait_for_cond(). And then, when the corresponding C2Hs (chip to host packets) is received, we call rtw89_complete_cond(). Besides, RTW89_MAC_C2H_FUNC_PKT_OFLD_RSP's C2H handler should be executed in interrupt context to make our wait/complete process work as expected. 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://lore.kernel.org/r/9ae8c1f105901c65e3171276a9fd6c99ae51803f.camel@realtek.com
|
#
3ea1cd8d |
|
19-Apr-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: refine packet offload delete flow of 6 GHz probe There are two places where offload packets of 6 GHz probe would be deleted from FW, i.e. calling rtw89_fw_h2c_del_pkt_offload(). * rtw89_core_cancel_6ghz_probe_tx() * rtw89_release_pkt_list() It is possible that we try to delete the same one from FW twice. Although it might not be a big problem for now, it will depend on the runtime chip firmware. So, we add a check to avoid it. In case things becomes complex due to racing problem, we don't choose to do list_del(info->list) and kfree(info) in both sides. Besides, rtw89_fw_h2c_del_pkt_offload() will needs to wait for completion after the follow-up commit. However, rtw89_core_cancel_6ghz_probe_tx() was called in interrupt context. So, we move the stuffs of calling rtw89_fw_h2c_del_pkt_offload() from rtw89_core_cancel_6ghz_probe_tx() into a work. Then, we also need a check there before we call it. 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://lore.kernel.org/r/091966e5709cd7caecf9b81f7fd6388ae2b70a7e.camel@realtek.com
|
#
25a7e507 |
|
19-Apr-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: release bit in rtw89_fw_h2c_del_pkt_offload() We have a pair of FW functions, rtw89_fw_h2c_add_pkt_offload() and rtw89_fw_h2c_del_pkt_offload(). The rtw89_fw_h2c_add_pkt_offload() acquires the bit itself, but the bit needs to be released by the caller of rtw89_fw_h2c_del_pkt_offload(). This looks asymmetrical and is not friendly to callers. Second, if callers always releases the bits, it might make driver unaligned to bitmap status of FW after some failures of calling rtw89_fw_h2c_del_pkt_offload(). So, this commit move bit release into rtw89_fw_h2c_del_pkt_offload(). In general, driver will call rtw89_fw_h2c_add_pkt_offload() and rtw89_fw_h2c_del_pkt_offload(), and then, SW bitmap can align with FW one. There is one exception when notify_fw is false. It happens when driver detects FW problems and is going to reset FW. Only in this case, driver needs to release bits outside rtw89_fw_h2c_del_pkt_offload(). 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://lore.kernel.org/r/8cf5d45c5b04e7b680d4eb9dda62056cdce14cec.camel@realtek.com
|
#
ac83f380 |
|
14-Apr-2023 |
Po-Hao Huang <phhuang@realtek.com> |
wifi: rtw89: update statistics to FW for fine-tuning performance Since firmware can't have proper statistics, driver update the statistics periodically to firmware to assist in tuning performance. 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://lore.kernel.org/r/20230415034900.15679-5-pkshih@realtek.com
|
#
8b048bd5 |
|
14-Apr-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: use struct instead of macros to set H2C command of hardware scan Remove macros that set H2C data. Instead, use struct and le32_encode_bits() with mask definition to make it clean. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230415034900.15679-4-pkshih@realtek.com
|
#
e7399db2 |
|
14-Apr-2023 |
Po-Hao Huang <phhuang@realtek.com> |
wifi: rtw89: refine scan function after chanctx Since we can get the current channel definition each interface maps to, remove store_op function that is no longer required to make things simple. 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://lore.kernel.org/r/20230415034900.15679-3-pkshih@realtek.com
|
#
c0fea064 |
|
11-Apr-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: coex: send more hardware module info to firmware for 8851B 8851B has various hardware module types, so BT coexistence in firmware needs these information to make decision. Add them to make 8851B work well. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230412012831.10519-5-pkshih@realtek.com
|
#
d5289b2d |
|
30-Mar-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: 8851b: fix TX path to path A for one RF path chip For two RF paths chips, we normally set path B as main path by default. 8851B has single one RF path, so set TX path to A and set mapping of path B to 0. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230330133324.19538-3-pkshih@realtek.com
|
#
ffde7f34 |
|
20-Mar-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: add firmware format version to backward compatible with older drivers In the discuss threads [1] [2], new firmware format break user space because older drivers can't recognize new firmware format. To avoid this, the new format will be named rtw89/rtw8852b_fw-1.bin and only new driver try to load it. Old drivers only load original and understandable firmware rtw89/rtw8852b_fw.bin. More, new driver will be still backward compatible with old firmware, so original firmware can be used by new driver. If there is newer firmware format is introduced, rtw89/rtw8852b_fw-2.bin will be given. The same rules will be applied like above. So, we will have firmware like below in linux-firmware in the future. rtw89/rtw8852b_fw-2.bin rtw89/rtw8852b_fw-1.bin rtw89/rtw8852b_fw.bin After this patch, MODULE_FIRMWARE() of 8852A/B/C become rtw89/rtw8852a_fw.bin rtw89/rtw8852b_fw-1.bin rtw89/rtw8852c_fw.bin [1] https://lore.kernel.org/linux-wireless/df1ce994-3368-a57e-7078-8bdcccf4a1fd@gmail.com/T/#m24cb43be31a762d0ea70bf07f27ae96c59f6931b [2] https://bugzilla.kernel.org/show_bug.cgi?id=217207 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230320130606.20777-4-pkshih@realtek.com
|
#
b80ad23a |
|
20-Mar-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: use schedule_work to request firmware Since we are going to load more than one firmware and some are not presented or optional, using asynchronous API request_firmware_nowait() will become complicated. Also, we want to use firmware_request_nowarn() to avoid warning messages when loading optional files. So, use schedule_work to be simpler. To abstract loading a firmware or file, define a struct rtw89_fw_req_info containing a struct firmware and a completion to ensure this firmware is loaded completely. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230320130606.20777-3-pkshih@realtek.com
|
#
639ec6d6 |
|
20-Mar-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: fw: use generic flow to set/check features In early feature bitmap obtained from rtw89_early_fw_feature_recognize(), the bits needed to check get increased. It's more friendly to work with RTW89_CHK_FW_FEATURE(). So, we concentrate the flow of iterating FW feature configures and calling RTW89_SET_FW_FEATURE() for various uses. And then, we adjust rtw89_early_fw_feature_recognize() for RTW89_CHK_FW_FEATURE(). 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://lore.kernel.org/r/20230320130606.20777-2-pkshih@realtek.com
|
#
c5280e5f |
|
11-Apr-2023 |
Po-Hao Huang <phhuang@realtek.com> |
wifi: rtw89: fix authentication fail during scan We used to store operating channel info after associated. However, scan might happen before that. Without switching back to operating channel, authentication or association might fail. Therefore, we switch back to operating channel when the scanning vif's BSSID is non-zero, which implies connected or during attempt to connect. 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://lore.kernel.org/r/20230411124832.14965-6-pkshih@realtek.com
|
#
d2b6da24 |
|
11-Apr-2023 |
Po-Hao Huang <phhuang@realtek.com> |
wifi: rtw89: 8852c: add beacon filter and CQM support Adding this supports beacon filter and connection quality monitor. To make host CPU wake up less, let firmware perform signal monitoring and beacon processing, then notify driver upon signal changes or beacon loss. This feature needs firmware 0.27.56 or newer to support it. 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://lore.kernel.org/r/20230411124832.14965-2-pkshih@realtek.com
|
#
e749ef96 |
|
16-Mar-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: add counters of register-based H2C/C2H The register-based H2C/C2H are used to exchange information between driver and firmware, but only apply to narrow area because its data size is smaller than regular packet-based H2C/C2H. This kind of H2C/C2H must be paired. To identify if any H2C/C2H is missing, update counters to help diagnose this kind of problems. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230316063956.71687-1-pkshih@realtek.com
|
#
a2c0ce5d |
|
07-Mar-2023 |
Ching-Te Ku <ku920601@realtek.com> |
wifi: rtw89: coex: Add traffic TX/RX info and its H2C There is a new mechanism which can do some real time performance tuning for WiFi and BT. This TX/RX info is a condition provide to firmware to do traffic analysis. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230308053225.24377-4-pkshih@realtek.com
|
#
5049964c |
|
07-Mar-2023 |
Ching-Te Ku <ku920601@realtek.com> |
wifi: rtw89: coex: Add WiFi role info v2 Remove WiFi traffic busy level & traffic rate from active role information. This information will move to v5 version TDMA cycle info. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230308053225.24377-3-pkshih@realtek.com
|
#
0d1f7ff1 |
|
20-Feb-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: refine FW feature judgement on packet drop The newer chips use the newer firmware branches, e.g. v027, v029. And, those firmware branches are supposed to support packet drop when they are just branched out. The initial firmware branch used by each chip is as below. * 8852A: v009 * 8852C: v027 * 8852B: v027 So, only 8852A may use firmware which doesn't support packet drop at runtime. To save trivial positive listing in firmware feature table, we change to reverse judgment. Besides, rtw89_mac_ptk_drop_by_band_and_wait() missed to check firmware feature before calling rtw89_fw_h2c_pkt_drop(). We also fix it. 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://lore.kernel.org/r/20230220070202.29868-7-pkshih@realtek.com
|
#
357277e1 |
|
20-Feb-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: 8852b: enable hw_scan support This enables hw_scan for 8852b after firmware version 0.29.29.0. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230220070202.29868-6-pkshih@realtek.com
|
#
31c416e6 |
|
20-Feb-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: fw: configure CRASH_TRIGGER feature for 8852B RTL8852B firmware supports CRASH_TRIGGER feature from v0.29.29.0. After this is configured, debugfs fw_crash can support type 1 on RTL8852B to trigger firmware crash and verify L2 recovery through simulation. 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://lore.kernel.org/r/20230220070202.29868-3-pkshih@realtek.com
|
#
aa4e0559 |
|
20-Feb-2023 |
Chin-Yen Lee <timlee@realtek.com> |
wifi: rtw89: add tx_wake notify for 8852B 8852B has the same issue: management frames get stuck when wifi chip enters low ps mode, so we alse add notify wake function to trigger wifi chip wake before forwarding management frames. 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://lore.kernel.org/r/20230220070202.29868-2-pkshih@realtek.com
|
#
c6aa9a9c |
|
17-Feb-2023 |
Po-Hao Huang <phhuang@realtek.com> |
wifi: rtw89: add RNR support for 6 GHz scan Since 6 GHz band has around 60 channels and more strict rules for active probing. Reduced neighbor report can be used to reduce the channels we scan and get specific target BSS info to probe for. Declare flag WIPHY_FLAG_SPLIT_SCAN_6GHZ so the scan request could be divided into two portions: legacy bands and 6 GHz bands. So RNR information from legacy bands could later be used when 6 GHz scan. When the scan flag NL80211_SCAN_FLAG_COLOCATED_6GHZ is set, cfg80211 will pass down a reduced channel set which contains PSCs and non-PSC with RNR info received in the 2 GHz/5 GHz band. This reduces the scan duration by allowing us to only scan for channels in which APs are currently operating. 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://lore.kernel.org/r/20230217120007.8835-1-pkshih@realtek.com
|
#
7410bd72 |
|
22-Jan-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: 8852b: try to use NORMAL_CE type firmware first New firmware type NORMAL_CE is introduced to support P2P-PS and hardware scan, but no LPS-PG mode. After this patch, old firmware with NORMAL type can still work well. The use of this new type is the same as before, so we add new type to avoid taking wrong firmware. Then, driver log can also give clear information about this change: rtw89_8852be 0000:03:00.0: Firmware version 0.29.26.0, cmd version 0, type 5 rtw89_8852be 0000:03:00.0: Firmware version 0.29.26.0, cmd version 0, type 3 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230123065401.14174-7-pkshih@realtek.com
|
#
e5624482 |
|
22-Jan-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: 8852b: don't support LPS-PG mode after firmware 0.29.26.0 Due to firmware size limit of 8852b, LPS-PG mode isn't supported after 0.29.26.0, and then we have more space to support other features, such as P2P-PS, hardware scan and so on. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230123065401.14174-6-pkshih@realtek.com
|
#
5c12bb66 |
|
22-Jan-2023 |
Chin-Yen Lee <timlee@realtek.com> |
wifi: rtw89: refine packet offload flow For upcoming firmware, driver needs to do packet offload to firmware to ensure LPS protocol work properly, so we update current connection and disconnect flow to maintain packet offload flow, and integrate with current WoWLAN flow which also needs packet offload. 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://lore.kernel.org/r/20230123065401.14174-3-pkshih@realtek.com
|
#
b8e8ff84 |
|
22-Jan-2023 |
Chin-Yen Lee <timlee@realtek.com> |
wifi: rtw89: fix potential wrong mapping for pkt-offload When driver fails to send H2C to firmware for pkt-offload, we should not update the pkt_list of driver, and need to release allocated pkt index to avoid wrong mapping between driver and firmware. 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://lore.kernel.org/r/20230123065401.14174-2-pkshih@realtek.com
|
#
72f8b046 |
|
06-Jan-2023 |
Ching-Te Ku <ku920601@realtek.com> |
wifi: rtw89: coex: Add version code for Wi-Fi firmware coexistence control The newer Wi-Fi firmware are all changed to "Not to send H2C to mention firmware how many call flow step should firmware trace". The structure had removed the member, and define the steps number at newer version firmware. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230106120844.17441-2-pkshih@realtek.com
|
#
4a0e218c |
|
03-Jan-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: fix potential leak in rtw89_append_probe_req_ie() Do `kfree_skb(new)` before `goto out` to prevent potential leak. Fixes: 895907779752 ("rtw89: 8852a: add ieee80211_ops::hw_scan") 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://lore.kernel.org/r/20230103141054.17372-1-pkshih@realtek.com
|
#
3f625adc |
|
03-Jan-2023 |
Ching-Te Ku <ku920601@realtek.com> |
wifi: rtw89: coex: Update WiFi role info H2C report Change style to feature version separate. And because there are different WiFi roles number in the firmware, it will make structure length longer or shorter, so update the length calculator to cover the difference. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230103140238.15601-8-pkshih@realtek.com
|
#
08c93c0c |
|
14-Dec-2022 |
Po-Hao Huang <phhuang@realtek.com> |
wifi: rtw89: refine 6 GHz scanning dwell time Reduce dwell time to improve scan duration in 6 GHz. This is required for scan requests that does not include RNR parsing and does full channel scan. 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://lore.kernel.org/r/20221214091952.42792-1-pkshih@realtek.com
|
#
6140635a |
|
17-Dec-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: coex: add BTC format version derived from firmware version Originally, each chip maintains its own format version followed firmware it uses. As new chip is added, firmware changes format of exchange messages to have rich information to handle more conditions. When old chip is going to upgrade firmware, it could use new format and driver needs to maintain compatibility with old firmware. So, add this version array to achieve this goal. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221217141745.43291-2-pkshih@realtek.com
|
#
18ddf102 |
|
08-Dec-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: adapt to new firmware format of security section Normally, system image should ensure firmware integrity, but we provide an advance feature to ensure this by security section along with firmware. To enable this feature, custom ID is programmed into efuse, and driver will download proper security section to firmware. Since I don't have this kind hardware modules on hand yet, but new format is used by newer firmware. Therefore, I prepare this patch in advance to consider size of security section as a factor of checking rule of firmware size, but don't actually download security section to firmware. This patch is backward compatible, so it will be safe to have this change before adding an new format firmware to linux-firmware repository. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221209012215.7342-1-pkshih@realtek.com
|
#
13eb07e0 |
|
01-Dec-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: request full firmware only once if it's early requested Under some condition, we now have to do early request full firmware when rtw89_early_fw_feature_recognize(). In this case, we can avoid requesting full firmware twice during probing driver. So, we pass out full firmware from rtw89_early_fw_feature_recognize() if it's requested successfully. And then, if firmware is settled, we have no need to request full firmware again during normal initizating flow. Setting firmware flow is updated to be as the following. platform | early recognizing | normally initizating ----------------------------------------------------------------------- deny reading | request full FW | (no more FW requesting) partial file | | (obtain FW from early pahse) ----------------------------------------------------------------------- able to read | request partial FW | async request full FW partial file | (quite small chunk) | 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://lore.kernel.org/r/20221202060521.501512-3-pkshih@realtek.com
|
#
3ddfe3bd |
|
01-Dec-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: don't request partial firmware if SECURITY_LOADPIN_ENFORCE Kernel logs on platform enabling SECURITY_LOADPIN_ENFORCE ------ ``` LoadPin: firmware old-api-denied obj=<unknown> pid=810 cmdline="modprobe -q -- rtw89_8852ce" rtw89_8852ce 0000:01:00.0: loading /lib/firmware/rtw89/rtw8852c_fw.bin failed with error -1 rtw89_8852ce 0000:01:00.0: Direct firmware load for rtw89/rtw8852c_fw.bin failed with error -1 rtw89_8852ce 0000:01:00.0: failed to early request firmware: -1 ``` Trace ------ ``` request_partial_firmware_into_buf() > _request_firmware() >> fw_get_filesystem_firmware() >>> kernel_read_file_from_path_initns() >>>> kernel_read_file() >>>>> security_kernel_read_file() // It will iterate enabled LSMs' hooks for kernel_read_file. // With loadpin, it hooks loadpin_read_file. ``` If SECURITY_LOADPIN_ENFORCE is enabled, doing kernel_read_file() on partial files will be denied and return -EPERM (-1). Then, the outer API based on it, e.g. request_partial_firmware_into_buf(), will get the error. In the case, we cannot get the firmware stuffs right, even though there might be no error other than a permission issue on reading a partial file. So we have to request full firmware if SECURITY_LOADPIN_ENFORCE is enabled. It makes us still have a chance to do early firmware work on this kind of platforms. 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://lore.kernel.org/r/20221202060521.501512-2-pkshih@realtek.com
|
#
c008c4b0 |
|
29-Nov-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: fw: implement MCC related H2C These MCC H2C(s) require to wait for MCC C2H to determine if the execution is successful. Through rtw89_wait_for_cond(), we make them wait for either a completion with data from MCC C2H handlers, which calls rtw89_complete_cond(), or timeout. 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://lore.kernel.org/r/20221129083130.45708-6-pkshih@realtek.com
|
#
860e8263 |
|
29-Nov-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: check if atomic before queuing c2h Before queuing C2H work, we check atomicity of the C2H's handler first now. If atomic or lock-free, handle it directly; otherwise, handle it with mutex in work as previous. This prepares for MAC MCC C2Hs which require to be processed directly. And, their handlers will be functions which can be considered atomic. 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://lore.kernel.org/r/20221129083130.45708-3-pkshih@realtek.com
|
#
38f25dec |
|
29-Nov-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: rfk: rename rtw89_mcc_info to rtw89_rfk_mcc_info The `rtw89_mcc_info mcc` is only for RFK MCC stuffs instead of common MCC management info. Replace it with `rtw89_rfk_mcc_info rfk_mcc` to avoid confusion and reserve `struct rtw89_mcc_info mcc` for MCC management code. (No logic changes.) 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://lore.kernel.org/r/20221129083130.45708-2-pkshih@realtek.com
|
#
d2b68e95 |
|
26-Oct-2022 |
Chin-Yen Lee <timlee@realtek.com> |
wifi: rtw89: add WoWLAN pattern match support Pattern match is an option of WoWLAN to allow the device to be woken up from suspend mode when receiving packets matched user-designed patterns. The patterns are written into hardware via WoWLAN firmware in suspend flow if users have set up them. If packets matched designed pattern are received, WoWLAN firmware will send an interrupt and then wake up the device. 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://lore.kernel.org/r/20221027052707.14605-8-pkshih@realtek.com
|
#
ee88d748 |
|
26-Oct-2022 |
Chin-Yen Lee <timlee@realtek.com> |
wifi: rtw89: add related H2C for WoWLAN mode In this patch we define some H2C, which will be called during suspend flow, to enable WoWLAN function provided by WoWLAN firmware. These H2C includes keep alive used to send null packet to AP periodically to avoid being disconnected by AP, disconnect detection used to configure how we check if AP is offline, wake up control used to decide which WiFi events could trigger resume flow, and global control used to enable WoWLAN function. 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://lore.kernel.org/r/20221027052707.14605-6-pkshih@realtek.com
|
#
41d56769 |
|
26-Oct-2022 |
Chih-Kang Chang <gary.chang@realtek.com> |
wifi: rtw89: add drop tx packet function When entering WoWLAN mode, we need to drop all transmit packets, including those in mac buffer, to avoid memory leakage, so implement the drop_tx function. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> 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://lore.kernel.org/r/20221027052707.14605-5-pkshih@realtek.com
|
#
5f05bdb0 |
|
26-Oct-2022 |
Chih-Kang Chang <gary.chang@realtek.com> |
wifi: rtw89: move enable_cpu/disable_cpu into fw_download For WoWLAN mode, we need to download WoWLAN firmware by calling fw_download(). Another, to disable/enable WiFi CPU is needed before calling fw_download. Since Firmware runs on WiFi CPU, it is intuitive to combine enable_cpu/disable_cpu functions into fw_download. 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://lore.kernel.org/r/20221027052707.14605-3-pkshih@realtek.com
|
#
4feda7f3 |
|
19-Oct-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: adapt to new firmware format of dynamic header Since firmware size is limited, we create variant firmwares for variant application areas. To help driver to know firmware's capabilities, firmware dynamic header is introduced to have more information, such as firmware features and firmware compile flags. Since this driver rtw89 only uses single one specific firmware at runtime, this patch is just to ignore this dynamic header, not actually use the content. This patch can be backward compatible, and no this kind of firmware is added to linux-firmware yet, so I can prepare this in advance. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221020052549.33783-1-pkshih@realtek.com
|
#
47813205 |
|
06-Oct-2022 |
Po-Hao Huang <phhuang@realtek.com> |
wifi: rtw89: fix wrong bandwidth settings after scan Set channel in driver side to configure Tx power and channel index correctly after scan. Before this, beacons with bandwidth larger than 20M bandwidth will be dropped by mac80211 due to frequency mismatch. 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://lore.kernel.org/r/20221007045900.10823-2-pkshih@realtek.com
|
#
54997c24 |
|
06-Oct-2022 |
Po-Hao Huang <phhuang@realtek.com> |
wifi: rtw89: correct 6 GHz scan behavior Change active scan behavior to fit 6GHz requirements. There are many different rules on active scan between 6GHz and 2GHz/5GHz, so if the SSID is not specified, do fast passive scanning and limit number of probe requests we send for now until new firmware can support all rules. 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://lore.kernel.org/r/20221007045900.10823-1-pkshih@realtek.com
|
#
f4a43c3b |
|
21-Sep-2022 |
Dian-Syuan Yang <dian_syuan0116@realtek.com> |
wifi: rtw89: support for processing P2P power saving Support P2P client to process Notice of Absence (NoA) mechanism when it connects with P2P GO applying an NoA schedule. We define some action types including init, update, remove and terminate in h2c function to enable/disable NoA schedule. Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220922010435.12167-6-pkshih@realtek.com
|
#
3788c599 |
|
21-Sep-2022 |
Dian-Syuan Yang <dian_syuan0116@realtek.com> |
wifi: rtw89: send OFDM rate only in P2P mode Check IEEE80211_TX_CTL_NO_CCK_RATE flag to avoid sending frames with CCK rates in 2GHz band. In TX flow, add IEEE80211_TX_CTL_NO_CCK_RATE flag to check and get its lowest rate without CCK rates if the TX type is mgmt frames or data frames. Besides, the decision of phy rate and retry rate in P2P mode are also be handled. In P2P GO mode, it should send beacon of no CCK rates in its frame rate. Therefore, We add a condition to decide which rate is added to beacon content. Moreover, we avoid setting a mask of rates to be used for rate control selection before and after connection in P2P mode. Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220922010435.12167-3-pkshih@realtek.com
|
#
4c3140f4 |
|
15-Sep-2022 |
Dan Carpenter <dan.carpenter@oracle.com> |
wifi: rtw89: uninitialized variable on error in rtw89_early_fw_feature_recognize() If request_partial_firmware_into_buf() fails then "firmware" is not initialized and the release_firmware(firmware) will crash. Fixes: deebea35d699 ("wifi: rtw89: early recognize FW feature to decide if chanctx") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/YyMzDtX/3fUBnonC@kili
|
#
812825c2 |
|
15-Sep-2022 |
Po-Hao Huang <phhuang@realtek.com> |
wifi: rtw89: fix rx filter after scan In monitor mode we should be able to received all packets even if it's not destined to us. But after scan, the configuration was wrongly set, so we fix it. 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://lore.kernel.org/r/20220916033811.13862-7-pkshih@realtek.com
|
#
e77d3f8b |
|
13-Sep-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: 8852c: support fw crash simulation With FW >= v0.27.40.0, 8852C FW has feature to handle crash simulation. Besides, use RTW89_WCPU_BASE_MASK to replace use of RTW89_WCPU_BASE_ADDR and work for both 8852A and 8852C. 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://lore.kernel.org/r/20220914035034.14521-4-pkshih@realtek.com
|
#
9a785583f |
|
13-Sep-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: introudce functions to drop packets Introudce a H2C feature to drop packets according to given parameters. And, we implement instances to drop packets from BE, BK, VI, VO queues by vif or sta. Then, we refine our callback of ieee80211_ops::flush to deal with the case of drop=true via this feature. 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://lore.kernel.org/r/20220914035034.14521-3-pkshih@realtek.com
|
#
8b0f4b5d |
|
13-Sep-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: unify use of rtw89_h2c_tx() Seaprate calling of rtw89_h2c_tx() out of if-expression, and bypass the return value to upper caller. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220914035034.14521-2-pkshih@realtek.com
|
#
0891b366 |
|
12-Sep-2022 |
Kuan-Chung Chen <damon.chen@realtek.com> |
wifi: rtw89: support for setting HE GI and LTF Support setting HE GI and LTF values to the kernel via nl80211. We currently only support some GI and LTF values settings. The command example is: iw wlan0 set bitrates he-gi-2.4 0.8 he-ltf-2.4 2 Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220912070014.10018-2-pkshih@realtek.com
|
#
c918f5f4 |
|
13-Sep-2022 |
Ching-Te Ku <ku920601@realtek.com> |
wifi: rtw89: coex: Remove trace_step at COEX-MECH control structure for RTL8852C RTL8852C don't need to send the data trace_step which used to tell firmware how many TDMA steps should record. Remove the member. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220913092546.43722-7-pkshih@realtek.com
|
#
bd1056d4 |
|
07-Sep-2022 |
Po-Hao Huang <phhuang@realtek.com> |
wifi: rtw89: split scan including lots of channels The size limit of H2C commands is 2048. With regulatory that enables U-NII-6 ~ UNII-8 channels, channel list length combining with channel info length will exceed that. Split the channel list to parts and do scan multiple times to workaround that. 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://lore.kernel.org/r/20220908051257.25353-10-pkshih@realtek.com
|
#
3a1e7cb1 |
|
07-Sep-2022 |
Po-Hao Huang <phhuang@realtek.com> |
wifi: rtw89: 8852c: support hw_scan This enables hw_scan function for 52c. The mechanism is similar to 52a except that it adds modifications required for 6G channels and extends the command length to make driver compatible to both newer and existing 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://lore.kernel.org/r/20220908051257.25353-9-pkshih@realtek.com
|
#
5abbb68a |
|
07-Sep-2022 |
Chin-Yen Lee <timlee@realtek.com> |
wifi: rtw89: call tx_wake notify for 8852c in deep ps mode 8852c transmits packets with slow response in deep ps mode, and lead to low throughput. We need to call tx_wake for each pakcet to trigger firmware wake earlier to avoid 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://lore.kernel.org/r/20220908051257.25353-8-pkshih@realtek.com
|
#
183c8eff |
|
07-Sep-2022 |
Chin-Yen Lee <timlee@realtek.com> |
wifi: rtw89: support deep ps mode for rtw8852c rtw8852c could support deep ps mode if the firmware version is greater than 0.17.34. 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://lore.kernel.org/r/20220908051257.25353-7-pkshih@realtek.com
|
#
5a8e06e4 |
|
08-Sep-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: configure TX path via H2C command In order to support TX diversity, add a function to control TX path. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220908074140.39776-4-pkshih@realtek.com
|
#
8b1b4730 |
|
15-Aug-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: 8852c: initialize and correct BA CAM content The bacam_v1 must do additional initialization, and H2C content of BA CAM is also different. So, correct them accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220816013247.6243-3-pkshih@realtek.com
|
#
2def7356 |
|
15-Aug-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: 8852c: declare correct BA CAM number 8852A has 2 BA CAM entries, but 8852C has 8 entries. Add a field to discriminate their differences. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220816013247.6243-2-pkshih@realtek.com
|
#
e390cf2e |
|
24-Jul-2022 |
Ching-Te Ku <ku920601@realtek.com> |
rtw89: coex: update WL role info v1 for RTL8852C branch using The H2C format and support feature are different. The newer Wi-Fi firmware and driver branch need to handshake more information like DBCC or P2P connection info. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220725023509.43114-7-pkshih@realtek.com
|
#
deebea35 |
|
09-Aug-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: early recognize FW feature to decide if chanctx In current flow, FW is asynchronously loaded after alloc_hw(). It defers the decision on FW feature map. It makes things difficult for us to decide whether to hook chanctx ops, which should be decided while alloc_hw() is calling. Still, asynchronous gets its advantages. So, we want to resolve this without dropping them. Based on multi-FW flag, RTW89_MFW_SIG, we can determine runtime FW is multi-FW (MFW) or single FW (SFW). Both of them have a quite small chunk for header at the head. The difference is that MFW doesn't describe version code in its header while SFW does. So, we plan to extend MFW header for version code. After that, in both cases, we can determine FW feature map by just FW header. And, according to the map, we can decide chanctx. So, we call request_partial_firmware_into_buf() to request a quite small chunk before alloc_hw() to get a early FW feature map without affecting things much and only use early map to decide whether to hook chanctx ops. It means that if non-extended MFW is used at runtime, driver just acts without chanctx as before. If extended MFW or SFW, which supports required FW features, is used at runtime, driver can hook chanctx ops to mac80211 if chip has configured support_chanctx_num > 0. Besides, key point for now to support single one chanctx is whether HW scan is supported at runtime. So, we configure all chip's support_chanctx_num to 1, and check if HW scan is supported at runtime via early FW feature map. 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://lore.kernel.org/r/20220809104952.61355-14-pkshih@realtek.com
|
#
bb8152b3 |
|
09-Aug-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: create rtw89_chan centrally to avoid breakage Sometimes we need to write current rtw89_chan outside set_channel(), e.g. during HW scan, we adjust it to align FW process through C2H. However, we don't have full parameters to fill entire rtw89_chan. And it will breakage if we update only part of current rtw89_chan. That is what we don't want to see because most flows throughout driver treat rtw89_chan as a whole. So, we divide struct rtw89_chan to basic part and derived part. The basic part contains the parameters which we are always able to know. And the derived part will be calculated by the basic part. Then, a central function, rtw89_chan_create(), is added to deal with this. 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://lore.kernel.org/r/20220809104952.61355-5-pkshih@realtek.com
|
#
cbb145b9 |
|
09-Aug-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: re-arrange channel related stuffs under HAL We are planning to support mac80211 chanctx. To reduce future works, the driver architecture is adjusted first to isolate related things. According to chip, our HW may have multiple sub-entities to support multiple mac80211 chanctx. Struct rtw89_chan has been introduced for things about channel/band/subband/... Now introduce struct rtw89_chan_rcd to record difference after assigning new one of struct rtw89_chan. We will implement and support chanctx with single channel first, i.e. only use entry in RTW89_SUB_ENTITY_0, before handling dual channels. Our hierarchy in planning will become as the following. DEV -> HAL ---> entity (manage status across sub-entities) -----> sub-entity[*] (support mac80211 chanctx) where each sub-entity contains one struct rtw89_chan. 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://lore.kernel.org/r/20220809104952.61355-4-pkshih@realtek.com
|
#
39913cc8 |
|
10-Jun-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: allocate BSSID CAM per TDLS peer In STA mode, if peer is TDLS. Allocate a BSSID CAM entry with peer's address to match address properly, and then hardware can ACK peer's packets and receive packets to driver. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220610072610.27095-4-pkshih@realtek.com
|
#
6e8912a5 |
|
06-Jun-2022 |
Shaul Triebitz <shaul.triebitz@intel.com> |
wifi: mac80211: return a beacon for a specific link Pass the link id through to the get_beacon and return the beacon for a specific link id. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
6d7d1fef |
|
20-May-2022 |
Po Hao Huang <phhuang@realtek.com> |
rtw89: fix null vif pointer when hw_scan fails Add this check to avoid crash by dereferencing a null pointer. When hwscan fails due to no memory or dma failure, the scan flag in ieee80211_local is cleared. So mac80211 determine that it's not hw_scan then calls sw_scan_complete() with null vif, which is also freed during the fail. 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://lore.kernel.org/r/20220520071731.38563-3-pkshih@realtek.com
|
#
28000f7b |
|
20-May-2022 |
Po Hao Huang <phhuang@realtek.com> |
rtw89: fix channel inconsistency during hw_scan Previously channel maintained by driver could be different from the ones hardware actually is. Restore these variables back to prevent unexpected behavior. 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://lore.kernel.org/r/20220520071731.38563-2-pkshih@realtek.com
|
#
a06d2dd7 |
|
15-May-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
rtw89: convert rtw89_band to nl80211_band precisely Before 6 GHz band was supported, i.e. only 2 GHz and 5 GHz, they were the same from the numerical point of view. However, after 6 GHz band support, we need to do this conversion logically. 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://lore.kernel.org/r/20220516005215.5878-6-pkshih@realtek.com
|
#
16b44ed0 |
|
21-Apr-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: add RF H2C to notify firmware IQK results in hardware has two copies that are used by firmware to switch these two to support MCC. This H2C tell firmware the corresponding channel and band of each IQK results, and currrent one. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220421120903.73715-10-pkshih@realtek.com
|
#
04b5983e |
|
12-Apr-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: add new H2C to configure security CAM via DCTL for V1 chip DCTL is short for D-MAC control that V1 chip uses this H2C to configure security CAM. Implement the callers in next patch. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220413010804.8941-3-pkshih@realtek.com
|
#
aa7f148b |
|
12-Apr-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: extend H2C of CMAC control info In order to support new chip that has capability of 160M, we need new format to fill new information, so add a new V1 ID for newer use. Since most fields are the same, fill fields according to the function ID of chip. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220413010804.8941-2-pkshih@realtek.com
|
#
046d2e7c |
|
04-Apr-2022 |
Sriram R <quic_srirrama@quicinc.com> |
mac80211: prepare sta handling for MLO support Currently in mac80211 each STA object is represented using sta_info datastructure with the associated STA specific information and drivers access ieee80211_sta part of it. With MLO (Multi Link Operation) support being added in 802.11be standard, though the association is logically with a single Multi Link capable STA, at the physical level communication can happen via different advertised links (uniquely identified by Channel, operating class, BSSID) and hence the need to handle multiple link STA parameters within a composite sta_info object called the MLD STA. The different link STA part of MLD STA are identified using the link address which can be same or different as the MLD STA address and unique link id based on the link vif. To support extension of such a model, the sta_info datastructure is modified to hold multiple link STA objects with link specific params currently within sta_info moved to this new structure. Similarly this is done for ieee80211_sta as well which will be accessed within mac80211 as well as by drivers, hence trivial driver changes are expected to support this. For current non MLO supported drivers, only one link STA is present and link information is accessed via 'deflink' member. For MLO drivers, we still need to define the APIs etc. to get the correct link ID and access the correct part of the station info. Currently in mac80211, all link STA info are accessed directly via deflink. These will be updated to access via link pointers indexed by link id with MLO support patches, with link id being 0 for non MLO supported cases. Except for couple of macro related changes, below spatch takes care of updating mac80211 and driver code to access to the link STA info via deflink. @ieee80211_sta@ struct ieee80211_sta *s; struct sta_info *si; identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr}; @@ ( s-> - var + deflink.var | si->sta. - var + deflink.var ) @sta_info@ struct sta_info *si; identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth}; @@ ( si-> - var + deflink.var ) Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com [remove MLO-drivers notes from commit message, not clear yet; run spatch] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
65ee4971 |
|
31-Mar-2022 |
Po Hao Huang <phhuang@realtek.com> |
rtw89: fix misconfiguration on hw_scan channel time Without this patch, hw scan won't stay long enough on DFS/passive channels. Found previous logic error and fix it. 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://lore.kernel.org/r/20220401055043.12512-5-pkshih@realtek.com
|
#
a95bd62e |
|
17-Mar-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: add chip_info::h2c_desc_size/fill_txdesc_fwcmd to support new chips 8852A and 8852C use different H2C header and size, so add h2c_desc_size to allocate different header size and fill content by fill_txdesc_fwcmd. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220318023214.32411-8-pkshih@realtek.com
|
#
edb89629 |
|
14-Mar-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
rtw89: support FW crash simulation Originally, there is already a mechanism, SER (system error recover), to deal with HW/FW recovery. After FW v0.13.36.0, FW supports a H2C (host to chip) command to make a CPU exception. Then, SER is supposed to catch this FW crash and do L2 reset. This feature is a simulation to verify if flow of recovering from FW crash works. Usage of fw_crash debugfs is as the following. $ echo 1 > fw_crash // trigger FW crash and wait SER handling $ cat fw_crash // return 0 if restart has been done 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://lore.kernel.org/r/20220314071250.40292-9-pkshih@realtek.com
|
#
11fe4ccd |
|
14-Mar-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
rtw89: reconstruct fw feature As the fw features gradually increase, it would be better that we have a set of methods to maintain fw features instead of using scattered bool variables. We reconstruct the way fw recognize features, and introduce RTW89_CHK_FW_FEATURE() / RTW89_SET_FW_FEATURE() to check / set fw features for uses. 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://lore.kernel.org/r/20220314071250.40292-8-pkshih@realtek.com
|
#
d179c1f1 |
|
10-Mar-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: fix uninitialized variable of rtw89_append_probe_req_ie() smatch reports that: fw.c:1997 rtw89_append_probe_req_ie() error: uninitialized symbol 'ret'. This can be a issue only if no band is supported by the chip, but it is impossible. So, it is still safe without this patch. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220311020007.20414-1-pkshih@realtek.com
|
#
e8955811 |
|
06-Mar-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: add chip_info::{h2c,c2h}_reg to support more chips This is a register-based H2C/C2H interface to exchange data with firmware. Since the register addresses of 8852A and 8852C are different, add fields to chip_info to support this. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220307060457.56789-9-pkshih@realtek.com
|
#
7bfd05ff |
|
24-Feb-2022 |
Chin-Yen Lee <timlee@realtek.com> |
rtw89: add tx_wake notify for low ps mode We found management frames get stuck when wifi chip enters low ps mode. So we add one notify wake function to trigger wifi chip into normal mode before forwarding management frames. 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://lore.kernel.org/r/20220225030851.13327-3-pkshih@realtek.com
|
#
89590777 |
|
24-Feb-2022 |
Po Hao Huang <phhuang@realtek.com> |
rtw89: 8852a: add ieee80211_ops::hw_scan Declare this function allows us to use customized scanning policy, so each scan takes less time. This is a similar implementation to hw_scan in rtw88, except that we offload more items to firmware and extend the maximum IE length. For backward compatibility, we fallback to sw_scan when firmware does not support this feature. 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://lore.kernel.org/r/20220225030851.13327-2-pkshih@realtek.com
|
#
ff66964a |
|
06-Feb-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: extend role_maintain to support AP mode Fill mac_id and self_role depends on the operation mode. In AP mode, echo connected station has an unique mac_id, and each vif also has one mac_id to represent itself. The self_role is assigned to vif if the operation mode is decided, and RTW89_SELF_ROLE_AP_CLIENT is assigned to the connected STA in AP mode, Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220207063900.43643-2-pkshih@realtek.com
|
#
8b252070 |
|
06-Jan-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: rename vif_maintain to role_maintain The H2C_FUNC_MAC_FWROLE_MAINTAIN also maintains the roles of all connected stations; not just the role of VIF. So, I correct the name, but don't change the logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220107034239.22002-9-pkshih@realtek.com
|
#
742c470b |
|
06-Jan-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: extend firmware commands on states of sta_assoc and sta_disconnect The h2c_join firmware command is used to indicate a station is connected, and the assoc_cmac_tbl firmware command is used to set CMAC table corresponding to a mac_id. Both commands must work in both station and AP modes. Use the mac_id of rtw89_sta naturally and intuitively. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220107034239.22002-8-pkshih@realtek.com
|
#
f7e76d13 |
|
06-Jan-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: download beacon content to firmware Firmware sends out beacon content generated by mac80211, and then stations can receive beacon and work with this AP properly. Also, we download beacon content again if TIM is changed. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220107034239.22002-4-pkshih@realtek.com
|
#
3ffbb5a8 |
|
03-Jan-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: correct use of BA CAM BA CAM is used to ACK peer's packets, so it must be established when IEEE80211_AMPDU_RX_START, and free it by IEEE80211_AMPDU_RX_STOP. The hardware can support two static BA CAM entries, so I implement a bitmap and a struct to record which entry is used and its corresponding tid. Also, the hardware can learn and create dynamic BA CAM entries automatically if received packets don't match static BA CAM. That means it can still work if we don't use H2C to set static BA CAM. An exception is tid=0 should be always allocated in static BA CAM, so an existing static BA CAM will be replaced if it is full and peer is going to establish a BA with tid=0. The new firmware use new format of this H2C, so I upgrade it as well. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220104012052.6911-1-pkshih@realtek.com
|
#
20d9fc88 |
|
27-Dec-2021 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: remove duplicate definition of hardware port number RTW89_MAX_HW_PORT_NUM and RTW89_PORT_NUM refer to the same thing, so remove the one of them. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211227083134.35248-1-pkshih@realtek.com
|
#
40822e07 |
|
01-Dec-2021 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: fix sending wrong rtwsta->mac_id to firmware to fill address CAM With wrong rtwsta->mac_id, it can't send out ack properly when we receive assoc response occasionally. Then, it failed to connect an AP. The cause is that we store 'sta' and use it somewhere. To correct this, remove the variable and use mac_id in drv_priv of 'sta' or 'vif' passed by mac80211. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211201080607.11211-1-pkshih@realtek.com
|
#
e45a9e62 |
|
10-Nov-2021 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: update scan_mac_addr during scanning period Update scan_mac_addr to address CAM as A1, so hardware can ACK probe response properly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211111023706.14154-2-pkshih@realtek.com
|
#
75c5bd68 |
|
26-Nov-2021 |
Miri Korenblit <miriam.rachel.korenblit@intel.com> |
ieee80211: change HE nominal packet padding value defines It's easier to use and understand, and to extend for EHT later, if we use the values here instead of the shifted values. Unfortunately, we need to add _POS so that we can use it in places like iwlwifi/mvm where constants are needed. While at it, fix the typo ("NOMIMAL") which also helps catch any conflicts. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://lore.kernel.org/r/20211126104817.7c29a05b8eb5.I2ca9faf06e177e3035bec91e2ae53c2f91d41774@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
#
5737b451 |
|
18-Nov-2021 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: update partition size of firmware header on skb->data The partition size is used to tell hardware the size of piece we are going to send a firmware. The old code updates the size in constant buffer of firmware, and leads system crash. To fix this, update the size on skb->data after we copy the firmware data into skb. Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1188303 Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver") Reported-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Takashi Iwai <tiwai@suse.de> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211119054512.10620-2-pkshih@realtek.com
|
#
e3ec7017 |
|
11-Oct-2021 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: add Realtek 802.11ax driver This driver named rtw89, which is the next generation of rtw88, supports Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC, Spatial reuse, TWT and BSS coloring; now some of them aren't implemented though. The chip architecture is entirely different from the chips supported by rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges are totally redefined, so it's impossible to reuse register definition. To communicate with firmware, new H2C/C2H format is proposed. In order to have better utilization, TX DMA flow is changed to two stages DMA. To provide rich RX status information, additional RX PPDU packets are added. Since there are so many differences mentioned above, we decide to propose a new driver. It has many authors, they are listed in alphabetic order: Chin-Yen Lee <timlee@realtek.com> Ping-Ke Shih <pkshih@realtek.com> Po Hao Huang <phhuang@realtek.com> Tzu-En Huang <tehuang@realtek.com> Vincent Fann <vincent_fann@realtek.com> Yan-Hsuan Chuang <tony0620emma@gmail.com> Zong-Zhe Yang <kevin_yang@realtek.com> Tested-by: Aaron Ma <aaron.ma@canonical.com> Tested-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
|