The PD lower bound set after one interface is connected, If second
interface needs to connect, packets might not be detected because the
PD lower bound is too high. Therefore, a DIG suspend/resume flow is
added to decrease the PD lower bound during scanning or connection,
and the original PD level is resumed afterward.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250710042423.73617-3-pkshih@realtek.com
Newer firmware will notify driver of the Packet Detection (PD)
value on the channel after switch channels during FW scan.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250430055157.13623-2-pkshih@realtek.com
Some SAR sources, e.g. ACPI, may allow different SAR configs by antenna.
Previously, the minimum config between antennas was taken. Because there
are differences between HW design, different chips might have different
solutions to achieve this. So, it cannot be done through a single common
handling. Now, add the relevant skeleton for this purpose ahead.
First, add a flag into chip info to describe whether it has implemented
this function or not. Second, support to query SAR config for a given RF
path. With it, each chip can implement its own handling. Then, if a chip
declares to support this function, when it queries SAR config without a
given RF path, it gets a maximum config between antennas.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250326020643.14487-10-pkshih@realtek.com
The 8922A now supports dynamic antenna gain. However, in firmware
before v0.35.64.0, different transmit powers cannot be applied to
each RF path. To comply with regulatory limits in these older
firmware, the lower of the two requested transmit powers will
be used for both paths when they differ.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250306021144.12854-5-pkshih@realtek.com
Since debugfs needs wiphy lock held, wiphy_locked_debugfs_{read,write}()
will be adopted, so implmenet file_ops::read/write along with their
arguments.
For reading part, it needs lots of changes because seq_file is not
suitable for wiphy_locked_debugfs_{read,write}(), so use spatch script
below to convert basically, and manually implement the functions.
@ rule1 @
identifier m;
@@
- seq_printf(m,
+ p += scnprintf(p, end - p,
...)
@ rule2 @
identifier m;
@@
- seq_puts(m,
+ p += scnprintf(p, end - p,
...)
For current version, only 4K buffer to output. To note ourselves, add
ellipsis symbol "..." to trailing if buffer is full. Later, add an option
to specify buffer size needed by a debugfs entry.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250122060310.31976-4-pkshih@realtek.com
For certain works protected by driver mutex, use wiphy_work() directly
to have wiphy lock held naturally. Then every this kind of works is
protected by both wiphy lock and driver mutex.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250122060310.31976-3-pkshih@realtek.com
Dynamic mechanism EDCCA (Energy Detection Clear Channel Assessment) is to
dynamically adjusted to make EDCCA suitable for situations.
Use PHY context to support two PHY.
For the EDCCA log part, registers to report EDCCA for PHY 1 is not a
simple offset from PHY 0, so add them by separate patch.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250117072828.16728-7-pkshih@realtek.com
DIG standing for dynamic initial gain is to define RX coverage. Adjust this
value dynamically to gain good RX performance.
Use PHY context to extend DIG algorithm to support two PHY.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250117072828.16728-5-pkshih@realtek.com
RTL8922AE-VS is a variant of RTL8922AE, which is supported by firmware
version after 0.35.54.0 and only can support up to MCS11. Add a variant
struct to describe these requirements accordingly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250108020955.14668-3-pkshih@realtek.com
The newer firmware, lik RTL8852C version 0.27.111.0, will notify driver
report of TAS (Time Averaged SAR) power by new C2H events. This is to
assist in higher accurate calculation of TAS.
For now, driver doesn't use the report yet, so add a dummy handler to
avoid it throws info like:
rtw89_8852ce 0000:03:00.0: c2h class 9 func 6 not support
Also add "MAC" and "PHY" to the message to disambiguate the source of
C2H event.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241209042127.21424-1-pkshih@realtek.com
For MLO supported IC, send H2C command to firmware before PS with link
information for each PHY for MLO to work properly. And re-init hardware
settings regarding to RX descriptor information after PS.
Signed-off-by: Eric Huang <echuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241206055716.18598-4-pkshih@realtek.com
In the original flow, the crystal_cap might be calculated as a negative
value and set as an overflow value. Therefore, we added a check to limit
the calculated crystal_cap value. Additionally, we shrank the crystal_cap
adjustment according to specific CFO.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241128055433.11851-7-pkshih@realtek.com
The original handling will iterate all active links under the given sta
and apply the changes to each. Now, stack tweaks ops from sta_rc_update
to link_sta_rc_update, which means targeting a given link. Then, our link
iteration looks redundant. So, refine it to apply the changes to the link
directly.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241128055433.11851-6-pkshih@realtek.com
The dynamic antenna gain (DAG) may independently apply different TX
powers for each RF path. This can be accomplished by using the larger
TX power as the reference path and adjusting the TX power of the
other path based on the difference. Currently only 8852BE/8852BTE/
8852CE are supported.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241111065132.19587-4-pkshih@realtek.com
Dynamic Antenna Gain (DAG) adjusts the transmit power based on the
platform's antenna gain. This allows for higher transmit power when
the antenna gain is lower, while still complying with regulatory
limits. The driver reads the Realtek Antenna Gain (RTAG) data from
BIOS, and DAG is only enabled when the regulatory domain allows it.
Currently, it only supports 8852BE/8852BTE/8852CE.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241111065132.19587-3-pkshih@realtek.com
To support MLO, we initialize things on dual HW bands of Wi-Fi 7 chip.
And, each link will indicate which HW band it's bound to. So, in link
control flow, we control major things based on target link's HW band
instead of hardcode like RTW89_PHY_X or RTW89_MAC_X.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240925020119.13170-2-pkshih@realtek.com
Refactor STA related functions, e.g. add/assoc/disassoc/disconnect/remove
to separate most link stuffs into sub-functions for MLO reuse.
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-7-pkshih@realtek.com
Refactor VIF related functions, e.g. add/remove/assoc/mapping
to separate most link stuffs into sub-functions for MLO reuse.
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-6-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
RX DCK stands for receiver DC calibration. The v1 format adds a field to
indicate the calibration is for operation channel or an average value for
all scanning channels. Update the format accordingly, and increase
firmware format sequence to 2.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240913071340.41822-3-pkshih@realtek.com
No longer access chan with hard-code RTW89_CHANCTX_X whenever possible.
Instead, obtain the right chanctx from somewhere and use it in RTL8922A
RFK (RF calibration) related code.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240819091724.33730-7-pkshih@realtek.com
Driver will notify FW the target index of RFK table to use at some
moments. When MCC (multi-channel concurrent), the correctness of the
notification is especially important.
We now unify the selection logic of RFK table as below among chips.
1. check each table if it matches target channel
2. check all tables if any is idle by iterating active channels
3. replace the first table if all are busy unexpectedly
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240702124452.18747-2-pkshih@realtek.com
The channel configuration of 8852BT is very similar but a little different
to 8852B, so use chip ID as condition to add extra handles including
external loss compensation, ADC configurations, spur settings and so on.
Don't affect existing 8852BE.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/20240607070659.80263-3-pkshih@realtek.com
Configure RF registers according to band, channel, bandwidth. Since this
chip will support MLO, it needs check the operating mode to decide paths
we are going to configure.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240215055741.14148-4-pkshih@realtek.com
To set channel, add a function to get TXSB (TX subband) that is hardware
index to indicate primary channel. Then, configure band, channel,
bandwidth and TXSB via registers.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240215055741.14148-2-pkshih@realtek.com
PHY-1 can be seen as a copy of PHY-0, and the difference is their base
register address, so add a function to get offset to access PHY-1.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240209065229.34515-2-pkshih@realtek.com
Calling RF calibrations when interface up, connection, switching bands and
going to scan.
For 8922AE, RF calibrations are moved to firmware, so use H2C commands to
trigger RF calibrations and wait for a C2H event to indicate completion.
Then, do next RF calibration.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240202030642.108385-10-pkshih@realtek.com
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
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
Implement indirect interface v2 to read/write RF registers via PHY
registers for 8922A.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240124033637.12330-5-pkshih@realtek.com
The chip_ops::bb_preinit and ::bb_postinit are called before and after
loading BB parameters from tables of firmware file. The ::bb_reset is
used to reset hardware state, and currently it is not needed by 8922AE so
leave it as empty. The ::bb_sethw is to implement conditional parameters.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240120003831.7014-4-pkshih@realtek.com
The channel_info is hardware settings to reflect operational status, such
as scale factor, report unit, buffer matrix size, RU size and so on. Then,
we can get desired reports to do further tuning.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240105064440.36926-1-pkshih@realtek.com
TX power is controlled by BB layer basically, but it should interact with
MAC layer, so these registers are put on MAC register domain and called
BB wrapper, which contains TX power for each MAC ID, OFDMA RU power, and
consideration of power type table.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240105064433.36870-1-pkshih@realtek.com
NCTL standing for nano-controller is used to assist RF calibration.
Basically, we write settings from a table, but format of the table can't
describe register mask and additional conditions, so add a function to
set this kind of settings.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240105064422.36812-1-pkshih@realtek.com
Add RX gain offset dynamic setting flow according to different bands
and bandwidths. RX gain offset values will be different according to
different channel bands, therefore, this dynamic mechanism is needed
while channel is changed. Add this to parse data from the element of
firmware file, and then we can use them easier at runtime.
Signed-off-by: Chung-Hsuan Hung <hsuan8331@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240105064228.36580-3-pkshih@realtek.com
Trigger a RFK (RF calibration) in firmware by a H2C command, and in
progress it reports log and a result finally by C2H events. Firstly, add
prototype of the C2H event handlers to have a simple picture of framework.
The callers who trigger H2C will wait until a C2H event is received,
so we must process these C2H events in receiving process. Thus, mark this
kind of C2H events as atomic. Also, timestamp is also useful for
debugging, mark C2H events carrying RFK log as atomic as well.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231213005054.10568-5-pkshih@realtek.com
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
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
Add dynamic mechanism EDCCA (Energy Detection Clear Channel Assessment)
in track work. Using a fixed-value threshold will make EDCCA particularly
sensitive and cause failure to transmit under certain circumstances.
Therefore, the threshold is dynamically adjusted to make EDCCA suitable
for any situation.
However, in some cases, we will adjust the EDCCA threshold to the highest
level so that urgent transmissions can be performed successfully, such as
scanning.
Finally, in order to observe the EDCCA report in time, add the EDCCA perIC
register macro and EDCCA HW report analysis. EDCCA logs can be displayed
by using the EDCCA debug mask.
Signed-off-by: Yi-Chen Chen <jamie_chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231122060458.30878-3-pkshih@realtek.com
Read calibration values of RX gain offset from efuse, and set them to
registers to normalize RX gain for all hardware modules. Then, PHY dynamic
mechanism can get expected values to adjust hardware parameters to yield
expected performance.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231117024029.113845-5-pkshih@realtek.com
The register address used for CFO(carrier frequency offset) tracking is
different from WiFi 7 series, so we change the way to access it. And we
refine the flow of CFO tracking to compatible all WiFi 7 and 6 ICs.
Signed-off-by: Cheng-Chieh Hsieh <cj.hsieh@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231016065115.751662-4-pkshih@realtek.com
Set EHT rate mask to RA (rate adaptive) H2C command according to handshake
result. The EHT rate mask format looks like
44 28 12 4 0
+----------------+----------------+--------+----+
| EHT 2SS rate | EHT 1SS rate | OFDM | CCK|
+----------------+----------------+--------+----+
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231011115256.6121-4-pkshih@realtek.com
Wi-Fi 6 chips and Wi-Fi 7 chips have different register design for TX
power RU limit. We rename original setting stuffs with a suffix `_ax`,
concentrate related enum declaration in phy.h, and implement setting
flow for Wi-Fi 7 chips. Then, we set TX power RU limit according to
chip generation.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231003015446.14658-6-pkshih@realtek.com
Wi-Fi 6 chips and Wi-Fi 7 chips have different register design for
TX power limit. We rename original setting stuffs with a suffix `_ax`,
concentrate related enum declaration in phy.h, and implement setting
flow for Wi-Fi 7 chips. Then, we set TX power limit according to chip
generation.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231003015446.14658-5-pkshih@realtek.com
We have a register to control TX power of each rate section to increase
or decrease an offset. But, Wi-Fi 6 chips and Wi-Fi 7 chips have different
address and format for this control register. We rename original setting
stuffs with a suffix `_ax` and implement setting flow for Wi-Fi 7 chips.
Then, we set TX power offset according to chip generation.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231003015446.14658-4-pkshih@realtek.com
Wi-Fi 6 chips and Wi-Fi 7 chips have different register design for
TX power by rate. We rename original setting stuffs with a suffix
`_ax` and implement setting flow for Wi-Fi 7 chips. Then, we set TX
power by rate according to chip generation.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231003015446.14658-3-pkshih@realtek.com
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
The ENV_MNTR(environment monitor) is the dynamic mechanism which based on
the HW of CCX(Cisco Compatible Extensions) which provide the channel
loading and noisy level indicator to debug or support the 802.11k. The
PHYSTS provide the detail PHY information per packet we received for
debugging. The DIG(dynamic initial gain) is the dynamic mechanism to
adjust the packet detect power level by received signal strength to avoid
false detection of the WiFi packet.
The address of registers used for ENV_MNTR, PHYSTS and DIG of WiFi 7 IC
are different with WiFi 6 series, so we modify the method to access the
register address in order to compatible with all WiFi 7 and 6 ICs.
Signed-off-by: Cheng-Chieh Hsieh <cj.hsieh@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230822125822.23817-7-pkshih@realtek.com
