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: mac: use pointer to access functions of hardware engine and quota

To share flow with WiFi 7 chips, abstract functions related hardware
engines and their quota, so use pointer to access them. This doesn't change
logic at all.

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

wifi: rtw89: debug: remove wrapper of rtw89_debug()

The wrapper of rtw89_debug() is unnecessary, so just remove it.

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-5-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: show EHT rate in debugfs

Since we have TX rate from RA report of C2H event and RX rate from RX
descriptor, show them in debugfs like

TX rate [1]: EHT 2SS MCS-7 GI:3.2 BW:80 (hw_rate=0x427)
RX rate [1]: EHT 2SS MCS-7 GI:3.2 BW:80 (hw_rate=0x427)

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

wifi: rtw89: debug: txpwr table supports Wi-Fi 7 chips

We add TX power table format for Wi-Fi 7 chips. Since Wi-Fi 7 tables are
larger, in order to reuse some chunks, we extend code to process nested
entries. Now, dbgfs txpwr_table can work with Wi-Fi 7 chips.

An output example of dbgfs txpwr_table on Wi-Fi 7 chips is shown below.
...
[TX power byrate]
<< BW20 >>
CCK - 1M 2M 5.5M 11M | 20, 20, 20, 20, dBm
LEGACY - 6M 9M 12M 18M | 18, 18, 18, 18, dBm
LEGACY - 24M 36M 48M 54M | 18, 18, 17, 16, dBm
EHT - MCS14 MCS15 | 0, 0, dBm
DLRU_EHT - MCS14 MCS15 | 0, 18, dBm
MCS_1SS - MCS0 MCS1 MCS2 MCS3 | 18, 18, 18, 18, dBm
MCS_1SS - MCS4 MCS5 MCS6 MCS7 | 18, 17, 16, 15, dBm
MCS_1SS - MCS8 MCS9 MCS10 MCS11 | 14, 13, 12, 11, dBm
MCS_1SS - MCS12 MCS13 | 10, 9, dBm
HEDCM_1SS - MCS0 MCS1 MCS3 MCS4 | 18, 18, 18, 18, dBm
DLRU_MCS_1SS - MCS0 MCS1 MCS2 MCS3 | 18, 18, 18, 18, dBm
DLRU_MCS_1SS - MCS4 MCS5 MCS6 MCS7 | 18, 17, 16, 15, dBm
DLRU_MCS_1SS - MCS8 MCS9 MCS10 MCS11 | 14, 13, 12, 11, dBm
DLRU_MCS_1SS - MCS12 MCS13 | 10, 9, dBm
DLRU_HEDCM_1SS - MCS0 MCS1 MCS3 MCS4 | 18, 18, 18, 18, dBm
MCS_2SS - MCS0 MCS1 MCS2 MCS3 | 18, 18, 18, 18, dBm
...
[TX power limit]
<< 1TX >>
CCK_20M - NON_BF BF | 0, 0, dBm
CCK_40M - NON_BF BF | 0, 0, dBm
OFDM - NON_BF BF | 18, 0, dBm
MCS_20M_0 - NON_BF BF | 18, 0, dBm
MCS_20M_1 - NON_BF BF | 0, 0, dBm
...

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

wifi: rtw89: debug: show txpwr table according to chip gen

Since current TX power stuffs are for ax chips, add a suffix `_ax` to
them. Then, when requested to show txpwr table, select table according
to chip generation first.

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

wifi: rtw89: mac: generalize code to indirectly access WiFi internal memory

To diagnose abnormal behavior, we need to dump certain internal memory.
For example, dump security CAM when debugging encryption/decryption
problems, or dump BA CAM when debugging abnormal BlockAck.

Since the indirect address and internal memory base address are different
between WiFi 6 and 7 chips, add fields to reuse codes.

Also, only WiFi 6 chips initialize DMAC and CMAC tables via this indirect
interface, so no need to change the constant register address, and
new firmware will help to initialize these tables.

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

wifi: rtw89: sar: let caller decide the center frequency to query

If multiple channels, SAR will be hard to determine the center frequency
to query. Therefore, we move this decision out of SAR.

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

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: 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 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: debug: Fix error handling in rtw89_debug_priv_btc_manual_set()

If there is a failure during kstrtobool_from_user()
rtw89_debug_priv_btc_manual_set should return a negative error code
instead of returning the count directly.

Fix this bug by returning an error code instead of a count after
a failed call of the function "kstrtobool_from_user". Moreover
I omitted the label "out" with this source code correction.

Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver")
Signed-off-by: Zhang Shurong <zhang_shurong@foxmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/tencent_1C09B99BD7DA9CAD18B00C8F0F050F540607@qq.com

wifi: rtw89: debug: fix error code in rtw89_debug_priv_send_h2c_set()

If there is a failure during rtw89_fw_h2c_raw() rtw89_debug_priv_send_h2c
should return negative error code instead of a positive value count.
Fix this bug by returning correct error code.

Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver")
Signed-off-by: Zhang Shurong <zhang_shurong@foxmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://lore.kernel.org/r/tencent_AD09A61BC4DA92AD1EB0790F5C850E544D07@qq.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

wifi: rtw89: debug: txpwr table access only valid page according to chip

We now support RTL8851B which has only single RF path. For chip with
single RF path, TX power page is valid only in single path section.
So, we refine debugfs txpwr table to access TX power page according
to RF path number of runtime chip. It can prevent us from reading
beyond valid sections.

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

wifi: rtw89: enlarge supported length of read_reg debugfs entry

The register ranges of upcoming chips are different from current, and even
existing chips have different ranges, so support longer length to dump
registers. Then, user space can decide the ranges according to chip.

Since arbitrary length (e.g. 7) would be a little complicated, so simply
make length a multiple of 16. The output looks like

18620000h : 8580801f 82828282 82828282 080800fd

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

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: add RSSI statistics for the case of antenna diversity to debugfs

RSSI strength is only from PHY path A, but there are two antenna for the
module which supports antenna diversity. So, set RSSI value to index 1 of
RSSI array if current antenna is on antenna B. Then, debugfs can show
two RSSI values with a asterisk mark on selected antenna.

RSSI: -23 dBm (raw=174, prev=173) [-26, -23*]

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

wifi: rtw89: mac: use regular int as return type of DLE buffer request

The function to request DLE (data link engine) buffer uses 'u16' as return
value that mixes error code, so change it to 'int' as regular error code.
Also, treat invalid register value (0xfff) as an error.

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

wifi: rtw89: add use of pkt_list offload to debug entry

Driver can prepare pkt_list for firmware that only uses them to send out
the packets in specific situations. To understand the usage of current
status, and to check if there is leakage problem, dump bitmap and the
indices used by certain function.

An example looks like:

map:
...
pkt_ofld: 3f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...
[SCAN 0]: 3
[SCAN 1]: 4
[SCAN 3]: 5
VIF [0] xx:xx:xx:xx:xx:xx
...
pkt_ofld[GENERAL]: 0 1 2

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

wifi: rtw89: debug: avoid invalid access on RTW89_DBG_SEL_MAC_30

Only 8852C chip has valid pages on RTW89_DBG_SEL_MAC_30. To other chips,
this section is an address hole. It will lead to crash if trying to access
this section on chips except for 8852C. So, we avoid that.

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

wifi: rtw89: update D-MAC and C-MAC dump to diagnose SER

To detect TX or RX stuck, we implement SER (system error recovery) in
firmware to recover abnormal states of hardware, and report events to
driver. This kind of events could happen rarely per day.

SER might be true-positive or false-negative cases, and it could be failed
to recover true-positive case. We dump related registers to kernel message
at that moment and collect them from users, because they occur rarely,
randomly and hard to make sure we reproduce the same symptom. To address
problems accurately, add more registers by this patch.

It also might be false-positive cases that looks like TX or RX get stuck,
we need to dump registers from debugfs manually, so also add similar
things to debugfs as well.

Signed-off-by: Chia-Yuan Li <leo.li@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221102014300.14091-3-pkshih@realtek.com

wifi: rtw89: dump dispatch status via debug port

Dispatch is a component to decide packets forward to host, DMAC or
HAXIDMA. It contains CDT standing for CPU dispatcher, HDT standing
for host dispatcher, WDE standing for descriptor engine and PLE standing
for payload engine. STF is one kind of modes, it can be used if packet
send to hardware and doesn't need release report.

These debug port information can help to clarify the reason if
packets stuck in dispatch.

Signed-off-by: Chia-Yuan Li <leo.li@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221102014300.14091-2-pkshih@realtek.com

wifi: rtw89: add BW info for both TX and RX in phy_info

In order to debug performance issue intuitively, add bandwidth information
into debugfs entry phy_info. After applying this patch, it looks like:

TX rate [0]: HE 2SS MCS-11 GI:0.8 BW:80 (hw_rate=0x19b) ==> agg_wait=1 (3500)
RX rate [0]: HE 2SS MCS-9 GI:0.8 BW:80 (hw_rate=0x199)

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

wifi: rtw89: add to dump TX FIFO 0/1 for 8852C

MAC maintains TX FIFO to transmit packets with meta data to BB layer. To
debug abnormal transmission, we need to dump the content to dig problem.
Since FIFO of 8852C locates on different address with different size and
need additional switch to enable read operation, this patch adds the
changes accordingly.

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

wifi: rtw89: debug: txpwr_table considers sign

Previously, value of each field is just shown as unsigned.
Now, we start to show them with sign to make things more intuitive
during debugging.

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

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: 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: mac80211: keep A-MSDU data in sta and per-link

The A-MSDU data needs to be stored per-link and aggregated into a single
value for the station. Add a new struct ieee_80211_sta_aggregates in
order to store this data and a new function
ieee80211_sta_recalc_aggregates to update the current data for the STA.

Note that in the non MLO case the pointer in ieee80211_sta will directly
reference the data in deflink.agg, which means that recalculation may be
skipped in that case.

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

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

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: add debug select to dump MAC pages 0x30 to 0x33

Dump new region 0x3000 to 0x33ff to help debug.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220506120216.58567-5-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: mac: move table of mem base addr to common

Previously, mac_mem_base_addr_table was declared in debug.c locally
because it's only used via debugfs to dump mac memory. Now, we plan to
refine SER (system error recover) flow which will also need to dump mac
memory to somewhere as information for error which is catched. So, we
move mac_mem_base_addr_table to mac.c rtw89_mac_mem_base_addrs earlier
as common code.

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

rtw89: debug: add stations entry to show ID assignment

In order to trace the relation of IDs, we add this debugfs entry to make
them clear.

The output looks like:
map:
mac_id: 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
addr_cam: 07 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
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 [1] 58:00:e3:bb:9c:4f
addr_cam_idx=1
-> bssid_cam_idx=0
sec_cam_bitmap=00 00 00 00 00 00 00 00
STA [2] 94:08:53:8e:ef:75
addr_cam_idx=2
-> bssid_cam_idx=0
sec_cam_bitmap=00 00 00 00 00 00 00 00

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

rtw89: Add RX counters of VHT MCS-10/11 to debugfs

8852AE can receive packets with VHT MCS10/11, and we want to know we have
received this kind of packets, so show the counter of VHT MCS10/11 in
debugfs, like:

TP TX: 1 [1] Mbps (lv: 1), RX: 420 [422] Mbps (lv: 4)
Beacon: 19
Avg packet length: TX=102, RX=3081
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, 4, 624, 4818][29913, 556]
HE 1SS: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
HE 2ss: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
TX rate [0]: VHT 2SS MCS-9 SGI (hw_rate=0x119) ==> agg_wait=1 (3500)
RX rate [0]: VHT 2SS MCS-10 SGI (hw_rate=0x11a)
RSSI: -30 dBm (raw=161, prev=165)

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

net: Don't include filter.h from net/sock.h

sock.h is pretty heavily used (5k objects rebuilt on x86 after
it's touched). We can drop the include of filter.h from it and
add a forward declaration of struct sk_filter instead.
This decreases the number of rebuilt objects when bpf.h
is touched from ~5k to ~1k.

There's a lot of missing includes this was masking. Primarily
in networking tho, this time.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Acked-by: Stefano Garzarella <sgarzare@redhat.com>
Link: https://lore.kernel.org/bpf/20211229004913.513372-1-kuba@kernel.org

codel: remove unnecessary sock.h include

Since sock.h is modified relatively often (60 times in the last
12 months) it seems worthwhile to decrease the incremental build
work.

CoDel's header includes net/inet_ecn.h which in turn includes net/sock.h.
codel.h is itself included by mac80211 which is included by much of
the WiFi stack and drivers. Removing the net/inet_ecn.h include from
CoDel breaks the dependecy between WiFi and sock.h.

Commit d068ca2ae2e6 ("codel: split into multiple files") moved all
the code which actually needs ECN helpers out to net/codel_impl.h,
the include can be moved there as well.

This decreases the incremental build size after touching sock.h
from 4999 objects to 4051 objects.

Fix unmasked missing includes in WiFi drivers.

Acked-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211221193941.3805147-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

rtw89: fix incorrect channel info during scan

We used to fill in rx skbs' frequency field by mac80211's current
channel value. In some cases, mac80211 switches channel before all
rx packets have been processed. This results in incorrect bss info.
We fix this by filling in frequency field with channel index obtained
from hardware, then fix potential cck missing issue by skb's original
hw rate. After all fix is done, convert hw rate back to the supported
band rate index.

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

rtw89: add AXIDMA and TX FIFO dump in mac_mem_dump

The AXIDMA is tx/rx packet transmission between PCIE host
and device, and TX FIFO is MAC TX data.
We dump them to verify that these memory buffers are correct.

Signed-off-by: Chia-Yuan Li <leo.li@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Reviewed-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211122021129.4339-1-pkshih@realtek.com

rtw89: remove unnecessary conditional operators

The conditional operator is unnecessary while assigning values to the
bool variables.

Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Ye Guojin <ye.guojin@zte.com.cn>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211104061119.1685-1-ye.guojin@zte.com.cn

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