wifi: rtw89: update DMA function with different generation

The register of control and polling function for TX/RX DMA is different
from different generation, so update them. Also rename polling_dma
function to polling_dma_idle to avoid misunderstanding.

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/20240302005828.13666-4-pkshih@realtek.com

wifi: rtw89: wow: update WoWLAN reason register for different chips

The WoWLAN reason register is used for driver to get the wakeup reason
for reporting to cfg80211, and it is different from chips. So put it
into chip information.

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/20240302005828.13666-2-pkshih@realtek.com

wifi: rtw89: coex: Add coexistence policy to decrease WiFi packet CRC-ERR

The 2 Bluetooth profiles (Hands free profile & Human interface device)
have high duty transmission, it will affect the traffic of WiFi packet
frequently. And once the WiFi traffic down to B/G mode, it will need
a better success rate to recover the transmission rate. Add new policy
option to solve the above situation.

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-9-pkshih@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

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

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

wifi: rtw89: 8922a: add coexistence helpers of SW grant

Under some circumstances, coexistence mechanism want to keep grant BT or
WiFi, such as inquiry and WiFi is connecting, to ensure BT or WiFi can
transmit or receive data in that period.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240229074514.219276-3-pkshih@realtek.com

wifi: rtw89: chan: support MCC on Wi-Fi 7 chips

On Wi-Fi 7 chips, concurrent stuffs are supported by FW MRC series
(multi-role concurrent) functions. And, driver has implemented the
corresponding SW handling in patches in front of this one. Now, we
extend SW MCC (multi-channel concurrent) flow to work on Wi-Fi 7
chips.

In SW point of view, things look as below.

| SW | | FW func |
| | | H2C/C2H |
--------------------------------------------
| | ax |
| | /----| FW MCC func |
| MCC | -- chip --+ |
| | \----| FW MRC func |
| | be |

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-5-pkshih@realtek.com

wifi: rtw89: mac: implement MRC C2H event handling

Add handling of MRC (multiple role concurrent) C2H events including
TSF report and status report. Parse report data and then complete the
corresponding H2C commands, which will be implemented in the following.

Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240213073514.23796-3-pkshih@realtek.com

wifi: rtw89: change qutoa to DBCC by default for WiFi 7 chips

Since WiFi 7 is expected to support MLO, so we should enable MAC-0/1 and
PHY-0/1. By default, set dbcc_en=true, change quota to DBCC mode, and set
MLO mode to 2 + 0 that means we only use 2x2 connection on MAC/PHY-0
for now.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240209065229.34515-12-pkshih@realtek.com

wifi: rtw89: 8922a: implement AP mode related reg for BE generation

Modify reg for BE generation when AP stop, otherwise have warning
messages "Polling beacon packet empty fail".

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/20240209065229.34515-10-pkshih@realtek.com

wifi: rtw89: chan: move handling from add/remove to assign/unassign for MLO

After MLO, we will need to consider not only active chanctx but also active
interfaces (roles) to decide entity things. So in advance, we move handling
from chanctx_ops::add/remove to chanctx_ops::assign_vif/unassign_vif. Then,
we can recalculate and aware active interfaces' changes.

For now, behavior should not be really different, since active chanctx and
active interface are one-to-one mapping before MLO.

Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240206030624.23382-6-pkshih@realtek.com

wifi: rtw89: chan: tweak weight recalc ahead before MLO

Originally, we consider weight only based on how many chanctxs that
mac80211 sets. However, we need to consider both active chanctxs and
active interfaces to distinguish MCC (multiple channel concurrent)
from impending MLO.

Although the logic of handling is extended, for now, behavior might
not be different under current condition.

Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240206030624.23382-5-pkshih@realtek.com

wifi: rtw89: drop TIMING_BEACON_ONLY and sync beacon TSF by self

Some of our calculation during concurrent mode depend on last beacon
TSF. Originally, we just set IEEE80211_HW_TIMING_BEACON_ONLY and get
what we want from mac80211. But, IEEE80211_HW_TIMING_BEACON_ONLY will
be restricted once we declare MLO.

Since we are about to consider the MLO stuffs, so sync beacon TSF by
ourselves now and unset IEEE80211_HW_TIMING_BEACON_ONLY.

Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240206030624.23382-2-pkshih@realtek.com

wifi: rtw89: fw: read firmware secure information from efuse

To support firmware secure boot, read secure information from efuse to
know if current hardware module can support secure boot with certain
cryptography method.

This information should be prepared before downloading firmware, so read
efuse right after power on at probe stage. The secure information includes
secure cryptography method and secure key index that are used to choose
proper key material when downloading firmware.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240204012627.9647-3-pkshih@realtek.com

wifi: rtw89: 8922a: add chip_ops::rfk_hw_init

Add a chip_ops for WiFi 7 chips to set additional RF configurations
including MLO and PLL settings.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240202030642.108385-12-pkshih@realtek.com

wifi: rtw89: 8922a: add chip_ops::rfk_init_late to do initial RF calibrations later

The RF calibrations are moved into firmware, so we trigger calibrations by
H2C commands and wait for C2H completion events. However, these events
can be received only after HCI (i.e. PCI for now) starts, so we should
do initial RF calibrations after that.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240202030642.108385-11-pkshih@realtek.com

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

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

wifi: rtw89: rfk: add a completion to wait RF calibration report from C2H event

The RF calibrations should be executed one by one, so add a completion
to ensure one is finish before next. The report from C2H event contains
state and optional version, and we only check the state for now. We also
care about the time a RF calibration takes, so record start time before
asking firmware to do calibration and get the delta time when receiving
report.

Consider SER recovery, we can't receive C2H event, use half of argument
'ms' as fixed delay that is 2 times of measured maximum time of
calibrations.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240202030642.108385-2-pkshih@realtek.com

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

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

wifi: rtw89: 8922a: add chip_ops related to BB init

The chip_ops::bb_preinit and ::bb_postinit are called before and after
loading BB parameters from tables of firmware file. The ::bb_reset is
used to reset hardware state, and currently it is not needed by 8922AE so
leave it as empty. The ::bb_sethw is to implement conditional parameters.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240120003831.7014-4-pkshih@realtek.com

wifi: rtw89: add mlo_dbcc_mode for WiFi 7 chips

WiFi 7 chips can operate in various MLO applications, such as 1 link (2SS)
and 2 links (1SS + 1SS), and we should configure different PHY mode for
each of them.

For example,
- MLO_2_PLUS_0_1RF is 1 link with 2SS rate, and enable one RF component.
- MLO_1_PLUS_1_1RF is 2 links with 1SS rate for each, and enable one RF
component that can support two paths.

By default, we set the mode to legacy MLO_DBCC_NOT_SUPPORT (don't support
MLO and DBCC yet), and later we will introduce logic to change the mode.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240120003831.7014-2-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

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

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

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

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

wifi: rtw89: change supported bandwidths of chip_info to bit mask

Basically, all chips can support 20/40/80MHz bandwidth, and 8952C can
support 160MHz bandwidth, which is why we introduced support_bw160 before.
The coming WiFi 7 chips will support 320MHz optionally, so change it to
bit mask instead of adding another support_bw320.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240112062640.36922-3-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

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

wifi: rtw89: 8922a: update BA CAM number to 24

The total BA CAM number of 8922a is 32 instead of 16, and initial 8
entries are dynamic, so update the entry number to 24.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240108091134.67007-5-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

wifi: rtw89: phy: ignore special data from BB parameter file

BB parameter file is a list of tuple {addr, val} with conditional hardware
version. However, tuples within a condition can't be empty, so insert a
special dummy tuple for this case. Then, ignore this tuple when writing.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240105064407.36750-1-pkshih@realtek.com

wifi: rtw89: phy: add parser to support RX gain dynamic setting flow

Add RX gain offset dynamic setting flow according to different bands
and bandwidths. RX gain offset values will be different according to
different channel bands, therefore, this dynamic mechanism is needed
while channel is changed. Add this to parse data from the element of
firmware file, and then we can use them easier at runtime.

Signed-off-by: Chung-Hsuan Hung <hsuan8331@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240105064228.36580-3-pkshih@realtek.com

wifi: rtw89: phy: move bb_gain_info used by WiFi 6 chips to union

WiFi 7 chips use different bb_gain_info struct, so move existing struct to
a union in advance. 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://msgid.link/20240105064228.36580-2-pkshih@realtek.com

wifi: rtw89: coex: Update RF parameter control setting logic

Coexistence will set the RF parameter according to Wi-Fi link mode,
Wi-Fi/Bluetooth signal level, traffic direction, antenna type,
and is there Bluetooth connection exist or not. Bluetooth will notify
the current LNA level by scoreboard. If the setting not as expected,
coexistence will try to assign the correct level.

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/20231218061341.51255-10-pkshih@realtek.com

wifi: rtw89: coex: Add Bluetooth RSSI level information

In order to control RF LNA setting, need Bluetooth RSSI level information.
RSSI level separate Bluetooth RSSI to several level, so the mechanism can
assign a corresponding setting.

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/20231218061341.51255-9-pkshih@realtek.com

wifi: rtw89: coex: Update BTG control related logic

BTG is a RF system type, it means Wi-Fi 2.4GHz and Bluetooth share RF gain
and antenna. The RF gain must control by Wi-Fi or Bluetooth in single side.
For example, if Bluetooth RX a very strong signal, then Bluetooth will
adjust to a lower gain. And Wi-Fi will also use the same gain to do RX,
then maybe the gain will not enough. This BTG control mechanism can do
some refine to this situation.

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/20231218061341.51255-5-pkshih@realtek.com

wifi: rtw89: coex: Add Pre-AGC control to enhance Wi-Fi RX performance

Pre-AGC(Auto gain control) is a hardware mechanism, it will auto adjust
the RX gain for every packet, it can help to keep Wi-Fi signal on a well
RX quality. The coexistence will give advice to control the API and
monitor the settings by firmware report.
Also add function to check register, these registers were monitoring
by Wi-Fi firmware and report to coexistence driver periodically. This
can help to track whether these settings were taking effect or not.

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/20231218061341.51255-4-pkshih@realtek.com

wifi: rtw89: coex: Record down Wi-Fi initial mode information

This information will use as judgment about how to set RF/HW parameters.

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/20231218061341.51255-3-pkshih@realtek.com

wifi: rtw89: coex: Fix wrong Wi-Fi role info and FDDT parameter members

The Wi-Fi firmware 29.29.X should use version 2 role info format. FDDT
mechanism version 5 use the same cell members to judge traffic situation,
don't need to add another new format.

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/20231218061341.51255-2-pkshih@realtek.com

wifi: rtw89: mac: add flags to check if CMAC and DMAC are enabled

Before accessing CMAC and DMAC registers, we should ensure they have been
powered on, so add flag to determine the state. For old chips, we read
registers and check corresponding bit, but it takes extra cost to read.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231211083341.118047-4-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

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

wifi: rtw89: 8922a: add SER IMR tables

To activate SER (system error recovery) in firmware, we have to configure
IMR to trigger interrupts, and then SER can check registers to know if it
need to reset hardware or notify driver to re-configure whole settings.

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-4-pkshih@realtek.com

wifi: rtw89: refine element naming used by queue empty check

In queue empty check, one group contains 32 queues. And, the two elements,
wde_qempty_acq_num and wde_qempty_mgq_sel, are number of group and select
of group. To avoid confusing them with queue number and queue selection,
we refine their naming.

(don't change logic at all)

Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231124071703.132549-5-pkshih@realtek.com

wifi: rtw89: mac: add to get DLE reserved quota

The reserved quota of DLE (data link engine) is used for processing next
packet. Add this to get quota number, and then WiFi 7 chips can use them.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231124071703.132549-3-pkshih@realtek.com

wifi: rtw89: 8922a: extend and add quota number

Define 8922A buffer quota that are used by HCI control flow, payload
engine, descriptor engine and etc for operation modes, such as SCC (single
channel concurrence) and download firmware. Since WiFi 7 chips has more
buffer classifications, add fields and struct according to design.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231124071703.132549-2-pkshih@realtek.com

wifi: rtw89: debug: add debugfs entry to disable dynamic mechanism

A dynamic mechanism is usually an algorithm to adjust registers to adapt
to different environment every two seconds. In field, it could get
unexpected result, so we need to stop it and adjust registers manually, and
then fine tune the algorithm.

To stop mechanisms to assist debugging, add a debugfs entry shown as

Disabled DM: 0x1
[0] DYNAMIC_EDCCA: X

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231122060458.30878-4-pkshih@realtek.com

wifi: rtw89: phy: dynamically adjust EDCCA threshold

Add dynamic mechanism EDCCA (Energy Detection Clear Channel Assessment)
in track work. Using a fixed-value threshold will make EDCCA particularly
sensitive and cause failure to transmit under certain circumstances.
Therefore, the threshold is dynamically adjusted to make EDCCA suitable
for any situation.

However, in some cases, we will adjust the EDCCA threshold to the highest
level so that urgent transmissions can be performed successfully, such as
scanning.

Finally, in order to observe the EDCCA report in time, add the EDCCA perIC
register macro and EDCCA HW report analysis. EDCCA logs can be displayed
by using the EDCCA debug mask.

Signed-off-by: Yi-Chen Chen <jamie_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/20231122060458.30878-3-pkshih@realtek.com

wifi: rtw89: 8922a: read efuse content from physical map

The calibration values of thermal and bias are programmed in invariable
physical map. Read them into driver and will set them to registers later.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231117024029.113845-7-pkshih@realtek.com

wifi: rtw89: 8852c: read RX gain offset from efuse for 6GHz channels

Read calibration values of RX gain offset from efuse, and set them to
registers to normalize RX gain for all hardware modules. Then, PHY dynamic
mechanism can get expected values to adjust hardware parameters to yield
expected performance.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231117024029.113845-5-pkshih@realtek.com

wifi: rtw89: mac: add to access efuse for WiFi 7 chips

MAC address, hardware type, calibration values and etc are stored in efuse,
so we read them at probe stage and use them as capabilities to register
hardware.

There are two physical efuse -- one is the main efuse for digital hardware
part, and the other is for analog part. Because they are very similar, we
only describe the main efuse below.

The main efuse is split into two regions -- one is for logic map, and the
other is for physical map. For both regions, we use the same method to read
data, but need additional parser to get logic map. To allow reading
operation, we need to convert power state to active, and turn to idle state
after reading.

For WiFi 7 chips, we introduce efuse blocks to define feature group easier,
and these blocks are discontinue. For example, RF block is from 0x1_0000 ~
0x1_0240, and the next block PCIE_SDIO is starting from 0x2_0000.
Comparing to old one used by WiFi 6 chips, there is only single one logic
map, it would be a little hard to add an new field to a group if we don't
reserve a room in advance.

The relationship between efuse, region and block is shown as below:

(logical map)
+------------+ +---------------+ +-----------------+
| main efuse | | region 1 | | block 0x1_0000~ |
| (digital) | |(to logcal map)| +-----------------+
| | | | => +-----------------+
| | => | | | block 0x2_0000~ |
| | | | +-----------------+
| | |---------------| :
| | | region 2 |
+------------+ +---------------+

+------------+ +-----------------+
| 2nd efuse | ======================> | block 0x7_0000~ |
| (analog) | +-----------------+
+------------+

The parser converting from raw data to logic map is to decode block page,
block page offset, and word_en bits. Each word_en bit indicates two
following bytes as data of logic map, so total four word_en bits can
represent eight bytes. Thus, block page offset is 8-byte alignment.
The layout of a tuple is shown as below

+--------+--------+--------+--------+--------+--------+
| fixed 3 byte header | | | |
| | | | |
| [19:17] block_page | | | ... |
| [16:4] block_page_offset| | | |
| [3:0] word_en | ^ | ^ | |
+----|---+--------+--------+---|----+----|---+--------+
| | |
+-------------------------+---------+
a word_en bit indicates two bytes as data

For example,
block_page = 0x3
block_page_offset = 0x80 (must 8-byte alignment)
word_en = 0x6 (b'0110; 0 means data is presented)
following 4 bytes = 34 56 78 90
Then,
0x3_0080 = 34 56
0x3_0086 = 78 90

A special block page is RTW89_EFUSE_BLOCK_ADIE (7) that uses different
but similar format, because its real efuse size is smaller than main efuse.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231117024029.113845-4-pkshih@realtek.com

wifi: rtw89: regd: handle policy of 6 GHz according to BIOS

According to BIOS configuration of Realtek ACPI DSM function 4,
RTW89_ACPI_DSM_FUNC_6G_BP, we handle the regd policy of 6 GHz.

Policy defines two modes as below.
1. `BLOCK` mode:
The countries in configured list are blocked.
2. `ALLOW` mode:
_Only_ the countries in configured list are allowed.
(i.e. others are all blocked.)

Then, when receiving regulatory notification at runtime, if 6 GHz
is blocked on the country, 6 GHz channels will be disabled.

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/20231114091359.50664-3-pkshih@realtek.com

wifi: rtw89: pci: add pre_deinit to be called after probe complete

At probe stage, we only do partial initialization to enable ability to
download firmware and read capabilities. After that, we use this pre_deinit
to disable HCI to save power.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231110012319.12727-4-pkshih@realtek.com

wifi: rtw89: consider RX info for WiFi 7 chips

For WiFi 7 chips, some fields and predefined length are changed, so
add them accordingly.

The mac_id field is used to identify peer that send a packet, and we can
use it to know RSSI and traffic from the peer. For WiFi 7 chips,
RXWD.mac_id of PPDU status packet is not set by hardware. Instead, we
should fill it by rxinfo_user[].mac_id of PPDU status content.

Also, filter out invalid reports to prevent warning messages keep showing.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231027015059.10032-4-pkshih@realtek.com

wifi: rtw89: configure PPDU max user by chip

Different chip can support different max user in one PPDU report.
So, we now configure it in chip info.

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/20231027015059.10032-3-pkshih@realtek.com

wifi: rtw89: phy: generalize valid bit of BSS color

The register fields of BSS color map and valid bit are in the same register
for existing chips, but coming WiFi 7 chips define another register to
set valid bit, so add a field to chip_info to reuse the code.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231016065115.751662-3-pkshih@realtek.com

wifi: rtw89: phy: change naming related BT coexistence functions

Change naming to disambiguate the functions because their names are common
and not clear about the purpose. Not change logic at all.

These functions are to control baseband AGC while BT coexists with WiFi.
Among these functions, ctrl_btg_bt_rx is used to control AGC related
settings, which is affected by BT RX, while BT shares the same path
with wifi; ctrl_nbtg_bt_tx is used to control AGC settings under
non-shared path condition, which is affected by BT TX.

Signed-off-by: Chung-Hsuan Hung <hsuan8331@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/20231016065115.751662-2-pkshih@realtek.com

wifi: rtw89: add EHT radiotap in monitor mode

Add IEEE80211_RADIOTAP_EHT and IEEE80211_RADIOTAP_EHT_USIG radiotap to
fill basic EHT NSS, MCS, GI and bandwidth.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231011115256.6121-7-pkshih@realtek.com

wifi: rtw89: parse TX EHT rate selected by firmware from RA C2H report

RA (rate adaptive) C2H report is to reflect current TX rate firmware is
using. Parse C2H event encoded in EHT mode, and then user space and debugfs
can use the information to know TX rate.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231011115256.6121-5-pkshih@realtek.com

wifi: rtw89: Add EHT rate mask as parameters of RA H2C command

Set EHT rate mask to RA (rate adaptive) H2C command according to handshake
result. The EHT rate mask format looks like

44 28 12 4 0
+----------------+----------------+--------+----+
| EHT 2SS rate | EHT 1SS rate | OFDM | CCK|
+----------------+----------------+--------+----+

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231011115256.6121-4-pkshih@realtek.com

wifi: rtw89: phy: set TX power RU limit according to chip gen

Wi-Fi 6 chips and Wi-Fi 7 chips have different register design for TX
power RU limit. We rename original setting stuffs with a suffix `_ax`,
concentrate related enum declaration in phy.h, and implement setting
flow for Wi-Fi 7 chips. Then, we set TX power RU limit according to
chip generation.

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/20231003015446.14658-6-pkshih@realtek.com

wifi: rtw89: phy: set TX power limit according to chip gen

Wi-Fi 6 chips and Wi-Fi 7 chips have different register design for
TX power limit. We rename original setting stuffs with a suffix `_ax`,
concentrate related enum declaration in phy.h, and implement setting
flow for Wi-Fi 7 chips. Then, we set TX power limit according to chip
generation.

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/20231003015446.14658-5-pkshih@realtek.com

wifi: rtw89: refine bandwidth 160MHz uplink OFDMA performance

This improves 160MHz performance degradation with certain APs.
Some ICs transmit preamble that are hard to decode by others, continuous
retries then yield low throughput. Fix it with pre-calculated antenna
matrices.

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/20230929004024.7504-3-pkshih@realtek.com

wifi: rtw89: refine uplink trigger based control mechanism

Rename support_ul_tb_ctrl to waveform_ctrl since we need to do more
trigger based control and the naming could be confusing. Move related
code to leaf function so we make each functions separate and can be
easier to maintain.

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/20230929004024.7504-2-pkshih@realtek.com

wifi: rtw89: regd: configure Thailand in regulation type

Realtek RFE (RF Front End) parameters can consider Thailand individually
now, so we add it into regulation type enum. Then, we map country code TH
to RTW89_ETSI/RTW89_THAILAND according to band. The RF TX power tables will
add entries for RTW89_THAILAND in the following.

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>

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

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

wifi: rtw89: phy: extend TX power common stuffs for Wi-Fi 7 chips

The following are introduced for Wi-Fi 7 chips.
1. take BW/OFDMA into account on TX power by rate
2. increase TX power offset types up to EHT
3. split TX shape into tx_shape_lmt and tx_shape_lmt_ru

If functions which are only for AX, they always access TX power by rate
with BW/OFDMA = 0/0, and they don't access tx_shape's lmt_ru section.

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-7-pkshih@realtek.com

wifi: rtw89: phy: refine helpers used for raw TX power

Originally, these helpers were implemented by macros. We rewrite them
by normal functions. In the new function to seek raw TX power by rate,
we access the array according to rate section and discard the original
pointer arithmetic.

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-5-pkshih@realtek.com

wifi: rtw89: indicate TX power by rate table inside RFE parameter

For next-generation chips, TX power by rate table comes from RFE (RF
front end) parameter. It can be different according to RFE type. So,
we indicate TX power by rate table inside RFE parameter ahead. For
current chips, even with different RFE types, a chip is configured
with a single TX power by rate table. So, this commit doesn't really
affect these currently 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/20230920074322.42898-4-pkshih@realtek.com

wifi: rtw89: indicate TX shape table inside RFE parameter

For next-generation chips, TX shape table comes from RFE (RF front end)
parameter. It can be different according to RFE type. So, we indicate
TX shape table inside RFE parameter ahead. For current chips, even with
different RFE types, a chip is configured with a single TX shape table.
So, this commit doesn't really affect these currently 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/20230920074322.42898-3-pkshih@realtek.com

wifi: rtw89: add subband index of primary channel to struct rtw89_chan

The subband index is a hardware value of relationship between primary
channel and bandwidth, and it is used by setting channel/bandwidth to
specify the primary channel.

Because this index is only needed when bandwidth >= 20 MHz, adjust
order of enumerator bandwidth to access offsets array easier. To prevent
misuse RTW89_CHANNEL_WIDTH_NUM as size, change it to
RTW89_CHANNEL_WIDTH_ORDINARY_NUM that will be the size of array. The
enumerator values of bandwidth (before ordinary number) will be also
used by upcoming TX power table built in firmware file, so add a comment
to remind keeping the order.

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-2-pkshih@realtek.com

wifi: rtw89: consolidate registers of mac port to struct

MAC port is a design to support virtual interface on single MAC hardware.
For next generation chips, register addresses are changed but definitions
are the same, so move registers together to be easier to reuse codes.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230911082049.33541-6-pkshih@realtek.com

wifi: rtw89: add chip_info::txwd_info size to generalize TX WD submit

For existing chips, size of TX WD info is 6 words, but upcoming WiFi 7
chips become 8 words, so add a chip_info to reuse the code.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230911082049.33541-5-pkshih@realtek.com

wifi: rtw89: add to fill TX descriptor v2

The format v2 of TX descriptor contains 8-word body and 8-word info, and
fields include packet size, MAC_ID, security key ID and etc.

By design, it can possibly only fill body to reduce overhead, but this
driver keeps thing simple, so always fill body and info currently.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230911082049.33541-4-pkshih@realtek.com

wifi: rtw89: add to fill TX descriptor for firmware command v2

This kind of TX descriptor is used to download firmware or send firmware
command. Because we want to reduce descriptor overhead and this only needs
two fields 'size' and 'type', hardware designers choose short form of
RX descriptor for it.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230911082049.33541-3-pkshih@realtek.com

wifi: rtw89: add to query RX descriptor format v2

RX descriptor is used to provide meta data of received data. The WiFi 7
chips use different RX descriptor format, so add this parser along with
hardware design.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230911082049.33541-2-pkshih@realtek.com

wifi: rtw89: mcc: deal with beacon NoA if GO exists

In MCC STA+GO mode, we calculate NoA information and fill it into the
beacon of P2P GO. Since NoA uses only 32 bits to describe time things,
we need to deal with renewal when TSF[63:32] is carried. We trigger FW
to notify that. Then, we can update NoA information for new time period
once we get notification 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/20230908031145.20931-9-pkshih@realtek.com

wifi: rtw89: mcc: deal with BT slot change

When receiving request of adjusting BT slot from coex. mechanism,
we need to fetch the new BT slot and use the new one to calculate
MCC (multi-channel concurrency) pattern. Then, we update the new
MCC pattern to 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/20230908031145.20931-8-pkshih@realtek.com

wifi: rtw89: mcc: deal with P2P PS change

MCC fills duration limit of a role according to NoA description.
If P2P PS changes during MCC, we don't process P2P PS via normal
flow. Instead, we re-fill duration limit of the role for new NoA
description, and then we do MCC update.

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-7-pkshih@realtek.com

wifi: rtw89: mcc: track beacon offset and update when needed

In MCC STA+GC mode, the offset between TBTTs of remote AP and remote GO
might change. If the change is larger than tolerance, we should update
MCC after re-calculating parameters for new things. So, we track that in
rtw89_track_work() now. And, we add MCC update flow to tell FW either to
change durations of roles or to replace entire pattern according to how
MCC plans BT slot.

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-6-pkshih@realtek.com

wifi: rtw89: mcc: update role bitmap when changed

Each MCC (multi-channel concurrency) role maintains a bitmap of mac IDs.
The bitmap is supposed to contain the two points below.
* mac ID of itself
* mac ID(s) of STA(s) connecting to it
Under STA+GC mode, the bitmaps of both roles should not change. However,
under STA+GO mode, the bitmap of GO may change due to P2P clients which
connect/disconnect to/from it.

FW controls (TDMA-based) MCC things via mac IDs in bitmap of each role.
For example, mac IDs are required by FW when it wants to pause role1's
TX in role0 slot.

So, to sync between driver and FW, we update the new mac ID bitmap of GO
to FW once it's changed.

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-5-pkshih@realtek.com

wifi: rtw89: 52c: rfk: disable DPK during MCC

DPK is one kind of RF calibration. When MCC (multi-channel concurrency)
start/stop, DPK needs to do extra things to be off/on. We add a chanctx
callback type, RTW89_CHANCTX_CALLBACK_RFK, and register it for RTL8852C
to deal with DPK according to MCC states.

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-4-pkshih@realtek.com

wifi: rtw89: 8922a: add chip_ops::bb_preinit to enable BB before downloading firmware

Before downloading firmware for BB MCU, call this ops to enable baseband
hardware.

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-7-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

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

wifi: rtw89: mcc: decide pattern and calculate parameters

After the previous works, we can now expand and display the MCC pattern
in more detail, as shown below.

|< MCC interval >|
|< duration ref >| (if mid bt) |< duration aux >| (if tail bt) |
|<tob ref >|< toa ref>| ... |<tob aux >|< toa aux>| ... |
V V
tbtt ref tbtt aux
|< beacon offset >|

(where tob means `time offset behind` and toa means `time offset ahead`)

There are two key points.
1. decide position of BT slot if MCC pattern needs to handle BT duration.
2. calculate all parameters related to tob and toa in MCC pattern.

For point (1), when BT duration needs to be handled, BT position will
rely on beacon offset, either middle or tail. For point (2), to ensure
durations of the Wi-Fi roles cover their beacons, we have to calculate
tob and toa for them according to their TBTT.

And, there are two strategies to calculate parameters, strict and loose.
In strict pattern, all parameters take HW time into account as limitation.
But, the strict calculation are not always successful. In loose pattern,
it only tries to give positive parameters to reference role and doesn't
care much about auxiliary role. If unfortunately auxiliary role gets
negative parameters in loose pattern, FW will be notified and then deal
with it. So, the loose calculation won't fail. In general, we always try
strict pattern cases before using a loose pattern.

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-5-pkshih@realtek.com

wifi: rtw89: mcc: fill fundamental configurations

We determine the fundamental settings shown below.

|< MCC interval >|
|< duration ref >|< duration aux >|
| | | |
|< beacon offset >|
| |
V V
(tbtt ref) (tbtt aux)

(where `ref` (reference) and `aux` (auxiliary) mean the two MCC roles)

Based on MCC mode (GO+STA or GC+STA), we fill configurations of
MCC interval and beacon offset. And, we make sure each MCC role
have a basically required duration in the MCC interval.

The beacon offset mentioned above is a parameter for further MCC
pattern calculation. If MCC is in GC+STA mode, we will calculate
the real beacon offset through TSFs shown in beacons of both MCC
roles. Otherwise, we will use a default beacon offset, and make
GO sync STA's TSF timer with this offset.

MCC pattern calculation will break down each MCC role's duration
in more detail. We will implement it in the following.

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-3-pkshih@realtek.com

wifi: rtw89: mcc: initialize start flow

We prepare to support TDMA-based MCC (multi-channel concurrency)
which allows two kinds of modes below.
* P2P GO + normal STA
* P2P GC + normal STA

Each mode has two vif and two chanctx. Then, each vif binds one
separate chanctx and becomes one MCC role. We name the two MCC
roles as follows.
* MCC role - reference (ref)
We calculate the baseline of our TDMA things accodring
to its info, e.g. TBTT. In normal case, it will be put
at the first slot of TDMA.
* MCC role - auxiliary (aux)

MCC state machine will be running in FW eventually, but before that,
we have to fill and calculate things that are needed by FW. We fill
the information of MCC role according to its vif and its chanctx.
Then, we calculate the start time for MCC.

Note that the parameters used in the calculation now is assigned by
default rules. The precise parameters for better MCC behavior will be
derived in the following.

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-2-pkshih@realtek.com

wifi: rtw89: phy: modify register setting of ENV_MNTR, PHYSTS and DIG

The ENV_MNTR(environment monitor) is the dynamic mechanism which based on
the HW of CCX(Cisco Compatible Extensions) which provide the channel
loading and noisy level indicator to debug or support the 802.11k. The
PHYSTS provide the detail PHY information per packet we received for
debugging. The DIG(dynamic initial gain) is the dynamic mechanism to
adjust the packet detect power level by received signal strength to avoid
false detection of the WiFi packet.

The address of registers used for ENV_MNTR, PHYSTS and DIG of WiFi 7 IC
are different with WiFi 6 series, so we modify the method to access the
register address in order to compatible with all WiFi 7 and 6 ICs.

Signed-off-by: Cheng-Chieh Hsieh <cj.hsieh@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/20230822125822.23817-7-pkshih@realtek.com

wifi: rtw89: phy: add phy_gen_def::cr_base to support WiFi 7 chips

cr_base is base address of PHY control register. The base of WiFi 6 and 7
chips are 0x1_0000 and 0x2_0000 respectively, so define them accordingly.
For example, if PHY address is 0x1330, absolute address is 0x1_1330 for
WiFi 6 chips, and 0x2_1330 for WiFi 7 chips.

Meanwhile, there are two copies of PHY hardware named PHY0 and PHY1. The
offset between them is 0x2_0000, so the base address of PHY0 and PHY1 are
0x2_0000 and 0x4_0000 respectively.

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-6-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

wifi: rtw89: initialize multi-channel handling

We prepare to deal with multiple channels via new entity modes.
* MCC_PREPARE: Transitional mode before MCC
* MCC: Multi-Channel Concurrent mode
And, enum of sub-entity is extended for second channel context.

We add the entry flow of multi-channel handling and the core stuffs
for extended index of sub-entity. And, we now deal with the filling
of entity channels' info in entity recalc where we know the number
of active chanctx. However, the other detail coding of MCC start/stop
will be implemented in the following.

Besides, chanctx listener struct is pre-added in chip info. Each
component can add callback type in chanctx listener and configure
its callback function to react according to chanctx states. We know
at least RFK (RF calibration) and BTC (BT coexistence) will require
such callbacks.

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-7-pkshih@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

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

wifi: rtw89: add function prototype for coex request duration

The request duration comes from coex mechanism, indicating the
length of time that should be reserved for BT in each time division.
It is required to handle update notification when channel concurrency
processes. Since it will involve in both coex and wifi code flow, this
commit ahead adds the prototype for required function interfaces to
split the implementation of coex and wifi in the following.

The follow-up are expected be add afterwards.
1. coex mechanism call rtw89_core_ntfy_btc_event() once bt req len changes
2. channel concurrency flow updates related stuffs when notified

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-2-pkshih@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 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

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

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

wifi: rtw89: add firmware suit for BB MCU 0/1

For existing chips, firmware is only for WiFi CPU, but WiFi 7 chips add
new hardware component BB MCU that needs firmware as well. The firmwares of
BB MCU 0/1 are also downloaded via the same path like WiFi CPU firmware,
and use the same firmware header format, so add firmware suits to access
them commonly.

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-6-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

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

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

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

wifi: rtw89: add C2H RA event V1 to support WiFi 7 chips

WiFi 7 chips have more rate mode (EHT), higher MCS and more bandwidth, so
define and use reserved bits to carry these information in C2H events.
Also, the SS/MCS encoded bits of VHT and HE are changed, so define V1 masks
for them.

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-9-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

wifi: rtw89: define hardware rate v1 for WiFi 7 chips

To support EHT rate, hardware rate v1 is introduced. The CCK and OFDM rates
are persistent. HT/VHT/HE rates use different rate code from original, and
add new code for EHT 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-3-pkshih@realtek.com

wifi: rtw89: add chip_info::chip_gen to determine chip generation

The coming WiFi 7 chip is 8922AE which uses different hardware rate and
register naming rule. Adding a chip_info::chip_gen field can help to
do things by generations accordingly.

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-2-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

wifi: rtw89: TX power stuffs replace confusing naming of _max with _num

Some old declarations about TX power stuffs were named with confusing
`_max`. But, they mean "the number of". So we change them to be named
with `_num`.

(No logic is changed.)

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/20230616060523.28396-1-pkshih@realtek.com

wifi: rtw89: cleanup rtw89_iqk_info and related code

Drop useless '_iqk_track()' and 'rtw8852a_iqk_track()' (they
just change 'thermal_rek_en' field which is set but unused
and so removed as well) functions, set but unused 'kcount'
field of 'struct rtw89_iqk_info', and convert 'thermal' to
local variables where appropriate (it doesn't need to have
longer storage duration because it is actually used for the
debugging purposes only).

Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230614081555.91395-2-dmantipov@yandex.ru

wifi: rtw89: cleanup private data structures

Remove a bunch of unused (and set but unused) fields
from 'struct rtw89_btc_wl_nhm', 'struct rtw89_dle_info',
'struct rtw89_hal' and 'struct rtw89_env_monitor_info'
driver-specific data structures, adjust related bits.

Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230614081555.91395-1-dmantipov@yandex.ru

wifi: rtw89: 8852c: update TX power tables to R63 with 6 GHz power type (3 of 3)

Update TX power tables to RF version R63.

TX power tables' changes:
* TX power byrate:
tweak a bit
* TX power limit, TX power limit RU, TX power shape:
configure values for MEXICO, UKRAINE, CHILE, QATAR
tweak a bit on other configured values
* 6 GHz TX power limit, 6 GHz TX power limit RU:
add an extra dimension for 6 GHz regulatory power type, i.e.
STD (standard power), LPI (low power indoor), VLP (very low power)

Besides, we adjust TX power handling at 6 GHz in phy to consider 6 GHz
regulatory power type.

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/20230602150556.36777-8-pkshih@realtek.com

wifi: rtw89: 8852c: update TX power tables to R63 with 6 GHz power type (2 of 3)

Update TX power tables to RF version R63.

TX power tables' changes:
* TX power byrate:
tweak a bit
* TX power limit, TX power limit RU, TX power shape:
configure values for MEXICO, UKRAINE, CHILE, QATAR
tweak a bit on other configured values
* 6 GHz TX power limit, 6 GHz TX power limit RU:
add an extra dimension for 6 GHz regulatory power type, i.e.
STD (standard power), LPI (low power indoor), VLP (very low power)

Besides, we adjust TX power handling at 6 GHz in phy to consider 6 GHz
regulatory power type.

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/20230602150556.36777-7-pkshih@realtek.com

wifi: rtw89: process regulatory for 6 GHz power type

Configure the corresponding power type for 6 GHz regulatory if we can
determine one single target. Otherwise, we use the default one.

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/20230602150556.36777-5-pkshih@realtek.com

wifi: rtw89: use struct and le32_get_bits() to access received PHY status IEs

PHY status IEs generated by BB hardware is to provide more detail
information related to received packets, such as RSSI and bandwidth.

To avoid type casting, change buf type from u8* to void* as well.

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-4-pkshih@realtek.com

wifi: rtw89: add chip_ops::query_rxdesc() and rxd_len as helpers to support newer chips

The next generation chips use different RX descriptor format, so add
a chip_ops to hook suitable handlers. Also, the length of RX descriptor is
different, so add a variable to store the length according to chip and
descriptor content dynamically. Then, the code can be more general.

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-2-pkshih@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

wifi: rtw89: 8851b: configure GPIO according to RFE type

Though 8851BE is a 1x1 chip, but it has two antenna hardware module that
needs additional configuration to help choose antenna we are going to use.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230512061220.16544-3-pkshih@realtek.com

wifi: rtw89: suppress the log for specific SER called CMDPSR_FRZTO

For 8852CE, there is abnormal state called CMDPSR_FRZTO,
which occasionally happens in some platforms, and could be
found by firmware and fixed in current SER flow, so we add
suppress function to avoid verbose message for this resolved case.

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/20230508084335.42953-4-pkshih@realtek.com

wifi: rtw89: ser: L1 add pre-M0 and post-M0 states

Newer FW re-design SER (syetem error recovery) L1 (level 1) flow.
New L1 flow will expect two extra states before original L1 flow.

* Before:
fw --- M1 --> driver
fw <-- M2 --- driver
fw --- M3 --> driver
fw <-- M4 --- driver
fw --- M5 --> driver

* After:
fw --- pre-M0 --> driver
fw <-- post-M0 --- driver
fw --- M1 --> driver
fw <-- M2 --- driver
fw --- M3 --> driver
fw <-- M4 --- driver
fw --- M5 --> driver

Then before M1, FW gets one more interval to deal with things that FW
should have handled well. To consider backward/forward compatibility,
FW and driver won't change flow from M1 to M5. (only except that halt
trigger control will change a little bit.) So, there will be two differnt
starting points of SER L1.
* old FW: SER L1 starts from M1
* new FW: SER L1 starts from pre-M0
Then, driver adds the new SER L1 entry and also keep the original one
instead of changing 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/20230508084335.42953-3-pkshih@realtek.com

wifi: rtw89: regd: judge UNII-4 according to BIOS and chip

For realtek regulatory, there are following two kinds of configurations
to determine whether to allow UNII-4 band, i.e. 5.9GHz channels.

1. default setting according to whether chip support it or not
2. evaluate realtek ACPI DSM with RTW89_ACPI_DSM_FUNC_59G_EN (func. 6)

If (1) is false, we won't try (2) and just disallow UNII-4. Otherwise,
if (2) is not supported or returns a non-specific value, we follow the
default setting either. Besides, this commit aims to add decision logic
in rtw89 regulatory. Actually, driver doesn't register UNII-4 yet. That
will be handled by another commit.

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/20230508081211.38760-3-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

wifi: rtw89: use chip_info::small_fifo_size to choose debug_mask

Previously, 8852B has smaller FIFO size than others, so I use chip_id to
choose debug_mask before. 8851B has similar design, so add a field to
chip_info as a general expression.

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-6-pkshih@realtek.com

wifi: rtw89: add CFO XTAL registers field to support 8851B

Since CFO XTAL registers of 8851B is different from 8852A, add a chip_info
field to define their difference. Other chips use another interface, so
fill NULL to this field.

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/20230421024551.29994-5-pkshih@realtek.com

wifi: rtw89: 8851b: add NCTL post table

NCTL (nano-controller) is used to assist RF calibration that sends
commands to NCTL so it can reduce IO from driver. 8851B needs additional
settings, so add a table to do things.

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-4-pkshih@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

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

wifi: rtw89: add EVM for antenna diversity

Take EVM into consideration when doing antenna diversity, and the priority
is higher than RSSI. Since EVM is more relevant to performance than RSSI,
especially in OTA environment.

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/20230418012820.5139-8-pkshih@realtek.com

wifi: rtw89: add RSSI based antenna diversity

RSSI statistics are grouped by CCK, OFDM or non-legacy rate. These
statistics will be collected in training state for both (main/aux)
antenna. There is a time period (ANTDIV_DELAY) for rate adaptive
settle down before start collect statistics when switch antenna.

Antenna diversity checks packet count from training state for each
group and use the most one as the final RSSI for comparison, and
then choose the better one as target antenna.

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/20230418012820.5139-7-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-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

wifi: rtw89: set capability of TX antenna diversity

TX antenna diversity is a mechanism to select a proper antenna from two
antenna for single one hardware PHY chip. It chooses antenna with better
EVM or RSSI, and use GPIO to control SPDT to switch selected antenna.

RFE type from efuse is used to define if a module can support TX antenna
diversity when (type % 3) is 2.

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-3-pkshih@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

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

wifi: rtw89: read version of analog hardware

The chip contains digital and analog parts, and each of them has its own
version number. This is used by BT coexistence mechanism to make strategy
decision for different analog version.

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-2-pkshih@realtek.com

wifi: rtw89: use hardware CFO to improve performance

Turn on hardware CFO (central frequency offset) compensation based on IC
capability, and improve digital CFO compensation accuracy by using
more fixed points number.

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/20230330132352.13647-1-pkshih@realtek.com

wifi: rtw89: support parameter tables by RFE type

One chip can have different RFE (RF front end) types which we will judge
at runtime. And, different RFE types may use different RF parameter tables.
Though we didn't really meet this case previously, we are going to meet it
on upcoming chip RTL8851B. So, this commit handles parameter tables for
runtime RFE type.

We now encapsulate rtw89_txpwr_rule_<2/5/6>ghz tables into rtw89_rfe_parms.
Then, each chip defines its default parameter tables, and if needed, it can
configure extra parameter tables by RFE type. Finally we determine runtime
parameter tables by RFE type if one is configured. Otherwise, we use the
default parameter tables.

For now, we just move all settings under default parameter tables. We will
configure parameter tables by RFE types in separate commits afterwards.

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/20230330080331.37155-1-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

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

wifi: rtw89: add ieee80211::remain_on_channel ops

Add support of remain on channel ops. Since channel context is
required to enable multi-channel concurrent(MCC) and the current
ROC in mac80211 don't support more than 1 channel context, add this
to let P2P and other protocols relying on this work as expected.
The off-channel duration and cancel timing is purely controlled by
upper layers.

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-4-pkshih@realtek.com

wifi: rtw89: add function to wait for completion of TX skbs

Allocate a per-skb completion to track those skbs we are interested in
and wait for them to complete transmission with TX status.

Normally, the completion object is freed by wait side, but it could be
timeout result that complete side should free the object instead. Add a
owner field with RCU to determine which side should free the object.

Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230411124832.14965-3-pkshih@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

wifi: rtw89: config EDCCA threshold during scan to prevent TX failed

Need to configure EDCCA threshold to default value before scan, and recall
original value after scan to prevent probe request can't be sent out.

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/20230322060238.43922-1-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

wifi: rtw89: coex: Add report control v5 variation

In order to reduce firmware code size cost, remove some counter value from
the structure. But firmware didn't update version code. To parse the
correct report, add another variation version v105 to parse it.

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/20230314020617.28193-5-pkshih@realtek.com

wifi: rtw89: coex: Update RTL8852B LNA2 hardware parameter

The LNA gain didn't set before, it will lead some WiFi RX issue.
And the setting can increase both of WiFi & BT performance while
they are both RX.

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/20230314020617.28193-4-pkshih@realtek.com

wifi: rtw89: coex: Add v5 firmware cycle status report

To support v5 version firmware cycle report, apply the related structure
and functions. v5 cycle report add a group of status to show how the
free-run/TDMA training goes to. It is a firmware mechanism that can auto
adjust coexistence mode between TDMA and free run mechanism at 3 antenna
solution. v5 version provide more reference data to let the mechanism
make decision.

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-8-pkshih@realtek.com

wifi: rtw89: coex: Add v2 Bluetooth scan info

Compare to v1 and v2 removed some not usable parameters. Save firmware
code size. The information can show how frequent and how long the
Bluetooth scan do. It will help to debug coexistence issue.

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-7-pkshih@realtek.com

wifi: rtw89: coex: Add register monitor report v2 format

The v2 firmware report reduce its maximum register numbers from 30 to 20,
it can help to save firmware code size.

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-5-pkshih@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

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

wifi: rtw89: coex: Add more error_map and counter to log

The error map and counter can help to analyze is coexistence mechanism
going well or not. For example, if there is E2G (External control Wi-Fi
slot for Wi-Fi 2.4 GHz) hang counter, it means Wi-Fi firmware didn't cut
a slot for Wi-Fi 2.4 GHz. Maybe something wrong with firmware timer.

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-2-pkshih@realtek.com

wifi: rtw89: release RX standby timer of beamformee CSI to save power

Originally, we keep RX standby timer to handle beamformee CSI, but this
spends power and causes system not entering power save mode. To improve
power consumption, release the timer if throughput becomes low.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230307141848.26403-1-pkshih@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

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

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

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

wifi: rtw89: disallow enter PS mode after create TDLS link

Buffer STA on TDLS links are not currently supported. Therefore, it
is not allowed to enter the PS mode after TDLS link is established.

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/20230119064631.66971-1-pkshih@realtek.com

wifi: rtw89: coex: Change firmware steps report to version separate

The report records the slots/events and their time cost about the code
call flow at firmware, ver 3 assign a reserved variable to recognize
the report is enabled or not. And add corresponding function to parsing
the report.

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-4-pkshih@realtek.com

wifi: rtw89: coex: Change Wi-Fi Null data report to version separate

Coexistence need to send Null data to stop AP keeps TX packet to DUT
before DUT coexistence switch to Bluetooth time slot, or it will be an
interference to DUT BT and because DUT will not RX packet from AP
the packet retry may harmful to WL TP. Compare to v1 version, the newer
firmware report will also report Null TX data counter.

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-3-pkshih@realtek.com

wifi: rtw89: coex: Add v5 firmware control report

Comparing v5 control report to v4 version, v5 reduce some of variable's
size to reduce firmware code size. And change the grant signal report
format.

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-6-pkshih@realtek.com

wifi: rtw89: coex: Change firmware control report to version separate

The rtw89 driver may support more than 1 version of Wi-Fi firmware for
certain chips. In order to support all the firmware, change to select logic
by firmware feature version code. Type control version 4 will monitor
Bluetooth PTA hardware counters at firmware and C2H to driver, but
version 1 will not do this.

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-5-pkshih@realtek.com

wifi: rtw89: coex: Add v4 version firmware cycle report

To support v4 version firmware cycle report, apply the related
structure and functions. v4 cycle report add a group of status
to show how the free-run/TDMA training goes to. It is a firmware
mechanism that can auto adjust coexistence mode between TDMA and
free run mechanism at 3 antenna solution.

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-4-pkshih@realtek.com

wifi: rtw89: coex: Rename BTC firmware cycle report by feature version

Because there are new report format in the upcoming patches, to make the
logic more readable, rename the related structure by their version number.
And to support the several version at the same time, add union definition
to include all the versions.

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-3-pkshih@realtek.com

wifi: rtw89: 8852b: update BSS color mapping register

BSS color mapping register is different per IC, therefore, move this
register to chip_info and update the setting function. Without this patch,
wrong BSS color causes behavior abnormal, especially DL-OFDMA.

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/20221214091803.41293-1-pkshih@realtek.com

wifi: rtw89: coex: Change TDMA related logic to version separate

In order to make different version of TDMA and coming update in the future
can all work well, use BTC format version to replace chip_id, because
format could change for specific chip_id.

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/20221217141745.43291-8-pkshih@realtek.com

wifi: rtw89: coex: Add v2 BT AFH report and related variable

Wi-Fi firmware update AFH report feature to version 2. If there is BT BLE
device connect to DUT, the mechanism will send H2C to request BT BLE
channel map, it will help to debug.

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/20221217141745.43291-6-pkshih@realtek.com

wifi: rtw89: coex: use new introduction BTC version format

Previous patch has added format version derived from firmware version.
Use the format version, and remove constant version number from chip_info.

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-3-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

wifi: rtw89: consider ER SU as a TX capability

ER (Extended Range) SU is to have a larger coverage. We set this as a RA
capability, and then firmware can choose ER SU to transmit packets to
reception at cell edge. For 8852C, it needs to fill this capability in
TXWD, so update rtw89_build_txwd_info0_v1().

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221209012110.7242-1-pkshih@realtek.com

wifi: rtw89: link rtw89_vif and chanctx stuffs

First, introduce struct rtw89_sub_entity for chanctx related stuffs.
Second, add enum rtw89_sub_entity_idx to rtw89_vif for vif operation
to access its/right chanctx stuffs after future multi-channel support.

Besides, RTW89_SUB_ENTITY_0 is the default chanctx entry throughout
driver, i.e. it's used for things which may not have a target chanctx
yet. So, we need to ensure that RTW89_SUB_ENTITY_0 is always working.
If there is at least one alive chanctx, then one of them must take
RTW89_SUB_ENTITY_0. If no alive chanctx, RTW89_SUB_ENTITY_0 will be
filled by rtw89_config_default_chandef().

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-7-pkshih@realtek.com

wifi: rtw89: mac: process MCC related C2H

Process C2H(s) related to MCC (multi-channel concurrency). These handling,
which either call rtw89_complete_cond() or show message in debug mode, can
be considered atomic/lock-free. So, they should be safe to be processed
directly after C2H pre-check in previous patch.

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-5-pkshih@realtek.com

wifi: rtw89: introduce helpers to wait/complete on condition

MCC (multi-channel concurrency) related H2Cs (host to chip commands)
require to wait for C2H (chip to host events) responses to judge the
execution result and data. We introduce helpers to assist this process.
Besides, we would like the helpers to be generic for use in driver even
outside of MCC H2C/C2H, so we make a independent patch for them.

In the following, I describe the things first.
```
(A) C2H is generated by FW, and then transferred upto driver. Hence,
driver cannot get it immediately without a bit waitting/blocking.
For this, we choose to use wait_for_completion_*() instead of
busy polling.
(B) From the driver management perspective, a scenario, e.g. MCC,
may have mulitple kind of H2C functions requiring this process
to wait for corresponding C2Hs. But, the driver management flow
uses mutex to protect each behavior. So, one scenario triggers
one H2C function at one time. To avoid rampant instances of
struct completion for each H2C function, we choose to use one
struct completion with one condition flag for one scenario.
(C) C2Hs, which H2Cs will be waitting for, cannot be ordered with
driver management flow, i.e. cannot enqueue work to the same
ordered workqueue and cannot lock by the same mutex, to prevent
H2C side from getting no C2H responses. So, those C2Hs are parsed
in interrupt context directly as done in previous commit.
(D) Following (C), the above underline H2Cs and C2Hs will be handled
in different contexts without sync. So, we use atomic_cmpxchg()
to compare and change the condition in atomic.
```

So, we introduce struct rtw89_wait_info which combines struct completion
and atomic_t. Then, the below are the descriptions for helper functions.
* rtw89_wait_for_cond() to wait for a completion based on a condition.
* rtw89_complete_cond() to complete a given condition and carry data.
Each rtw89_wait_info instance independently determines the meaning of
its waitting conditions. But, RTW89_WAIT_COND_IDLE (UINT_MAX) is reserved.

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-4-pkshih@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

wifi: rtw89: add HE radiotap for monitor mode

With basic HE radiotap, we can check data rate in sniffer data. To store
the radiotap data, we reserve headroom of aligned 64 bytes, and then
update HE radiotap in monitor mode, so it doesn't affect performance in
normal mode.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221125072416.94752-3-pkshih@realtek.com

wifi: rtw89: avoid inaccessible IO operations during doing change_interface()

During doing change_interface(), hardware is power-off, so some components
are inaccessible and return error. This causes things unexpected, and we
don't have a warning message for that. So, ignore some IO operations in
this situation, and add a warning message to indicate something wrong.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221117085235.53777-1-pkshih@realtek.com

wifi: rtw89: switch BANDEDGE and TX_SHAPE based on OFDMA trigger frame

There are some registers for transmit waveform control, two of them used
in this change are for BANDEDGE and TX_SHAPE control. BANDEDGE controls
whether to apply band edge filter to transmit waveform. TX_SHAPE controls
whether to apply triangular mask to transmit waveform. It is found for
some chip, these two should be turned off during OFDMA UL traffic for
better performance.

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/20221117063001.42967-3-pkshih@realtek.com

wifi: rtw89: read CFO from FD or preamble CFO field of phy status ie_type 1 accordingly

Add macro to get FD(frequency domain) CFO field from ie_type 1, and correct
the naming for preamble CFO field. Each IC could assign the CFO source to
either FD CFO or preamble CFO in chip_info. Based on the suggestion from HW
designer, rtw8852b and its derived versions will have better CFO tracking
performance with FD CFO.

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/20221117063001.42967-2-pkshih@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

wifi: rtw89: add WoWLAN function support

WoWLAN is a feature which allows devices to be woken up from suspend
state through WLAN events.

When user enables WoWLAN feature and then let the device enter suspend
state, WoWLAN firmware will be loaded by the driver and periodically
monitors WiFi packets. Power consumption of WiFi chip will be reduced
in this state.

We now implement WoWLAN function in rtw8852ae and rtw8852ce chip.
Currently supported WLAN events include receiving magic packet,
rekey packet and deauth packet, and disconnecting from AP.

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-7-pkshih@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

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

wifi: rtw89: add function to adjust and restore PLE quota

PLE RX quota, which is the setting of RX buffer, is needed to be adjusted
dynamically for WoWLAN mode, and restored when back to normal mode.
The action is not needed for rtw8852c chip.

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-4-pkshih@realtek.com

wifi: rtw89: 8852b: rfk: add DPK

DPK is short for digital pre-distortion calibration. It can adjusts digital
waveform according to PA linear characteristics dynamically to enhance
TX EVM.

Do this calibration when we are going to run on AP channel. To prevent
power offset out of boundary, it monitors thermal and set proper boundary
to register.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221014060237.29050-2-pkshih@realtek.com

wifi: rtw89: 8852b: rfk: add TSSI

TSSI is transmitter signal strength indication, which is a close-loop
hardware circuit to feedback actual transmitting power as a reference for
next transmission.

When we setup channel to connect an AP, it does full calibration. When
switching bands or channels, it needs to reset hardware status to prevent
use wrong feedback of previous transmission.

To do TX power compensation reflecting current temperature, it loads tables
of compensation values into registers according to channel and band group.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221012083234.20224-6-pkshih@realtek.com

wifi: rtw89: 8852b: add chip_ops::set_channel

set_channel is main function to configure channel and bandwidth for all
layers, namely MAC, BB and RF. Additionally, MAC layer enables CCK rate
checking to avoid wrong rate from driver. BB layer configures SCO
(Sample Clock Offset) for CCK, TX gain error/offset, and reset baseband
hardware circuit after all configurations done.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221005083212.45683-7-pkshih@realtek.com

wifi: rtw89: coex: move chip_ops::btc_bt_aci_imp to a generic code

This chunk is to set fixed BT LNA2 at level5 when WiFi/BT shared BTG RFC
to improve BT anti-interference ability from adjacent channel. Since all
chips use the same setting, remove chip_ops::btc_bt_aci_imp.

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/20221005083212.45683-2-pkshih@realtek.com

wifi: rtw89: 8852b: add chip_ops to read phy cap

This efuse region is to store PHY calibration, and it is a separated region
from the region that stores MAC address. Then, use these data to configure
via chip_ops::power_trim that is a calibration mechanism of TX power.

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-9-pkshih@realtek.com

wifi: rtw89: phy: make generic txpwr setting functions

Previously, we thought control registers or setting things for TX power
series may change according to chip. So, setting functions are implemented
chip by chip. However, until now, the functions keep the same among chips,
at least 8852A, 8852C, and 8852B. There is a sufficient number of chips to
share generic setting functions. So, we now remake them including TX power
by rate, TX power offset, TX power limit, and TX power limit RU as generic
ones in phy.c.

Besides, there are some code refinements in the generic ones, but almost
all of the logic doesn't change.

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-5-pkshih@realtek.com

wifi: rtw89: check DLE FIFO size with reserved size

For SCC mode, some FIFO are reserved, so compare the quantity after minus
the reserved size.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220927062611.30484-9-pkshih@realtek.com

wifi: rtw89: mac: correct register of report IMR

The register of report IMR is chip specific, so add a field to strut to
correct them.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220927062611.30484-8-pkshih@realtek.com

wifi: rtw89: 8852b: implement chip_ops::{enable,disable}_bb_rf

Implement to power on/off BB and RF via MAC registers.

Add return type of chip_ops::disable_bb_rf, because it could fail to
disable. Also, correct naming of register 0x0200 used by the ops 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/20220927062611.30484-5-pkshih@realtek.com

wifi: rtw89: mac: define DMA channel mask to avoid unsupported channels

Six channels are unsupported by 8852b, so mask them out to prevent to
access undefined registers in this chip.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220927062611.30484-3-pkshih@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

wifi: rtw89: coex: add logic to control BT scan priority

Add control logic to operate Wi-Fi to BT scoreboard to control BT scan
priority. And patch mechanism parameter to enhance Wi-Fi throughput while
coexisting with BT profile & BT scan. Set PTA priority let Wi-Fi BT can RX
at the same time.

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/20220920010939.12173-9-pkshih@realtek.com

wifi: rtw89: coex: summarize Wi-Fi to BT scoreboard and inform BT one time a cycle

If Wi-Fi driver send Wi-Fi status to BT via scoreboard too frequent in a
short moment, BT will loss some of them because of hardware response time.
To avoid this issue, change the code flow. Summarize the scoreboard changes
and if the value have changed, send the scoreboard to BT only once in
a coexistence processing cycle. It also can help to reduce driver I/O.

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/20220920010939.12173-8-pkshih@realtek.com

wifi: rtw89: coex: modify LNA2 setting to avoid BT destroyed Wi-Fi aggregation

To prevent LNA2 change its gain during a Wi-Fi aggregation packet while
GNT_BT pull high. Otherwise, changes of this gain will destroy the whole
aggregation when Wi-Fi RX.

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/20220920010939.12173-7-pkshih@realtek.com

wifi: rtw89: coex: add v1 Wi-Fi firmware steps report

This report is to record firmware call flow like notify events, and take
actions. This can help to address if firmware flow is in expectation.
Implement v1 parser to support 8852CE firmware report.

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/20220920010939.12173-5-pkshih@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 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

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

wifi: rtw89: support for setting TID specific configuration

Add ops set_tid_config to support TID specific configuration.
We currently only support ampdu setting.

The command example is:
iw wlan0 set tidconf tids 0x3 ampdu off
iw wlan0 set tidconf peer xx:xx:xx:xx:xx:xx tids 0x2 ampdu on

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-3-pkshih@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

wifi: rtw89: coex: Combine set grant WL/BT and correct the debug log

To reduce register IO, combine set_gnt_wl/set_gnt_bt to set the same
register one time. Because RTL8852C use different register to control
antenna path, so make correction of path control related debug logs.

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-8-pkshih@realtek.com

wifi: rtw89: coex: Move coexistence firmware buffer size parameter to chip info

Because RTL8852A/RTL8852C use different firmware buffer size to
send C2H packet, it's necessary to use different size to parse C2H report.

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-4-pkshih@realtek.com

wifi: rtw89: coex: Add v1 Wi-Fi firmware power-saving null data report

The later version Wi-Fi firmware will report null data TX times,
so the structure is different from before.

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-3-pkshih@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

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

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

wifi: rtw89: set response rate selection

With suitable response rate, it can acknowledge peer packets are received.
Otherwise, peer could re-transmit again due to missing of ACK frames.
To achieve this, refer to RX rate and CMAC table to choose the smaller
as initial response rate.

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/20220908051257.25353-6-pkshih@realtek.com

wifi: rtw89: add DIG register struct to share common algorithm

Since control register address for DIG are different per IC, add a new
struct rtw89_dig_regs in chip info for each IC to define their own address.

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/20220908051257.25353-2-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-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220908074140.39776-6-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 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

wifi: rtw89: parse phycap of TX/RX antenna number

Two fields, TX/RX ANT NUM, are introduced to address variant TX/RX antenna
number of hardware. For example, a 1x1 chip with TX diversity, TX NSS = 1
and TX/RX ANT NUM = 2.

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-3-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 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

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

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

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

rtw89: coex: Update Wi-Fi driver/firmware TDMA cycle report for RTL8852c

Because RTL8852c firmware handshake use different structure definition
with RTL8852a, so it's necessary to update a version for RTL8852c.

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-10-pkshih@realtek.com

rtw89: coex: Add v1 Wi-Fi SCC coexistence policy

Because the later firmware had patched some new feature, it can control
the Wi-Fi/BT slots more efficiently. This patch enhance it for better
Wi-Fi SCC mode performance.

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-9-pkshih@realtek.com

rtw89: coex: Move _set_policy to chip_ops

Due to the difference of Wi-Fi firmware supported feature, RTL8852C
need to defined more policy to enable the features.
(Ex: DBCC, Wi-Fi multi-role, TDMA instant and so on)

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-8-pkshih@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

rtw89: coex: Add v1 version TDMA format and parameters

RTL8852C use a later version Wi-Fi firmware, there are some parameters
need to be defined. These new parameter can avoid some unexpected
TDMA mode while Wi-Fi enter/leave lps.

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-6-pkshih@realtek.com

rtw89: coex: Add logic to parsing rtl8852c firmware type ctrl report

Add a part of logic to parse type of ctrl report from firmware, and
remove Bluetooth packet counter count from driver, the feature was
moved to firmware at rtl8852c.

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-4-pkshih@realtek.com

rtw89: coex: Move Wi-Fi firmware coexistence matching version to chip

To configure the different chips with different coexistence version,
separated the firmware feature version matching number is necessary.

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-3-pkshih@realtek.com

rtw89: coex: update radio state for RTL8852A/RTL8852C

Update scoreboard setting to let Bluetooth know Wi-Fi power save state.

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-2-pkshih@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

wifi: rtw89: declare support for mac80211 chanctx ops by chip

Some HW features are required if we hook chanctx ops to mac80211. With it,
mac80211 would expect the HW-supported variant ops exists on some behavior,
e.g. HW scan. But, HW features may depend on chip's FW or its development.
Besides, how many chanctx can be supported also depends on chip design.
We can neither decide whether to generally support chanctx ops nor how many
chanctx can be supported.

So, support_chanctx_num is added under chip info to deal with this by chip.
For now, all chip configure support_chanctx_num as 0. We haven't really
hook chanctx ops yet. So, chip can run without mac80211 chanctx as before.

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-13-pkshih@realtek.com

wifi: rtw89: add skeleton of mac80211 chanctx ops support

Support mac80211 chanctx series ops. Still, currently support
single channel. Based on this premise, things should be similar
to before. So, we haven't dealt with relationship between vif
and chanctx in depth. Instead, we leave both ::assign_vif()
and ::unassign_vif() as noops for now.

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-12-pkshih@realtek.com

wifi: rtw89: introduce entity mode and its recalculated prototype

After supporting more than one channel, we need entity mode to decide
how to set current channel(s) on the sub-entities. This decision may
happen on set_channel() and rtw89_core_set_chip_txpwr().

For now, we support single one channel and use only first HW entry,
i.e. RTW89_SUB_ENTITY_0, RTW89_MAC_0, RTW89_PHY_0. Without something
unexpected, the entity mode should always be RTW89_ENT_MODE_SCC after
recalcated, where SCC means single channel concurrency. So, an assert
is added in set_channel() and rtw89_core_set_chip_txpwr().

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-11-pkshih@realtek.com

wifi: rtw89: initialize entity and configure default chandef

While idle, we need a default chandef to set channel for things,
such as scan. Before support of mac80211 chanctx, mac80211 would
configure a default one on ieee80211_hw::conf::chandef. And we
just queried it whenever we did set channel. However, after support
of mac80211 chanctx, the flow won't work like before.

Besides, we don't now query chandef from ieee80211_hw::conf::chandef
either. So, similar to mac80211 without using chanctx, we configure
the default chandef with ieee80211_channel of index 0 in 2GHz.

Although we have not added the support of mac80211 chanctx here,
this configuration should be compatible before that. So, we commit
this 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/20220809104952.61355-10-pkshih@realtek.com

wifi: rtw89: concentrate chandef setting to stack callback

Originally, we didn't support mac80211 chanctx, so it's expected that
ieee80211_hw::conf::chandef would be filled by mac80211. And then, we
could just query it whenever we need the current chandef.

However, we are planing to support mac80211 chanctx. After that, the
above assumption would be broken. So, we adjust a bit ahead to reduce
future works about mac80211 chanctx.

After this, we don't query ieee80211_hw::conf::chandef directly, and
we add a map, entity_map, to HAL to indicate which chandef came from
stack. And it will later be used to recalcate entity mode.

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-9-pkshih@realtek.com

wifi: rtw89: concentrate parameter control for setting channel callback

For future support on multiple channels by multiple sub-entities,
we need to manage parameters of each channel instance like rtw89_chan,
rtw89_mac_idx, rtw89_phy_idx. So, we adjust related channel callback
functions and centrally conrtol these parameters in set_channel().

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-8-pkshih@realtek.com

wifi: rtw89: rfk: concentrate parameter control while set_channel()

For future support on multiple channels, there will be settings of
multiple sub-entities that we need to control. We don't want such
settings to be scattered all over the place. So, we centrally manage
controls of rtw89_phy_idx for RFK in set_channel().

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-7-pkshih@realtek.com

wifi: rtw89: txpwr: concentrate channel related control to top

For future support on multiple channels, it would be disturbing if we
still allow scattered leaf functions of TX power to query and manage
channel related control by themselves.

So, query rtw89_chan only on top functions. Then, pass it via functions
to make sure that the values coming from the same struct rtw89_chan.

Besides, fix rtw8852a_set_txpwr_offset() from rtw8852a_set_txpwr_ctrl()
to rtw8852a_set_txpwr(). TX power offset should consider current band,
so move it to chip_ops::set_txpwr() which will be called every time that
channel is set.

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-6-pkshih@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

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

wifi: rtw89: introduce rtw89_chan for channel stuffs

Introduce struct rtw89_chan ahead to encapsulate stuffs from struct
rtw89_channel_params. These stuffs have a clone in HAL and are used
throughout driver. After multiple channels support, it's expected that
each channel instance has a configuration of them. So, we refine them
with struct rtw89_chan by precise type first, and will re-arrange HAL
by struct rtw89_chan in the following as well.

(No logic has changed.)

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-3-pkshih@realtek.com

wifi: rtw89: rewrite decision on channel by entity state

We need to invoke the callback of the changed band at the first
set_channel() after every power-off. Originally, we forced the
channel to be 0 when doing power-off, and then determined things
by comparing channel with 0.

However, deciding on such things by channel might be confusing.
It's also confusing to use this kind of decision when we consider
multiple channels in the follow-up patches. So, another flag,
entity_active, is added ahead to HAL to deal with this.

Besides, we also need to check if entity is active when we set
TX power.

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-2-pkshih@realtek.com

wifi: rtw89: drop invalid TX rate report of legacy rate

Somehow, firmware could report invalid TX rate, and we consider the
invalid rate as 0 that will make a wrong decision. So, drop invalid
reports, and also suppress the warning message.

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-9-pkshih@realtek.com

wifi: rtw89: enable VO TX AMPDU

To improve VO throughput, we enable VO TX AMPDU.

We measure the latency of enable or disable VO TX AMPDU. The experimental
results show that the difference between the two is insignificant only
300µs, so the little impact can be ignored for user experience.

Moreover, we found some APs will have a group key handshake timeout issue
when the EAPOL's TID is already setup BA session. Therefore, when
transmitting EAPOL, if EAPOL's TID BA session is already setup, we need
to delete it.

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/20220610072610.27095-7-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

wifi: rtw89: allocate address CAM and MAC ID to TDLS peer

Normally, we only allocate an address CAM and single one MAC ID to AP in
STA mode. To support TDLS, we handle TDLS peers like AP handles stations.

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-2-pkshih@realtek.com

wifi: mac80211: move interface config to new struct

We'll use bss_conf for per-link configuration later, so
move out all the non-link-specific data out into a new
struct ieee80211_vif_cfg used in the vif.

Some adjustments were done with the following spatch:

@@
expression sdata;
struct ieee80211_vif *vifp;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
(
-sdata->vif.bss_conf.var
+sdata->vif.cfg.var
|
-vifp->bss_conf.var
+vifp->cfg.var
)

@bss_conf@
struct ieee80211_bss_conf *bss_conf;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
-bss_conf->var
+vif_cfg->var

(though more manual fixups were needed, e.g. replacing
"vif_cfg->" by "vif->cfg." in many files.)

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

rtw89: add new state to CFO state machine for UL-OFDMA

Add an new state, RTW89_PHY_DCFO_STATE_HOLD, to keep CFO acceleration
after CFO_PERIOD_CNT if the traffic is UL-OFDMA, which is calculated
based on RX trigger frame counter.

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/20220608113224.11193-4-pkshih@realtek.com

rtw89: 8852c: add trigger frame counter

Adding this allows us to maintain trigger frame statistics, which is
required for our CFO tracking decisions.

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/20220608113224.11193-3-pkshih@realtek.com

rtw89: sar: adjust and support SAR on 6GHz band

Since SAR is more expected to follow U-NII bands to plan subbands,
division of 6GHz band is quite different from defined enum of subbands
which is used by PHY in most cases. It's hard and painful if we want to
keep using the same enum on SAR. So, we introduce another enum for SAR
subbands and adjust SAR flow to use it.

Besides, since 6GHz SAR subbands won't be divided with edge alignment,
some cases will span two SAR subbands. For these cases, we describe them
within an array of rtw89_sar_span and take the smaller one between SAR
settings of the two subbands.

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/20220520071731.38563-6-pkshih@realtek.com

rtw89: 8852c: rfk: re-calibrate RX DCK once thermal changes a lot

RX DCK is receiver DC calibration. To keep good RF performance, do this
calibration again if the delta of thermal value from the last calibration
is more than 8.

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-5-pkshih@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

rtw89: 8852c: rfk: add DPK

DPK is short for digital pre-distortion calibration. It can adjusts digital
waveform according to PA linear characteristics dynamically to enhance
TX EVM.

Do this calibration when we are going to run on AP channel. To prevent
power offset out of boundary, it monitors thermal and set proper boundary
to register.

8852c needs two backup buffers, so we enlarge the array. But, 8852a still
needs only one, so it only uses first element (index zero).

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220502235408.15052-9-pkshih@realtek.com

rtw89: 8852c: rfk: add IQK

IQ signal calibration is a very important calibration to yield good RF
performance. We do this calibration only if we are going to run on AP
channel. During scanning phase, without this calibration RF performance
is still acceptable because it transmits with low data rate at this phase.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220502235408.15052-8-pkshih@realtek.com

rtw89: 8852c: rfk: add LCK

LCK is short fro LC Tank calibration. Do this calibration once driver
loads RF parameters table. Since the characteristic can be changed by
temperature, we do this calibration again if difference of thermal value
is over a threshold.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220502235408.15052-4-pkshih@realtek.com

rtw89: 8852c: configure default BB TX/RX path

8852c propose new API to configure BB TX/RX path. Without fix patch, it
can't transmit any packet.

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-11-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

rtw89: don't flush hci queues and send h2c if power is off

When disconnecting, it warns somethings after power is off, and we can't
do HCI IO. So, add this patch to avoid below messages:

rtw89_8852ce 0000:03:00.0: timed out to flush pci txch: 11
rtw89_8852ce 0000:03:00.0: failed to pre-release fwcmd

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-9-pkshih@realtek.com

rtw89: ps: access TX/RX rings via another registers in low power mode

In low power mode, we need to pause PCI to configure IMR and PCI ring
index registers accordingly, because the regular registers are power-off
in this mode.

In the transition moment named paused in code, we can't touch ring index,
so don't kick off DMA immediately. Instead, queue them into pending queue,
and kick off after the moment.

There are three low power modes, which are RF off/clock gate/power gate,
but PCI enter low power mode in later two modes only. So, add a mask
to achieve this.

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-7-pkshih@realtek.com

rtw89: 8852c: add efuse gain offset parser

Define efuse struct to access gain offset, and store them for further use
by setting channel.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220414062027.62638-8-pkshih@realtek.com

rtw89: 8852c: support bb gain info

Add parser for bb gain table and configure bb gain table for 8852c.
While ctrl_ch, obtain bb gain error settings and write them to phy.

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/20220414062027.62638-7-pkshih@realtek.com

rtw89: 8852c: phy: configure TSSI bandedge

TSSI is used to manage TX power with thermal value as a factor. This patch
is to configure bandedge to TX proper waveform.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220414062027.62638-5-pkshih@realtek.com

rtw89: 8852c: add TX power by rate and limit tables

TX power depends on rate, but must follow regulation for specific country.
Once asked to set channel, we configure registers according to these TX
power tables.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220414062027.62638-3-pkshih@realtek.com

rtw89: 8852c: add BB and RF parameters tables

These parameters are used to initialize BB and RF hardware when we are
going to bring up interface and start to transmit and receive.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220414062027.62638-2-pkshih@realtek.com

rtw89: configure security CAM for V1 chip

Add to configure security CAM while mac80211 calls set_key and del_key.

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-4-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

rtw89: rtw89_ser: add const to struct state_ent and event_ent

Change the struct and the uses to const to reduce data.

$ size drivers/net/wireless/realtek/rtw89/ser.o* (x86-64 defconfig w/ rtw89)
text data bss dec hex filename
3741 8 0 3749 ea5 drivers/net/wireless/realtek/rtw89/ser.o.new
3437 312 0 3749 ea5 drivers/net/wireless/realtek/rtw89/ser.o.old

Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/2fd88e6119f62b968477ef9781abb1832d399fd6.camel@perches.com

rtw89: ser: configure C-MAC interrupt mask

Similarly, create functions to set specific C-MAC masks for firmware
recovery.

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/20220408001353.17188-4-pkshih@realtek.com

rtw89: ser: configure D-MAC interrupt mask

These interrupts are used by firmware to recover hardware. Create
functions to set specific D-MAC masks to replace plain register settings.

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/20220408001353.17188-3-pkshih@realtek.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>

rtw89: add chip_ops::{enable,disable}_bb_rf to support v1 chip

The v1 chip use specific functions to enable and disable BB/RF.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220325060055.58482-11-pkshih@realtek.com

rtw89: support hardware generate security header

The newer chip will generate security header itself, so don't set
IEEE80211_KEY_FLAG_GENERATE_IV in this kind of chip. But, it needs to fill
key_index, PN and 802.11 header length to TX descriptor, and then hardware
uses these to generate security header.

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-11-pkshih@realtek.com

rtw89: support variant of fill_txdesc

The txdesc is descriptor related to skb->data. The v1 version contains
8 dwords txwd_body and 6 dwords txwd_info, and the format is also different
from original one.

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-10-pkshih@realtek.com

rtw89: pci: support variant of fill_txaddr_info

The txaddr_info is used to fill the DMA address of skb->data. The v1
version can support up to 10 entries, but the maximum size of each entry
is 2047, so it fill more than one entry for large packet, like 3000 bytes.

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-9-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

rtw89: disabled IGI configuration for unsupported hardware

Bypass IGI, known as Rx gain, adjustment flow for incompatible hardware
architectures.

Signed-off-by: Johnson Lin <johnson.lin@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/20220318023214.32411-7-pkshih@realtek.com

rtw89: add UK to regulation type

Add RTW89_UK to enum rtw89_regulation_type.
The follow-up commit will configure the corresponding values for it
to TX power tables.

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/20220318023214.32411-2-pkshih@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

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

rtw89: ser: dump memory for fw payload engine while L2 reset

When FW encounters exception or assertion, SER L2 reset process will start.
It will dump some error information and re-download FW eventually. Since
such errors are usually critical, we would like to keep more information
about error to increase possibility of analysis and debugging FW. We first
add FW payload engine (fw reserved playoad engine, fw_rsvd_ple) memory
dump. FW will record things like CPU registers, backtrace entry, etc. in it
for debugging.

Moreover, device core dump framework is used and wrapped to collect kinds
of dumps during SER L2 reset process.

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-6-pkshih@realtek.com

rtw89: ser: control hci interrupts on/off by state

While SER (system error recover) is processing, it's supposed to mean
something is under recovery. So, disable interrupts (excluding the one
of halt which could be used during SER) to avoid unexpected behavior.
And then, enable interrupts after SER is 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-5-pkshih@realtek.com

rtw89: implement stop and resume channels transmission v1

These function is used to stop transmitting when we are going to switch
channels or do some RF calibration. Before these operations, we need to
stop channel transmission and backup setting into parameter tx_en. After
operations are done, resume transmitting by backup parameter tx_en.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220317055543.40514-13-pkshih@realtek.com

rtw89: extend mac tx_en bits from 16 to 32

In order to support 8852C that uses 32 bits to control TX types.

This patch doesn't really use 32 bits tx_en yet, but next patch will
use it.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220317055543.40514-12-pkshih@realtek.com

rtw89: 8852c: add mac_ctrl_path and mac_cfg_gnt APIs

The BT-coexistence uses these function to control antenna and TDMA, so
implement the variant type to support all chips.

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/20220317055543.40514-10-pkshih@realtek.com

rtw89: add config_rf_reg_v1 to configure RF parameter tables

The format of RF parameter is changed; it doesn't encode delay parameters
into table, but the delay coding becomes regular pair of register address
and value.

To help firmware to recover RF register settings, we need to download
these parameters to firmware. For v1 format, only download partial
parameters (ignore them with addr < 0x100).

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220317055543.40514-6-pkshih@realtek.com

rtw89: 8852c: add setting of TB UL TX power offset

Configure this TX power to indicate TX power offset that uses to transmit
TB (trigger base) uplink frames.
Also, shrink the unit of TX power offset changes to suitable type s8.

Signed-off-by: Yuan-Han Zhang <yuanhan1020@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/20220317055543.40514-4-pkshih@realtek.com

rtw89: modify dcfo_comp to share with chips

The dcfo_comp is digital CFO (central frequency offset) compensation.
Since the flow can be shared with all chips, add chip parameters to support
variant register address and format.

Signed-off-by: Yuan-Han Zhang <yuanhan1020@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/20220317055543.40514-2-pkshih@realtek.com

rtw89: 8852c: process efuse of phycap

Read phycap data programmed in efuse, and store them into array.

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-13-pkshih@realtek.com

rtw89: support DAV efuse reading operation

DAV is an another efuse region that new chip, like 8852C, has this region.
Extend the code to read it, and convert the physical map to logical map
followed by original logical map.

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-12-pkshih@realtek.com

rtw89: 8852c: add chip::dle_mem

These tables are used to configure hardware buffer size according to
operating mode.

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-11-pkshih@realtek.com

rtw89: add page_regs to handle v1 chips

These registers are used to configure and access page size of HCI.

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-10-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

rtw89: add hci_func_en_addr to support variant generation

The HCI_FUNC_EN address of 8852C is different from existing chipset, so
add a chip_info::hci_func_en_addr to fill the address individually.

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-8-pkshih@realtek.com

rtw89: add power_{on/off}_func

New chipset uses individual power_{on/off} functions to replace old power
sequences, because it is hard to represent new complicated flow in a
sequence table.

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-7-pkshih@realtek.com