To prevent chip overheating, reduce TX duty as the mechanism of thermal
protection. When temperature is raising over a threshold, send a firmware
command to reduce TX duty. If temperature is still raising, higher level
is adopted to have lower active duration.

The equation and unit of thermal values are different from chip to chip,
so define constant thresholds of thermal value to corresponding absolute
temperature of 110 and 120 degree Celsius.

Latter patch will decide which thermal threshold is adopted, and current
is still not enable thermal protection.

For debugging, add a flag to disable_dm that thermal protection can be
disabled to clarify low throughput in field.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241016133735.7571-2-pkshih@realtek.com

In range test, the RSSI is helpful to check attenuation of cable and align
difference between environments. Since data packets can be transmitted with
different rate and power, the RSSI of all packets can be variant.
Oppositely beacon is transmitted with the same rate and power, so beacon
RSSI will be relatively invariant, and more helpful to diagnose problems.

The output of beacon RSSI in unit of dBm looks like:

  Beacon: 19 (-33 dBm), TF: 0

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240927013512.7106-1-pkshih@realtek.com

The drv_priv hooked to mac80211 become as below.

                           (drv_priv)             (instance-0)
 +---------------+       +-----------+          +----------------+
 | ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
 +---------------+       +-----------+    |     +----------------+
                                          |
                                          |       (instance-1)
                                          |     +----------------+
                                          +---> | rtw89_vif_link |
                                                +----------------+

                           (drv_priv)             (instance-0)
 +---------------+       +-----------+          +----------------+
 | ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
 +---------------+       +-----------+    |     +----------------+
                                          |
                                          |       (instance-1)
                                          |     +----------------+
                                          +---> | rtw89_sta_link |
                                                +----------------+

The relation bewteen mac80211 link_id and our link instance is like below.

                 |\
 (link_id)       | \
     0  -------- |  |
     1  -------- |  | ------ instance-0 (link_id: X) -> work on HW band 0
     2  -------- |  |
     ...         |  | ------ instance-1 (link_id: Y) -> work on HW band 1
     14 -------- |  |
                 | /
                 |/

	N.B. For cases of non-MLD connection, we set our link instance-0
	active with link_id 0. So, our code flow can be compatible between
	non-MLD connection and MLD connection.

Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.

There are some things listed below, which work for now but need to extend
before multiple active links.
	1. tx path
		select suitable link instance among multiple active links
	2. rx path
		determine rx link by PPDU instead of always link instance-0
	3. CAM
		apply MLD pairwise key to any active links dynamically

Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.

Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com

Tweak code to not always access sta->deflink directly. Instead,
according to link_id, read target link_sta from sta->link[].

For now, rtwsta_link->link_id keeps 0. When driver starts to
support MLO, the link_id will be assigned.

Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-5-pkshih@realtek.com

This is an intermediate version that is separated from subsequent major
MLO changes, so some functions' namings are not really determined here.
e.g. struct rtw89_sta_link *sta_to_rtwsta_safe(struct ieee80211_sta *sta)

No logic is changed.

Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-3-pkshih@realtek.com

This is an intermediate version that is separated from subsequent major
MLO changes, so some functions' namings are not really determined here.
e.g. struct rtw89_vif_link *vif_to_rtwvif_safe(struct ieee80211_vif *vif)

No logic is changed.

Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-2-pkshih@realtek.com

The rtw89 uses debugfs to access registers and driver states. To get
a range of registers, the range value is set and stored to a variable, and
get the set of register values by the stored range. However, the variable
is a static global variable, which multiple adapters will be a problem,
so move the variable to adapter context rtw89_dev.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240816115700.17390-1-pkshih@realtek.com

Originally, we planed to fill MAC_0/1 indicators with chanctx and
use sub_entity_xxx for these things. However, there are some reasons
listed below which make us give up this plan after we know our Wi-Fi 7
HW design.
	1. one link is bound to one HW band during its life time
	   but, one link might change chanctx dynamically
	2. in concurrent mode, assume 1st vif is MLD
	   1st vif's 2nd link might use the same chanctx as 2nd vif
	   but, they are not on the same HW band
So, we let sub_entity_xxx stuffs deal with only chanctx now. And, to be
more readable, we rename sub_entity related words to chanctx.

No logic is changed.

Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240727080650.12195-4-pkshih@realtek.com

To more accurately debug performance issues, EVM statistics will
differentiate between different space streams, and only beacon
and data frames will be included.

Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240724052626.12774-2-pkshih@realtek.com

In rtw89_sta_info_get_iter() 'status->he_gi' is compared to array size.
But then 'rate->he_gi' is used as array index instead of 'status->he_gi'.
This can lead to go beyond array boundaries in case of 'rate->he_gi' is
not equal to 'status->he_gi' and is bigger than array size. Looks like
"copy-paste" mistake.

Fix this mistake by replacing 'rate->he_gi' with 'status->he_gi'.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver")
Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240703210510.11089-1-amishin@t-argos.ru