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

[ Upstream commit acc55d7dd4de525ac07e43e90ea3cc630677ec8a ]

The Wi-Fi firmware 29.29.X should use version 2 role info format

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

[ Upstream commit acc55d7dd4de525ac07e43e90ea3cc630677ec8a ]

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

Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231218061341.51255-2-pkshih@realtek.com
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

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

The ENV_MNTR(environment monitor) is the dynamic mechanism which based on
the HW of CCX(Cisco Compatible Extensions) which provi

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

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

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

Signed-off-by: Cheng-Chieh Hsieh <cj.hsieh@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230822125822.23817-7-pkshih@realtek.com

show more ...

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

cr_base is base address of PHY control register. The base of WiFi 6 and 7
chips are 0x1_0000 and 0x2_0000 respectively, so define t

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

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

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

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

show more ...

wifi: rtw89: mac: add mac_gen_def::band1_offset to map MAC band1 register address

There are two copies of MAC hardware called band0 and band1. Basically,
the only difference between them is base add

wifi: rtw89: mac: add mac_gen_def::band1_offset to map MAC band1 register address

There are two copies of MAC hardware called band0 and band1. Basically,
the only difference between them is base address, so we can share functions
with a 'band' (or 'mac_idx') argument.

The offset of base address of WiFi 6 and 7 are 0x2000 and 0x4000
respectively, so add band1_offset field to new introduced struct
mac_gen_def to possibly reuse functions.

Using below spatch script to convert callers:

@@
expression reg, band;
@@
- rtw89_mac_reg_by_idx(reg, band)
+ rtw89_mac_reg_by_idx(rtwdev, reg, band)

@@
expression reg, port, band;
@@
- rtw89_mac_reg_by_port(reg, port, band)
+ rtw89_mac_reg_by_port(rtwdev, reg, port, band)

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

show more ...

wifi: rtw89: initialize multi-channel handling

We prepare to deal with multiple channels via new entity modes.
* MCC_PREPARE: Transitional mode before MCC
* MCC: Multi-Channel Concurrent mode
And,

wifi: rtw89: initialize multi-channel handling

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

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

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

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

show more ...

wifi: rtw89: provide functions to configure NoA for beacon update

Callers call renew function when wanting to generate a new P2P NoA
information element, and call append function to append NoA attri

wifi: rtw89: provide functions to configure NoA for beacon update

Callers call renew function when wanting to generate a new P2P NoA
information element, and call append function to append NoA attribute
one by one. Then, updating beacon work will fetch the P2P NoA information
element configured by callers and add it to beacon.

The use case of MCC (multi-channel concurrent) <GO + STA> for example:
* start MCC - GO part
renew P2P NoA
append period NoA after calculation
* download beacon for GO
fetch P2P NoA and add to beacon content
* stop MCC - GO part
renew P2P NoA (reset)

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

show more ...

wifi: rtw89: call rtw89_chan_get() by vif chanctx if aware of vif

We adjust these processes which can work accodrding to vif but call
rtw89_chan_get() with static RTW89_SUB_ENTITY_0. After multi-cha

wifi: rtw89: call rtw89_chan_get() by vif chanctx if aware of vif

We adjust these processes which can work accodrding to vif but call
rtw89_chan_get() with static RTW89_SUB_ENTITY_0. After multi-channel
support, chanctx of vif won't always be on RTW89_SUB_ENTITY_0. So,
we make them call rtw89_chan_get() with rtwvif->sub_entity_idx.

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

show more ...

wifi: rtw89: add function prototype for coex request duration

The request duration comes from coex mechanism, indicating the
length of time that should be reserved for BT in each time division.
It i

wifi: rtw89: add function prototype for coex request duration

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

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

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

show more ...

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

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

show more ...

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

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

show more ...

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 ver

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

show more ...

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

For existing chips, firmware is only for WiFi CPU, but WiFi 7 chips add
new hardware component BB MCU that needs firmware as well. The firmwares of
BB M

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

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

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

show more ...

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

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

show more ...

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 form

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

show more ...

wifi: rtw89: recognize log format from firmware file

Firmware log format is an element of multi-firmware file
and used for firmware to provide log with formatted text.
Driver needs to recognize it i

wifi: rtw89: recognize log format from firmware file

Firmware log format is an element of multi-firmware file
and used for firmware to provide log with formatted text.
Driver needs to recognize it in advance if it exists.

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

show more ...

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

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

show more ...

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 even

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

show more ...

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
r

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

show more ...

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

To support EHT rate, hardware rate v1 is introduced. The CCK and OFDM rates
are persistent. HT/VHT/HE rates use different rate code from origina

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

To support EHT rate, hardware rate v1 is introduced. The CCK and OFDM rates
are persistent. HT/VHT/HE rates use different rate code from original, and
add new code for EHT rates.

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

show more ...

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

The coming WiFi 7 chip is 8922AE which uses different hardware rate and
register naming rule. Adding a chip_info::chip_gen field can

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

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

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

show more ...

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 a

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

show more ...

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

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

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

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

(No logic is changed.)

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

show more ...

wifi: rtw89: cleanup rtw89_iqk_info and related code

Drop useless '_iqk_track()' and 'rtw8852a_iqk_track()' (they
just change 'thermal_rek_en' field which is set but unused
and so removed as well) f

wifi: rtw89: cleanup rtw89_iqk_info and related code

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

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

show more ...

wifi: rtw89: cleanup private data structures

Remove a bunch of unused (and set but unused) fields
from 'struct rtw89_btc_wl_nhm', 'struct rtw89_dle_info',
'struct rtw89_hal' and 'struct rtw89_env_mo

wifi: rtw89: cleanup private data structures

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

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

show more ...

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

Update TX power tables to RF version R63.

TX power tables' changes:
* TX power byrate:
tweak a bit
* TX power limit

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

Update TX power tables to RF version R63.

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

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

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

show more ...