wifi: rtw89: wow: update config mac function with different generation

The registers to configure mac function for WoWLAN mode that are different
from different generation, so update them.

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-5-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: fw: implement MRC H2C command functions

Implement MRC (multiple role concurrent) H2C commands. Mainly deal with
H2C format, LE type built from CPU value, default setting on some fields,
and then sending the command to FW. Besides, MRC start, MRC delete, and
MRC request TSF need to wait for a report from C2H events.

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

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: fw: add definition of H2C command and C2H event for MRC series

For Wi-Fi 7 chips, FW supports MRC (multi-role concurrent) functions
including H2C commands and C2H events. We can consider FW MRC functions
as a superset of FW MCC (multi-channel concurrent) functions. And, MRC
functions can take MLO things into account.

Basically before MLO, SW can also manipulate FW MRC to work original
SW MCC flow. So, we add them first and implement the handling in the
following. And then, SW MCC will call different series of FW functions
according to chip later.

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

wifi: rtw89: fw: download firmware with key data for secure boot

Since firmware header contains multiple secure sections, we need to trim
ignored sections, and then download firmware header with single one secure
section.

For secure boot, when downloading secure section, copy security key data
from MSS poll by key_idx read from efuse. If non-secure boot, no need this
extra copy.

+---------------------------+ -\
| firmware header | |
| | |
| +-----------------------+ | | only preserve single one secure
| | section type/size * N | | | section
| | ... | | |
| +-----------------------+ | |
+---------------------------+ -/
: :
+---------------------------+ -\
| secure section type (ID:9)| |
| | |
+----|-> [ security key data ] | |
| +---------------------------+ -/
| |MSS Pool for above section |
| | [ security key data 0 ] |
+----|- [ security key data 1 ] |
by key_idx | [ security key data 2 ] |
| ... |
+---------------------------+

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

wifi: rtw89: fw: parse secure section from firmware file

A firmware file can contains more than one section with secure type, so
use secure information from efuse to choose the one with matched
cryptography method. Then choose key data from MSS poll (multiple security
section pool; see below picture) according to key_index from efuse.

Note that the size of MSS pool isn't included in section size defined
in firmware header, so we also need to parse header of MSS pool to get
its size as shift to parse next section.

If secure boot isn't supported by current hardware, the first secure
section will be adopted, and no need additional process to key data.

+---------------------------+
| firmware header |
| |
| +-----------------------+ |
| | section type/size * N-|-|-------+
| | ... | | |
| +-----------------------+ | |
+---------------------------+ |
: : |
+---------------------------+ -\ |
| secure section type (ID:9)| | |
| | | <--+
| | |
+---------------------------+ -/
|MSS Pool for above section |
| |
| |
+---------------------------+

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

wifi: rtw89: fw: consider checksum length of security data

The newer firmware file provides security data with checksum, so we need to
consider the length. Otherwise it will fail to validate total firmware
length resulting in failed to probe.

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

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: add H2C command to trigger TXGAPK

TXGAPK stands for TX power gap calibration. Use this calibration to
compensate TX power gap to output expected power.

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

wifi: rtw89: rfk: add H2C command to trigger DACK

DACK (digital-to-analog converters calibration) is used to calibrate DAC
to output signals with expected quality.

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

wifi: rtw89: rfk: add H2C command to trigger DPK

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

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

wifi: rtw89: rfk: add H2C command to trigger RX DCK

RX DCK is receiver DC calibration. This will calibrate DC offset to
reflect correct received signal strength indicator, so mechanisms like CCA
can have normalized values.

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

wifi: rtw89: rfk: add H2C command to trigger IQK

IQ signal calibration is a basic and important calibration to yield good RF
performance. Do this calibration on AP channel if we are going to connect.
During scanning phase, it transmits with low data rate, so without IQK
RF performance is still acceptable.

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

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 more fields to beacon H2C command to support multi-links

To support multi-links beacon, it needs more fields. But currently we still
only support legacy AP mode. Only update struct to fit expected size of
firmware.

Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240126063356.17857-8-pkshih@realtek.com

wifi: rtw89: add new H2C for PS mode in 802.11be chip

Because 802.11be chip support MLO mode, driver needs to send new H2C to
pass more connected channel information to firmware, to ensure PS mode
work fine.

Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240126063356.17857-6-pkshih@realtek.com

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: prepare scan leaf functions for wifi 7 ICs

The channel field slightly differs between WiFi 6 and WiFi 7.
So we prepare some required functions in advance, this doesn't change
existing wifi 6 ICs behavior. This H2C prepares the channel list
to be scanned for. With layout as the following:

+--------+--------------------+-------------------+-----------------------+
| header | number of channels | channel info size | channel_info * number |
+--------+--------------------+-------------------+-----------------------+

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

wifi: rtw89: debug: add FW log component for scan

This allows scan related logs when FW log debug mode is on.

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

wifi: rtw89: update scan C2H messages for wifi 7 IC

Add definition and parsing for wifi 7 extended fields. These fields
include hardware index which is current reporting, timestamp and self
defined sequences for debug purposes.

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

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: Set default CQM config if not present

When wpa_supplicant is initiated by users and not by NetworkManager,
the CQM configuration might not be set. Without this setting, ICs
with connection monitor handled by driver won't detect connection
loss. To fix this we prepare a default setting upon associated at
first, then update again if any is given later.

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

wifi: rtw89: refine hardware scan C2H events

Define struct for scan offload C2H events and update each elements'
bitfield. This patch does not change original behavior, just style
conversion and naming changes.

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

wifi: rtw89: refine add_chan H2C command to encode_bits

Use struct filling style instead of pointer casting.
This does not change the original behavior.

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

wifi: rtw89: fw: extend JOIN H2C command to support WiFi 7 chips

WiFi 7 chips will support MLD, so there are more fields about that. But
currently we don't support MLD yet, just define fields and bits by this
patch ahead, and fill STA_TYPE only.

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

wifi: rtw89: fw: use struct to fill JOIN H2C command

The JOIN command is used to tell firmware an new station is joining, and
create an entry for it. This patch is only to convert to set data via
struct, and don't change logic at all.

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

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: fw: add H2C command to update security CAM v2

To have secure connection, set key information into security CAM including
key index, entry index and valid map. This new introduced H2C command can
support MLO, but currently not implement yet.

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

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 H2C command to download beacon frame for WiFi 7 chips

The firmware of coming WiFi 7 chips can support more AP functions, like
virtual AP, so extend format of download beacon frame to configure them.
Currently rtw89 only enables AP mode as old chips, so leave new fields
zeros.

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

wifi: rtw89: use struct to fill H2C command to download beacon frame

Download beacon frame via H2C command for AP mode, and then firmware can
issues beacon periodically. Originally TIM offset minus fixed 24 bytes of
frame header implicitly in macro, and this patch explicitly uses
ieee80211_hdrlen() to get header length, but expected to change nothing
at all.

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

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: fw: use struct to fill BA CAM H2C commands

The WiFi 6 chips use these commands to create BA CAM entry when RX BA
session is established, this BA CAM can record whether packets are received
or not, then reply BA for current status. This patch doesn't change logic.

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

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: mac: add feature_init to initialize BA CAM V1

Add a call of feature_init() when bringing interface up. For now, the
feature is to reset BA CAM V1 that is only used by upcoming 8922A.

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

wifi: rtw89: add firmware H2C command of BA CAM V1

BA CAM is used to generate BA frame for received AMPDU packets. To support
WiFi 7, change format from V0 to have more fields and enlarge entry number
for new need.

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

wifi: rtw89: add DBCC H2C to notify firmware the status

To support MLO of WiFi 7, we should configure hardware as DBCC mode, and
notify this status to firmware.

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

wifi: rtw89: phy: print out RFK log with formatted string

With formatted string loaded from firmware file, we can use the formatted
string ID and get corresponding string, and then use regular rtw89_debug()
to show the message if debug mask of RFK is enabled.

If the string ID doesn't present, fallback to print plain hexadecimal.

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

wifi: rtw89: parse and print out RFK log from C2H events

RFK log events contains two types. One called RUN log is to reflect state
during RFK is running, and it replies on formatted string loaded from
firmware file, but print this type as plain hexadecimal only in this patch.
The other is REPORT log that reflects the final result of a RFK, and
each calibration has its own struct to carry many specific information.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231213005054.10568-6-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: add version field to BB MCU firmware element

8922AE has more than one hardware version, and they use different BB MCU
firmware, so occupy a byte from element priv[] to annotate version. Since
there are more than one firmware and only matched version is adopted,
return 1 to ignore not matched firmware.

+===========================================+
| elm ID | elm size | version | |
+----------+----------+----------+----------+
| | element_priv[] |
+-------------------------------------------+

change to |
v

+===========================================+
| elm ID | elm size | version | |
+----------+----------+----------+----------+
| | cv | element_rsvd[] |
+-------------------------------------------+

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

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: configure CRASH_TRIGGER FW feature

RTL8922A FW supports CRASH_TRIGGER feature from v0.34.30.0.
After it, debugfs fw_crash can accept type 1 on RTL8922A to
trigger firmware crash and verify L2 recovery.

Besides, RTL8922A sync address offset of reserved payload engine.
And, SER (system error recovery) tweaks conversion from WCPU address
to indirect access address for RTL8922A. The new conversion works
for all supported chips.

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

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: 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: 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: fw: move polling function of firmware path ready to an individual function

To download firmware, we need to check path is ready. There are two kinds
of path -- one is to download firmware header, and the other is to download
firmware body.

Since the polling method is different from WiFi 7 chips, make it to be
an individual function, and then we can reuse the download flow.

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

wifi: rtw89: fix typo of rtw89_fw_h2c_mcc_macid_bitmap()

Fix a typo where `bitamp` should be `bitmap`. Don't change functionality
at all.

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

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: introduce infrastructure of firmware elements

In order to pack more data into firmware file, we introduce firmware
elements and append BB_MCU firmware first. The first part of new firmware
file is still unchanged firmware of WiFi CPU, so the new firmware format
can be backward compatible to old format. The new elements part consists
of ID and size basically, which can append more elements simply. To avoid
unaligned access in certain platform and be easy to read, headers of all
elements start at 16-byte aligned address.

+===========================================+
| original firmware |
| +-------------+
| | padding |
+===========================================+
| elm ID 1 | elm size | other header data |
+----------+----------+ |
| |
+-------------------------------------------+
| content (variable length) |
| +-------------+
| | padding |
+===========================================+
| elm ID 2 | elm size | other header data |
+----------+----------+ |
| |
+-------------------------------------------+
| content (variable length) |
| +-----------------------+
| | (no padding for the last one)
+===================+

More detail of element header is shown below. The additional fields
'version' and 'element_priv[]' are meta data of elements, so that we can
know element version easily, and element_priv[] provide specific fields
for certain element, such as RF path index for RF parameter tables.

+===========================================+
| elm ID | elm size | version | rsvd0 |
+----------+----------+----------+----------+
| rsvd1/2 | element_priv[] |
+-------------------------------------------+

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

wifi: rtw89: add firmware parser for v1 format

A firmware with v1 format contains many sections to download. Add parser to
read section type, target address, length, checksum and so on, and then
download the section to WiFi CPU with proper location.

The additional dynamic header length named dynamic_hdr_len is used to
skip content of dynamic header containing compiler flags of firmware, which
can help to determine variant firmware build, but currently rtw89 only
use single one variant. So, just skip the content.

The layout of a WiFi CPU firmware with v1 format looks like:

+---------------------------------------+
| Header (12 words) |
+---------------------------------------+
| Section header 1 (4 words) |
| Section header 2 (4 words) |
| Section header 3 (4 words) |
| ... |
+---------------------------------------+
| Dynamic header (variable length) |
+---------------------------------------+
| Data used & pointed by section |
| ... |
+---------------------------------------+

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

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: 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: use struct to access RA report

RA (rate adaptive), a mechanism to select proper rate, is implemented in
firmware, and this report is used to tell driver TX rate it is currently
using. Use struct to access this report, and doesn't change logic at all.

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

wifi: rtw89: use struct to access firmware C2H event header

Firmware C2H events contain two-word header which can indicate category,
class, function and length of received events. Use struct to access them,
and doesn't change logic at all.

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

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: use struct to set RA H2C command

RA (rate adaptive) H2C command is used to tell firmware which rates can
be used for specified MAC ID. Basically, this commit doesn't change result.
Only change to set two 32-bit instead of continual 8-byte rate masks one
by one. Originally, we only set 5-byte masks, because existing WiFi 6
2SS chips only need 5-byte masks. Setting two 32-bit masks will be more
efficient and also can support coming WiFi 7 2SS chips containing more
rates.

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

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: 8851b: enable hw_scan support

This enables hw_scan for 8851b after firmware version 0.29.37.1.
Extend the channel info struct with padding zeros so newer firmware
can work properly, this change is backward compatible with older
firmware.

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

wifi: rtw89: use struct to access register-based H2C/C2H

The register-based H2C/C2H are used to exchange commands and events with
firmware. The exchange data is limited, but it is relatively simple,
because it can work before HCI initialization. To make these code clean,
use struct to access them. This patch doesn't change logic at all.

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

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: scan offload wait for FW done ACK

The following are scan offload related H2C (host to chip) function types.
* H2C_FUNC_ADD_SCANOFLD_CH
* H2C_FUNC_SCANOFLD
Before doing FW scan, we will continuously send multiple H2Cs with above
types which are used to tell FW the scan configuration of this time. But,
if FW doesn't handle one of these H2Cs well, the FW scan process might
not run as expected and driver should notice it early.

So, this commits makes scan offload related H2Cs wait for FW done ACK via
rtw89_wait_for_cond() and rtw89_complete_cond(). And, we check the return
code of these H2Cs from FW.

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

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: update statistics to FW for fine-tuning performance

Since firmware can't have proper statistics, driver update the
statistics periodically to firmware to assist in tuning performance.

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

wifi: rtw89: use struct instead of macros to set H2C command of hardware scan

Remove macros that set H2C data. Instead, use struct and
le32_encode_bits() with mask definition to make it clean.

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

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: 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: fw: use generic flow to set/check features

In early feature bitmap obtained from rtw89_early_fw_feature_recognize(),
the bits needed to check get increased. It's more friendly to work with
RTW89_CHK_FW_FEATURE(). So, we concentrate the flow of iterating FW feature
configures and calling RTW89_SET_FW_FEATURE() for various uses. And then,
we adjust rtw89_early_fw_feature_recognize() for RTW89_CHK_FW_FEATURE().

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

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: 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: add RNR support for 6 GHz scan

Since 6 GHz band has around 60 channels and more strict rules for
active probing. Reduced neighbor report can be used to reduce the
channels we scan and get specific target BSS info to probe for.

Declare flag WIPHY_FLAG_SPLIT_SCAN_6GHZ so the scan request could be
divided into two portions: legacy bands and 6 GHz bands. So RNR
information from legacy bands could later be used when 6 GHz scan.

When the scan flag NL80211_SCAN_FLAG_COLOCATED_6GHZ is set, cfg80211
will pass down a reduced channel set which contains PSCs and non-PSC
with RNR info received in the 2 GHz/5 GHz band. This reduces the
scan duration by allowing us to only scan for channels in which APs
are currently operating.

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

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: fix parsing offset for MCC C2H

A 8-byte offset is missed during parsing C2Hs (chip to host packets)
of MCC (multi-channel concurrent) series.
So, we fix it.

Fixes: ef9dff4cb491 ("wifi: rtw89: mac: process MCC related C2H")
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/20230119064342.65391-1-pkshih@realtek.com

wifi: rtw89: refine 6 GHz scanning dwell time

Reduce dwell time to improve scan duration in 6 GHz. This is required
for scan requests that does not include RNR parsing and does full
channel scan.

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

wifi: rtw89: fw: adapt to new firmware format of security section

Normally, system image should ensure firmware integrity, but we provide
an advance feature to ensure this by security section along with firmware.
To enable this feature, custom ID is programmed into efuse, and driver
will download proper security section to firmware.

Since I don't have this kind hardware modules on hand yet, but new format
is used by newer firmware. Therefore, I prepare this patch in advance to
consider size of security section as a factor of checking rule of firmware
size, but don't actually download security section to firmware.

This patch is backward compatible, so it will be safe to have this change
before adding an new format firmware to linux-firmware repository.

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

wifi: rtw89: request full firmware only once if it's early requested

Under some condition, we now have to do early request full firmware when
rtw89_early_fw_feature_recognize(). In this case, we can avoid requesting
full firmware twice during probing driver. So, we pass out full firmware
from rtw89_early_fw_feature_recognize() if it's requested successfully.
And then, if firmware is settled, we have no need to request full firmware
again during normal initizating flow.

Setting firmware flow is updated to be as the following.

platform | early recognizing | normally initizating
-----------------------------------------------------------------------
deny reading | request full FW | (no more FW requesting)
partial file | | (obtain FW from early pahse)
-----------------------------------------------------------------------
able to read | request partial FW | async request full FW
partial file | (quite small chunk) |

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

wifi: rtw89: don't request partial firmware if SECURITY_LOADPIN_ENFORCE

Kernel logs on platform enabling SECURITY_LOADPIN_ENFORCE
------
```
LoadPin: firmware old-api-denied obj=<unknown> pid=810 cmdline="modprobe -q -- rtw89_8852ce"
rtw89_8852ce 0000:01:00.0: loading /lib/firmware/rtw89/rtw8852c_fw.bin failed with error -1
rtw89_8852ce 0000:01:00.0: Direct firmware load for rtw89/rtw8852c_fw.bin failed with error -1
rtw89_8852ce 0000:01:00.0: failed to early request firmware: -1
```

Trace
------
```
request_partial_firmware_into_buf()
> _request_firmware()
>> fw_get_filesystem_firmware()
>>> kernel_read_file_from_path_initns()
>>>> kernel_read_file()
>>>>> security_kernel_read_file()
// It will iterate enabled LSMs' hooks for kernel_read_file.
// With loadpin, it hooks loadpin_read_file.
```

If SECURITY_LOADPIN_ENFORCE is enabled, doing kernel_read_file() on partial
files will be denied and return -EPERM (-1). Then, the outer API based on it,
e.g. request_partial_firmware_into_buf(), will get the error.

In the case, we cannot get the firmware stuffs right, even though there might
be no error other than a permission issue on reading a partial file. So we have
to request full firmware if SECURITY_LOADPIN_ENFORCE is enabled. It makes us
still have a chance to do early firmware work on this kind of platforms.

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

wifi: rtw89: fw: implement MCC related H2C

These MCC H2C(s) require to wait for MCC C2H to determine if the
execution is successful. Through rtw89_wait_for_cond(), we make
them wait for either a completion with data from MCC C2H handlers,
which calls rtw89_complete_cond(), or timeout.

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

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: check if atomic before queuing c2h

Before queuing C2H work, we check atomicity of the C2H's handler first now.
If atomic or lock-free, handle it directly; otherwise, handle it with mutex
in work as previous. This prepares for MAC MCC C2Hs which require to be
processed directly. And, their handlers will be functions which can be
considered atomic.

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

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 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: fw: adapt to new firmware format of dynamic header

Since firmware size is limited, we create variant firmwares for variant
application areas. To help driver to know firmware's capabilities, firmware
dynamic header is introduced to have more information, such as firmware
features and firmware compile flags.

Since this driver rtw89 only uses single one specific firmware at runtime,
this patch is just to ignore this dynamic header, not actually use the
content.

This patch can be backward compatible, and no this kind of firmware is
added to linux-firmware yet, so I can prepare this in advance.

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

wifi: rtw89: correct 6 GHz scan behavior

Change active scan behavior to fit 6GHz requirements. There are many
different rules on active scan between 6GHz and 2GHz/5GHz, so if the
SSID is not specified, do fast passive scanning and limit number of
probe requests we send for now until new firmware can support all
rules.

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

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: 8852c: support fw crash simulation

With FW >= v0.27.40.0, 8852C FW has feature to handle crash simulation.
Besides, use RTW89_WCPU_BASE_MASK to replace use of RTW89_WCPU_BASE_ADDR
and work for both 8852A and 8852C.

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

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 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: 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: configure TX path via H2C command

In order to support TX diversity, add a function to control TX path.

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

wifi: rtw89: use u32_get_bits to access C2H content of PHY capability

The definitions of bit fields in structure will be wrong in big-endian
platform, so use u32_get_bits() to access them.

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

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

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

rtw89: fix channel inconsistency during hw_scan

Previously channel maintained by driver could be different from the
ones hardware actually is. Restore these variables back to prevent
unexpected behavior.

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

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: add new H2C to configure security CAM via DCTL for V1 chip

DCTL is short for D-MAC control that V1 chip uses this H2C to configure
security CAM. Implement the callers in next patch.

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

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: 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: 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: ser: dump fw backtrace while L2 reset

Read FW backtrace entry through FW reserved payload engine, and then
add FW backtrace dump during SER (system error recover) L2 reset process.
It contains a list of RA (return address) and SP (stack pointer) which
gives us a chance to trace back the call stack of FW.

Moreover, if core dump might have wrong content due to error during
dumping, we won't invoke device core dump framework. For this case,
rtw89_ser_cd_free() is added to free buffer by ourselves.

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-7-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: 8852a: add ieee80211_ops::hw_scan

Declare this function allows us to use customized scanning policy, so
each scan takes less time. This is a similar implementation to hw_scan
in rtw88, except that we offload more items to firmware and extend the
maximum IE length. For backward compatibility, we fallback to sw_scan
when firmware does not support this feature.

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

rtw89: extend role_maintain to support AP mode

Fill mac_id and self_role depends on the operation mode.

In AP mode, echo connected station has an unique mac_id, and each vif also
has one mac_id to represent itself.

The self_role is assigned to vif if the operation mode is decided, and
RTW89_SELF_ROLE_AP_CLIENT is assigned to the connected STA in AP mode,

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

rtw89: rename vif_maintain to role_maintain

The H2C_FUNC_MAC_FWROLE_MAINTAIN also maintains the roles of all connected
stations; not just the role of VIF. So, I correct the name, but don't
change the logic at all.

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

rtw89: extend firmware commands on states of sta_assoc and sta_disconnect

The h2c_join firmware command is used to indicate a station is connected,
and the assoc_cmac_tbl firmware command is used to set CMAC table
corresponding to a mac_id. Both commands must work in both station and AP
modes. Use the mac_id of rtw89_sta naturally and intuitively.

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

rtw89: download beacon content to firmware

Firmware sends out beacon content generated by mac80211, and then stations
can receive beacon and work with this AP properly. Also, we download
beacon content again if TIM is changed.

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

rtw89: correct use of BA CAM

BA CAM is used to ACK peer's packets, so it must be established when
IEEE80211_AMPDU_RX_START, and free it by IEEE80211_AMPDU_RX_STOP.

The hardware can support two static BA CAM entries, so I implement a bitmap
and a struct to record which entry is used and its corresponding tid. Also,
the hardware can learn and create dynamic BA CAM entries automatically if
received packets don't match static BA CAM. That means it can still work if
we don't use H2C to set static BA CAM. An exception is tid=0 should be
always allocated in static BA CAM, so an existing static BA CAM will be
replaced if it is full and peer is going to establish a BA with tid=0.

The new firmware use new format of this H2C, so I upgrade it as well.

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

rtw89: fix sending wrong rtwsta->mac_id to firmware to fill address CAM

With wrong rtwsta->mac_id, it can't send out ack properly when we receive
assoc response occasionally. Then, it failed to connect an AP.

The cause is that we store 'sta' and use it somewhere. To correct this,
remove the variable and use mac_id in drv_priv of 'sta' or 'vif' passed
by mac80211.

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

rtw89: update scan_mac_addr during scanning period

Update scan_mac_addr to address CAM as A1, so hardware can ACK probe
response properly.

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

rtw89: use inline function instead macro to set H2C and CAM

In order to use compiler to check if we do improper cast of const* on
arguments of inline function.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211119054512.10620-4-pkshih@realtek.com

rtw89: add const in the cast of le32_get_bits()

Add 'const' to be clear that this is a read-only access, and this patch
doesn't change logic at all.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211119054512.10620-3-pkshih@realtek.com

rtw89: update partition size of firmware header on skb->data

The partition size is used to tell hardware the size of piece we are going
to send a firmware. The old code updates the size in constant buffer of
firmware, and leads system crash.

To fix this, update the size on skb->data after we copy the firmware data
into skb.

Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1188303
Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver")
Reported-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211119054512.10620-2-pkshih@realtek.com

rtw89: add Realtek 802.11ax driver

This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.

The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.

Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:

Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>

Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com