Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48 |
|
#
60168f6c |
| 22-Aug-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: mac: generalize code to indirectly access WiFi internal memory
To diagnose abnormal behavior, we need to dump certain internal memory. For example, dump security CAM when debugging encr
wifi: rtw89: mac: generalize code to indirectly access WiFi internal memory
To diagnose abnormal behavior, we need to dump certain internal memory. For example, dump security CAM when debugging encryption/decryption problems, or dump BA CAM when debugging abnormal BlockAck.
Since the indirect address and internal memory base address are different between WiFi 6 and 7 chips, add fields to reuse codes.
Also, only WiFi 6 chips initialize DMAC and CMAC tables via this indirect interface, so no need to change the constant register address, and new firmware will help to initialize these tables.
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-3-pkshih@realtek.com
show more ...
|
Revision tags: v6.1.46 |
|
#
bfbadacf |
| 16-Aug-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: sar: let caller decide the center frequency to query
If multiple channels, SAR will be hard to determine the center frequency to query. Therefore, we move this decision out of SAR.
Sig
wifi: rtw89: sar: let caller decide the center frequency to query
If multiple channels, SAR will be hard to determine the center frequency to query. Therefore, we move this decision out of SAR.
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-4-pkshih@realtek.com
show more ...
|
Revision tags: v6.1.45, v6.1.44 |
|
#
eb2624f5 |
| 04-Aug-2023 |
Kuan-Chung Chen <damon.chen@realtek.com> |
wifi: rtw89: Introduce Time Averaged SAR (TAS) feature
Time Averaged SAR (TAS) tracks the amount of transmit power over a period of time and adjusts the power accordingly. Two thresholds are used to
wifi: rtw89: Introduce Time Averaged SAR (TAS) feature
Time Averaged SAR (TAS) tracks the amount of transmit power over a period of time and adjusts the power accordingly. Two thresholds are used to determine when to increase or reduce transmit power: Dynamic Power Reduction (DPR) on/off. Compared to Static SAR, which has a constant transmit power, TAS can improve the user experience or range extension.
TAS can be enabled through BIOS, and the driver will evaluate Realtek ACPI DSM with RTW89_ACPI_DSM_FUNC_TAS_EN to determine whether TAS should be enabled.
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/20230804053458.31492-1-pkshih@realtek.com
show more ...
|
Revision tags: v6.1.43 |
|
#
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 form
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
show more ...
|
#
ae775faa |
| 28-Jul-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: add to display hardware rates v1 histogram in debugfs
The upcoming WiFi 7 chips support EHT rates, and hardware rate codes are changed too, so modify to adapt the changes. (EHT counters
wifi: rtw89: add to display hardware rates v1 histogram in debugfs
The upcoming WiFi 7 chips support EHT rates, and hardware rate codes are changed too, so modify to adapt the changes. (EHT counters are still zeros in below example)
RX count: Legacy: [0, 0, 0, 0] OFDM: [0, 0, 0, 0, 0, 0, 0, 0] HT 0: [0, 0, 0, 0, 0, 0, 0, 0] HT 1: [0, 0, 0, 0, 0, 0, 0, 0] VHT 1SS: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0][0, 0] VHT 2SS: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0][0, 0] HE 1SS: [0, 0, 42, 0, 43, 90, 75, 0, 26, 20, 260, 7] HE 2SS: [0, 96, 232, 84, 125, 184, 52, 0, 0, 0, 0, 0] EHT 1SS: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0][0, 0] EHT 2SS: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
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-10-pkshih@realtek.com
show more ...
|
Revision tags: v6.1.42, v6.1.41, v6.1.40, v6.1.39 |
|
#
59b4cc43 |
| 15-Jul-2023 |
Zhang Shurong <zhang_shurong@foxmail.com> |
wifi: rtw89: debug: Fix error handling in rtw89_debug_priv_btc_manual_set()
If there is a failure during kstrtobool_from_user() rtw89_debug_priv_btc_manual_set should return a negative error code in
wifi: rtw89: debug: Fix error handling in rtw89_debug_priv_btc_manual_set()
If there is a failure during kstrtobool_from_user() rtw89_debug_priv_btc_manual_set should return a negative error code instead of returning the count directly.
Fix this bug by returning an error code instead of a count after a failed call of the function "kstrtobool_from_user". Moreover I omitted the label "out" with this source code correction.
Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver") Signed-off-by: Zhang Shurong <zhang_shurong@foxmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/tencent_1C09B99BD7DA9CAD18B00C8F0F050F540607@qq.com
show more ...
|
#
4f4626cd |
| 05-Jul-2023 |
Zhang Shurong <zhang_shurong@foxmail.com> |
wifi: rtw89: debug: fix error code in rtw89_debug_priv_send_h2c_set()
If there is a failure during rtw89_fw_h2c_raw() rtw89_debug_priv_send_h2c should return negative error code instead of a positiv
wifi: rtw89: debug: fix error code in rtw89_debug_priv_send_h2c_set()
If there is a failure during rtw89_fw_h2c_raw() rtw89_debug_priv_send_h2c should return negative error code instead of a positive value count. Fix this bug by returning correct error code.
Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver") Signed-off-by: Zhang Shurong <zhang_shurong@foxmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://lore.kernel.org/r/tencent_AD09A61BC4DA92AD1EB0790F5C850E544D07@qq.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
Revision tags: v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32 |
|
#
b25e755e |
| 31-May-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: debug: txpwr table access only valid page according to chip
We now support RTL8851B which has only single RF path. For chip with single RF path, TX power page is valid only in single pa
wifi: rtw89: debug: txpwr table access only valid page according to chip
We now support RTL8851B which has only single RF path. For chip with single RF path, TX power page is valid only in single path section. So, we refine debugfs txpwr table to access TX power page according to RF path number of runtime chip. It can prevent us from reading beyond valid sections.
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-3-pkshih@realtek.com
show more ...
|
Revision tags: v6.1.31, v6.1.30 |
|
#
4cfad52a |
| 18-May-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: enlarge supported length of read_reg debugfs entry
The register ranges of upcoming chips are different from current, and even existing chips have different ranges, so support longer len
wifi: rtw89: enlarge supported length of read_reg debugfs entry
The register ranges of upcoming chips are different from current, and even existing chips have different ranges, so support longer length to dump registers. Then, user space can decide the ranges according to chip.
Since arbitrary length (e.g. 7) would be a little complicated, so simply make length a multiple of 16. The output looks like
18620000h : 8580801f 82828282 82828282 080800fd
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-6-pkshih@realtek.com
show more ...
|
Revision tags: v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25 |
|
#
4bb223a1 |
| 17-Apr-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: add EVM and SNR statistics to debugfs
To help debug performance problem, add EVM and SNR statistics to debugfs that shows
EVM: [(26.75, 26.75) (25.75, 25.75)] SNR: 40
Signed-off-
wifi: rtw89: add EVM and SNR statistics to debugfs
To help debug performance problem, add EVM and SNR statistics to debugfs that shows
EVM: [(26.75, 26.75) (25.75, 25.75)] SNR: 40
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230418012820.5139-5-pkshih@realtek.com
show more ...
|
#
f6b24241 |
| 17-Apr-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: add RSSI statistics for the case of antenna diversity to debugfs
RSSI strength is only from PHY path A, but there are two antenna for the module which supports antenna diversity. So, se
wifi: rtw89: add RSSI statistics for the case of antenna diversity to debugfs
RSSI strength is only from PHY path A, but there are two antenna for the module which supports antenna diversity. So, set RSSI value to index 1 of RSSI array if current antenna is on antenna B. Then, debugfs can show two RSSI values with a asterisk mark on selected antenna.
RSSI: -23 dBm (raw=174, prev=173) [-26, -23*]
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230418012820.5139-4-pkshih@realtek.com
show more ...
|
#
eaddda24 |
| 14-Apr-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: mac: use regular int as return type of DLE buffer request
The function to request DLE (data link engine) buffer uses 'u16' as return value that mixes error code, so change it to 'int' a
wifi: rtw89: mac: use regular int as return type of DLE buffer request
The function to request DLE (data link engine) buffer uses 'u16' as return value that mixes error code, so change it to 'int' as regular error code. Also, treat invalid register value (0xfff) as an error.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230414082228.30766-1-pkshih@realtek.com
show more ...
|
Revision tags: v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8 |
|
#
5da5ba7e |
| 23-Jan-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: add use of pkt_list offload to debug entry
Driver can prepare pkt_list for firmware that only uses them to send out the packets in specific situations. To understand the usage of curren
wifi: rtw89: add use of pkt_list offload to debug entry
Driver can prepare pkt_list for firmware that only uses them to send out the packets in specific situations. To understand the usage of current status, and to check if there is leakage problem, dump bitmap and the indices used by certain function.
An example looks like:
map: ... pkt_ofld: 3f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... [SCAN 0]: 3 [SCAN 1]: 4 [SCAN 3]: 5 VIF [0] xx:xx:xx:xx:xx:xx ... pkt_ofld[GENERAL]: 0 1 2
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-4-pkshih@realtek.com
show more ...
|
#
c074da21 |
| 19-Jan-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: debug: avoid invalid access on RTW89_DBG_SEL_MAC_30
Only 8852C chip has valid pages on RTW89_DBG_SEL_MAC_30. To other chips, this section is an address hole. It will lead to crash if tr
wifi: rtw89: debug: avoid invalid access on RTW89_DBG_SEL_MAC_30
Only 8852C chip has valid pages on RTW89_DBG_SEL_MAC_30. To other chips, this section is an address hole. It will lead to crash if trying to access this section on chips except for 8852C. So, we avoid that.
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/20230119063529.61563-2-pkshih@realtek.com
show more ...
|
Revision tags: v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77 |
|
#
f7333fc2 |
| 01-Nov-2022 |
Chia-Yuan Li <leo.li@realtek.com> |
wifi: rtw89: update D-MAC and C-MAC dump to diagnose SER
To detect TX or RX stuck, we implement SER (system error recovery) in firmware to recover abnormal states of hardware, and report events to d
wifi: rtw89: update D-MAC and C-MAC dump to diagnose SER
To detect TX or RX stuck, we implement SER (system error recovery) in firmware to recover abnormal states of hardware, and report events to driver. This kind of events could happen rarely per day.
SER might be true-positive or false-negative cases, and it could be failed to recover true-positive case. We dump related registers to kernel message at that moment and collect them from users, because they occur rarely, randomly and hard to make sure we reproduce the same symptom. To address problems accurately, add more registers by this patch.
It also might be false-positive cases that looks like TX or RX get stuck, we need to dump registers from debugfs manually, so also add similar things to debugfs as well.
Signed-off-by: Chia-Yuan Li <leo.li@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/20221102014300.14091-3-pkshih@realtek.com
show more ...
|
#
d6197c91 |
| 01-Nov-2022 |
Chia-Yuan Li <leo.li@realtek.com> |
wifi: rtw89: dump dispatch status via debug port
Dispatch is a component to decide packets forward to host, DMAC or HAXIDMA. It contains CDT standing for CPU dispatcher, HDT standing for host dispat
wifi: rtw89: dump dispatch status via debug port
Dispatch is a component to decide packets forward to host, DMAC or HAXIDMA. It contains CDT standing for CPU dispatcher, HDT standing for host dispatcher, WDE standing for descriptor engine and PLE standing for payload engine. STF is one kind of modes, it can be used if packet send to hardware and doesn't need release report.
These debug port information can help to clarify the reason if packets stuck in dispatch.
Signed-off-by: Chia-Yuan Li <leo.li@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/20221102014300.14091-2-pkshih@realtek.com
show more ...
|
Revision tags: v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3 |
|
#
25f49617 |
| 21-Oct-2022 |
Eric Huang <echuang@realtek.com> |
wifi: rtw89: add BW info for both TX and RX in phy_info
In order to debug performance issue intuitively, add bandwidth information into debugfs entry phy_info. After applying this patch, it looks li
wifi: rtw89: add BW info for both TX and RX in phy_info
In order to debug performance issue intuitively, add bandwidth information into debugfs entry phy_info. After applying this patch, it looks like:
TX rate [0]: HE 2SS MCS-11 GI:0.8 BW:80 (hw_rate=0x19b) ==> agg_wait=1 (3500) RX rate [0]: HE 2SS MCS-9 GI:0.8 BW:80 (hw_rate=0x199)
Signed-off-by: Eric Huang <echuang@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/20221021091601.39884-1-pkshih@realtek.com
show more ...
|
Revision tags: v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0 |
|
#
732dd91d |
| 30-Sep-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: add to dump TX FIFO 0/1 for 8852C
MAC maintains TX FIFO to transmit packets with meta data to BB layer. To debug abnormal transmission, we need to dump the content to dig problem. Since
wifi: rtw89: add to dump TX FIFO 0/1 for 8852C
MAC maintains TX FIFO to transmit packets with meta data to BB layer. To debug abnormal transmission, we need to dump the content to dig problem. Since FIFO of 8852C locates on different address with different size and need additional switch to enable read operation, this patch adds the changes accordingly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220930134417.10282-2-pkshih@realtek.com
show more ...
|
Revision tags: v5.15.71 |
|
#
b9021616 |
| 28-Sep-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: debug: txpwr_table considers sign
Previously, value of each field is just shown as unsigned. Now, we start to show them with sign to make things more intuitive during debugging.
Signed
wifi: rtw89: debug: txpwr_table considers sign
Previously, value of each field is just shown as unsigned. Now, we start to show them with sign to make things more intuitive during debugging.
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/20220928084336.34981-6-pkshih@realtek.com
show more ...
|
Revision tags: v5.15.70, v5.15.69, v5.15.68 |
|
#
8a1f6c88 |
| 13-Sep-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: support SER L1 simulation
SER (system error recovery) can deal with different crash types by different levels of processes. Previous FW crash simulation triggers a CPU exception which i
wifi: rtw89: support SER L1 simulation
SER (system error recovery) can deal with different crash types by different levels of processes. Previous FW crash simulation triggers a CPU exception which is one kind of SER L2 type. It can verify SER L2 flow which includes HW/FW restart.
Now, we want to increase crash simulation types. A debug function is added to trigger control error in purpose for SER L1 simulation/verification. And, debugfs fw_crash is extended to accept different parameters.
echo 1 > fw_crash: simulate CPU exception as before (keep 1 for compatibility with previous)
It will be catched and handled by SER L2. (this requires HW/FW restart)
echo 2 > fw_crash: simulate control error
It will be catched and handled by SER L1. (driver and FW cooperate to recover this)
Besides, in order to apply to the above two cases, rename RTW89_FLAG_RESTART_TRIGGER to RTW89_FLAG_CRASH_SIMULATING and adjust where SER flow clears this bit for both L1 and L2.
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-5-pkshih@realtek.com
show more ...
|
Revision tags: v5.15.67, v5.15.66 |
|
#
7dbdf655 |
| 08-Sep-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: support TX diversity for 1T2R chipset
Check RSSI strength to decide which path is better, and then set TX path accordingly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-
wifi: rtw89: support TX diversity for 1T2R chipset
Check RSSI strength to decide which path is better, and then set TX path accordingly.
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-6-pkshih@realtek.com
show more ...
|
#
6ce472d6 |
| 08-Sep-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: record signal strength per RF path
Originally, we show average signal strength. To support TX diversity, this patch prepares strength per path, then we can decide TX path.
RSSI: -54
wifi: rtw89: record signal strength per RF path
Originally, we show average signal strength. To support TX diversity, this patch prepares strength per path, then we can decide TX path.
RSSI: -54 dBm (raw=112, prev=110) [-57, -52]
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-5-pkshih@realtek.com
show more ...
|
Revision tags: v5.15.65 |
|
#
4c51541d |
| 02-Sep-2022 |
Benjamin Berg <benjamin.berg@intel.com> |
wifi: mac80211: keep A-MSDU data in sta and per-link
The A-MSDU data needs to be stored per-link and aggregated into a single value for the station. Add a new struct ieee_80211_sta_aggregates in ord
wifi: mac80211: keep A-MSDU data in sta and per-link
The A-MSDU data needs to be stored per-link and aggregated into a single value for the station. Add a new struct ieee_80211_sta_aggregates in order to store this data and a new function ieee80211_sta_recalc_aggregates to update the current data for the STA.
Note that in the non MLO case the pointer in ieee80211_sta will directly reference the data in deflink.agg, which means that recalculation may be skipped in that case.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
Revision tags: v5.15.64 |
|
#
0d466f05 |
| 26-Aug-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: no HTC field if TX rate might fallback to legacy
Packets containing HTC field with legacy rate could be dropped by AP. If TX rate of report is lower than MCS2, hardware might fall back
wifi: rtw89: no HTC field if TX rate might fallback to legacy
Packets containing HTC field with legacy rate could be dropped by AP. If TX rate of report is lower than MCS2, hardware might fall back rate to legacy. Therefore, add a checking rule to avoid HTC field in this situation.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220826061011.9037-1-pkshih@realtek.com
show more ...
|
Revision tags: v5.15.63, v5.15.62, v5.15.61 |
|
#
08aa8077 |
| 15-Aug-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: correct BA CAM allocation
BA CAM entries are global resource of hardware, so move the bitmap and instances to rtw89_cam_info, and then use link list from rtw89_sta to these instances.
wifi: rtw89: correct BA CAM allocation
BA CAM entries are global resource of hardware, so move the bitmap and instances to rtw89_cam_info, and then use link list from rtw89_sta to these instances.
To check the allocation, add ba_cam to debugfs:
map: mac_id: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 addr_cam: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bssid_cam: 01 00 00 00 00 00 00 00 sec_cam: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ba_cam: 03 00 00 00 00 00 00 00 VIF [0] 94:08:53:8e:ef:21 bssid_cam_idx=0 addr_cam_idx=0 -> bssid_cam_idx=0 sec_cam_bitmap=00 00 00 00 00 00 00 00 STA [0] 38:78:62:8b:cb:c6 addr_cam_idx=0 -> bssid_cam_idx=0 sec_cam_bitmap=00 00 00 00 00 00 00 00 ba_cam tid[6]=0, tid[1]=1
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-4-pkshih@realtek.com
show more ...
|