wifi: rtw89: wow: update WoWLAN reason register for different chips

The WoWLAN reason register is used for driver to get the wakeup reason
for reporting to cfg80211, and it is different from chips. So put it
into chip information.

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-2-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: 8922a: add chip_ops::rfk_hw_init

Add a chip_ops for WiFi 7 chips to set additional RF configurations
including MLO and PLL settings.

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

wifi: rtw89: 8922a: add chip_ops::rfk_init_late to do initial RF calibrations later

The RF calibrations are moved into firmware, so we trigger calibrations by
H2C commands and wait for C2H completion events. However, these events
can be received only after HCI (i.e. PCI for now) starts, so we should
do initial RF calibrations after that.

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

wifi: rtw89: 8922a: add chip_ops related to BB init

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

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: change supported bandwidths of chip_info to bit mask

Basically, all chips can support 20/40/80MHz bandwidth, and 8952C can
support 160MHz bandwidth, which is why we introduced support_bw160 before.
The coming WiFi 7 chips will support 320MHz optionally, so change it to
bit mask instead of adding another support_bw320.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240112062640.36922-3-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 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: phy: move bb_gain_info used by WiFi 6 chips to union

WiFi 7 chips use different bb_gain_info struct, so move existing struct to
a union in advance. 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://msgid.link/20240105064228.36580-2-pkshih@realtek.com

wifi: rtw89: 8922a: add SER IMR tables

To activate SER (system error recovery) in firmware, we have to configure
IMR to trigger interrupts, and then SER can check registers to know if it
need to reset hardware or notify driver to re-configure whole settings.

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

wifi: rtw89: refine element naming used by queue empty check

In queue empty check, one group contains 32 queues. And, the two elements,
wde_qempty_acq_num and wde_qempty_mgq_sel, are number of group and select
of group. To avoid confusing them with queue number and queue selection,
we refine their naming.

(don't change logic 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/20231124071703.132549-5-pkshih@realtek.com

wifi: rtw89: phy: dynamically adjust EDCCA threshold

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

wifi: rtw89: mac: add to access efuse for WiFi 7 chips

MAC address, hardware type, calibration values and etc are stored in efuse,
so we read them at probe stage and use them as capabilities to register
hardware.

There are two physical efuse -- one is the main efuse for digital hardware
part, and the other is for analog part. Because they are very similar, we
only describe the main efuse below.

The main efuse is split into two regions -- one is for logic map, and the
other is for physical map. For both regions, we use the same method to read
data, but need additional parser to get logic map. To allow reading
operation, we need to convert power state to active, and turn to idle state
after reading.

For WiFi 7 chips, we introduce efuse blocks to define feature group easier,
and these blocks are discontinue. For example, RF block is from 0x1_0000 ~
0x1_0240, and the next block PCIE_SDIO is starting from 0x2_0000.
Comparing to old one used by WiFi 6 chips, there is only single one logic
map, it would be a little hard to add an new field to a group if we don't
reserve a room in advance.

The relationship between efuse, region and block is shown as below:

(logical map)
+------------+ +---------------+ +-----------------+
| main efuse | | region 1 | | block 0x1_0000~ |
| (digital) | |(to logcal map)| +-----------------+
| | | | => +-----------------+
| | => | | | block 0x2_0000~ |
| | | | +-----------------+
| | |---------------| :
| | | region 2 |
+------------+ +---------------+

+------------+ +-----------------+
| 2nd efuse | ======================> | block 0x7_0000~ |
| (analog) | +-----------------+
+------------+

The parser converting from raw data to logic map is to decode block page,
block page offset, and word_en bits. Each word_en bit indicates two
following bytes as data of logic map, so total four word_en bits can
represent eight bytes. Thus, block page offset is 8-byte alignment.
The layout of a tuple is shown as below

+--------+--------+--------+--------+--------+--------+
| fixed 3 byte header | | | |
| | | | |
| [19:17] block_page | | | ... |
| [16:4] block_page_offset| | | |
| [3:0] word_en | ^ | ^ | |
+----|---+--------+--------+---|----+----|---+--------+
| | |
+-------------------------+---------+
a word_en bit indicates two bytes as data

For example,
block_page = 0x3
block_page_offset = 0x80 (must 8-byte alignment)
word_en = 0x6 (b'0110; 0 means data is presented)
following 4 bytes = 34 56 78 90
Then,
0x3_0080 = 34 56
0x3_0086 = 78 90

A special block page is RTW89_EFUSE_BLOCK_ADIE (7) that uses different
but similar format, because its real efuse size is smaller than main efuse.

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

wifi: rtw89: configure PPDU max user by chip

Different chip can support different max user in one PPDU report.
So, we now configure it in chip info.

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

wifi: rtw89: phy: generalize valid bit of BSS color

The register fields of BSS color map and valid bit are in the same register
for existing chips, but coming WiFi 7 chips define another register to
set valid bit, so add a field to chip_info to reuse the code.

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

wifi: rtw89: phy: change naming related BT coexistence functions

Change naming to disambiguate the functions because their names are common
and not clear about the purpose. Not change logic at all.

These functions are to control baseband AGC while BT coexists with WiFi.
Among these functions, ctrl_btg_bt_rx is used to control AGC related
settings, which is affected by BT RX, while BT shares the same path
with wifi; ctrl_nbtg_bt_tx is used to control AGC settings under
non-shared path condition, which is affected by BT TX.

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://lore.kernel.org/r/20231016065115.751662-2-pkshih@realtek.com

wifi: rtw89: refine bandwidth 160MHz uplink OFDMA performance

This improves 160MHz performance degradation with certain APs.
Some ICs transmit preamble that are hard to decode by others, continuous
retries then yield low throughput. Fix it with pre-calculated antenna
matrices.

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

wifi: rtw89: refine uplink trigger based control mechanism

Rename support_ul_tb_ctrl to waveform_ctrl since we need to do more
trigger based control and the naming could be confusing. Move related
code to leaf function so we make each functions separate and can be
easier to maintain.

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

wifi: rtw89: phy: extend TX power common stuffs for Wi-Fi 7 chips

The following are introduced for Wi-Fi 7 chips.
1. take BW/OFDMA into account on TX power by rate
2. increase TX power offset types up to EHT
3. split TX shape into tx_shape_lmt and tx_shape_lmt_ru

If functions which are only for AX, they always access TX power by rate
with BW/OFDMA = 0/0, and they don't access tx_shape's lmt_ru section.

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

wifi: rtw89: indicate TX power by rate table inside RFE parameter

For next-generation chips, TX power by rate table comes from RFE (RF
front end) parameter. It can be different according to RFE type. So,
we indicate TX power by rate table inside RFE parameter ahead. For
current chips, even with different RFE types, a chip is configured
with a single TX power by rate table. So, this commit doesn't really
affect these currently 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/20230920074322.42898-4-pkshih@realtek.com

wifi: rtw89: indicate TX shape table inside RFE parameter

For next-generation chips, TX shape table comes from RFE (RF front end)
parameter. It can be different according to RFE type. So, we indicate
TX shape table inside RFE parameter ahead. For current chips, even with
different RFE types, a chip is configured with a single TX shape table.
So, this commit doesn't really affect these currently 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/20230920074322.42898-3-pkshih@realtek.com

wifi: rtw89: add chip_info::txwd_info size to generalize TX WD submit

For existing chips, size of TX WD info is 6 words, but upcoming WiFi 7
chips become 8 words, so add a chip_info to reuse the code.

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

wifi: rtw89: 8922a: add chip_ops::bb_preinit to enable BB before downloading firmware

Before downloading firmware for BB MCU, call this ops to enable baseband
hardware.

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

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

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

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

wifi: rtw89: add chip_ops::query_rxdesc() and rxd_len as helpers to support newer chips

The next generation chips use different RX descriptor format, so add
a chip_ops to hook suitable handlers. Also, the length of RX descriptor is
different, so add a variable to store the length according to chip and
descriptor content dynamically. Then, the code can be more general.

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

wifi: rtw89: 8851b: configure GPIO according to RFE type

Though 8851BE is a 1x1 chip, but it has two antenna hardware module that
needs additional configuration to help choose antenna we are going to use.

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

wifi: rtw89: 8852b: adjust quota to avoid SER L1 caused by access null page

Though SER can recover this case, traffic can get stuck for a while. Fix it
by adjusting page quota to avoid hardware access null page of CMAC/DMAC.

Fixes: a1cb097168fa ("wifi: rtw89: 8852b: configure DLE mem")
Fixes: 3e870b481733 ("wifi: rtw89: 8852b: add HFC quota arrays")
Cc: stable@vger.kernel.org
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Link: https://github.com/lwfinger/rtw89/issues/226#issuecomment-1520776761
Link: https://github.com/lwfinger/rtw89/issues/240
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230426034737.24870-1-pkshih@realtek.com

wifi: rtw89: regd: judge UNII-4 according to BIOS and chip

For realtek regulatory, there are following two kinds of configurations
to determine whether to allow UNII-4 band, i.e. 5.9GHz channels.

1. default setting according to whether chip support it or not
2. evaluate realtek ACPI DSM with RTW89_ACPI_DSM_FUNC_59G_EN (func. 6)

If (1) is false, we won't try (2) and just disallow UNII-4. Otherwise,
if (2) is not supported or returns a non-specific value, we follow the
default setting either. Besides, this commit aims to add decision logic
in rtw89 regulatory. Actually, driver doesn't register UNII-4 yet. That
will be handled by another commit.

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/20230508081211.38760-3-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: use chip_info::small_fifo_size to choose debug_mask

Previously, 8852B has smaller FIFO size than others, so I use chip_id to
choose debug_mask before. 8851B has similar design, so add a field to
chip_info as a general expression.

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

wifi: rtw89: add CFO XTAL registers field to support 8851B

Since CFO XTAL registers of 8851B is different from 8852A, add a chip_info
field to define their difference. Other chips use another interface, so
fill NULL to this field.

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

wifi: rtw89: 8851b: add NCTL post table

NCTL (nano-controller) is used to assist RF calibration that sends
commands to NCTL so it can reduce IO from driver. 8851B needs additional
settings, so add a table to do things.

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

wifi: rtw89: coex: Update function to get BT RSSI and hardware counter

Correct Bluetooth RSSI count method. The 6dB is the gap between hardware
packet sampled value and real RSSI value.

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

wifi: rtw89: coex: Add path control register to monitor list

Chips use similar hardware for path control, but could different
path/antenna configuration. Add these register to monitor, if there are
wrong settings, these register can help to debug.

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

wifi: rtw89: coex: Enable Wi-Fi RX gain control for free run solution

When Wi-Fi & Bluetooth are both busy at the same time, Wi-Fi need to
enable RX gain to protect Wi-Fi RX RF ability. Without this configure
the interference from Bluetooth will bring a big impact to Wi-Fi RX.

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

wifi: rtw89: support WoWLAN mode for 8852be

To support WoWLAN mode for 8852be, we add one PLE quota setting and
WoWLAN stub, which shows that supported WLAN events include receiving
magic packet, rekey packet and deauth packet, and disconnecting from AP.

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

wifi: rtw89: correct 5 MHz mask setting

Use primary channel index to determine which 5 MHz mask should be enable.
This mask is used to prevent noise from channel edge to effect CCA
threshold in wide bandwidth (>= 40 MHZ).

Fixes: 1b00e9236a71 ("rtw89: 8852c: add set channel of BB part")
Fixes: 6b0698984eb0 ("wifi: rtw89: 8852b: add chip_ops::set_channel")
Cc: stable@vger.kernel.org
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/20230406072841.8308-1-pkshih@realtek.com

wifi: rtw89: use hardware CFO to improve performance

Turn on hardware CFO (central frequency offset) compensation based on IC
capability, and improve digital CFO compensation accuracy by using
more fixed points number.

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

wifi: rtw89: support parameter tables by RFE type

One chip can have different RFE (RF front end) types which we will judge
at runtime. And, different RFE types may use different RF parameter tables.
Though we didn't really meet this case previously, we are going to meet it
on upcoming chip RTL8851B. So, this commit handles parameter tables for
runtime RFE type.

We now encapsulate rtw89_txpwr_rule_<2/5/6>ghz tables into rtw89_rfe_parms.
Then, each chip defines its default parameter tables, and if needed, it can
configure extra parameter tables by RFE type. Finally we determine runtime
parameter tables by RFE type if one is configured. Otherwise, we use the
default parameter tables.

For now, we just move all settings under default parameter tables. We will
configure parameter tables by RFE types in separate commits afterwards.

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/20230330080331.37155-1-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: config EDCCA threshold during scan to prevent TX failed

Need to configure EDCCA threshold to default value before scan, and recall
original value after scan to prevent probe request can't be sent out.

Signed-off-by: Chih-Kang Chang <gary.chang@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/20230322060238.43922-1-pkshih@realtek.com

wifi: rtw89: add counters of register-based H2C/C2H

The register-based H2C/C2H are used to exchange information between driver
and firmware, but only apply to narrow area because its data size is
smaller than regular packet-based H2C/C2H.

This kind of H2C/C2H must be paired. To identify if any H2C/C2H is missing,
update counters to help diagnose this kind of problems.

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

wifi: rtw89: coex: Update RTL8852B LNA2 hardware parameter

The LNA gain didn't set before, it will lead some WiFi RX issue.
And the setting can increase both of WiFi & BT performance while
they are both RX.

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

wifi: rtw89: 8852b: add channel encoding for hw_scan

To obtain correct packet frequency for hw_scan, 52b needs to decode
the channel index obtained from hardware. Change the driver related
set channel part as well to make driver/firmware compatible.

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

wifi: rtw89: 8852b: correct register mask name of TX power offset

For a packet with 1SS rate, it can also transmit via 2 antenna, called
2T mode. For 2T TX power offset, mask should be 2T as well. Fortunately,
the mask of 2T and 1T are the same, so it can still work well without
this fix.

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

wifi: rtw89: use passed channel in set_tx_shape_dfir()

In path of setting channel and setting TX power, the rtw89_chan instance
to be used is controlled by top and passed down. The set_tx_shape_dfir()
is in path of setting TX power, so it should use the passed rtw89_chan
instead of querying it itself. Otherwise, it might encounter mismatch
between parameters if multi-channel.

For example,
rtw89_8852ce 0000:04:00.0: set tx shape dfir by unknown ch: 155 on 2GHz

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

wifi: rtw89: 8852b: try to use NORMAL_CE type firmware first

New firmware type NORMAL_CE is introduced to support P2P-PS and hardware
scan, but no LPS-PG mode. After this patch, old firmware with NORMAL type
can still work well.

The use of this new type is the same as before, so we add new type to
avoid taking wrong firmware. Then, driver log can also give clear
information about this change:

rtw89_8852be 0000:03:00.0: Firmware version 0.29.26.0, cmd version 0, type 5
rtw89_8852be 0000:03:00.0: Firmware version 0.29.26.0, cmd version 0, 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/20230123065401.14174-7-pkshih@realtek.com

wifi: rtw89: 8852b: fill the missing configuration about queue empty checking

The configurations, wde_qempty_acq_num and wde_qempty_mgq_sel, are used
when MAC checks if TX queues are empty. Fill the corresponding setting
for 8852B.

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

wifi: rtw89: coex: Change RTL8852B use v1 TDMA policy

RTL8852B support the new features like TDMA instant (Change TDMA mechanism
immediately), Co-RX feature (Wi-Fi/Bluetooth can RX in the same time) and
so on. The v1 TDMA policy will enable those newer mechanism. It will have
a better coexistence performance.

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

wifi: rtw89: 8852b: update BSS color mapping register

BSS color mapping register is different per IC, therefore, move this
register to chip_info and update the setting function. Without this patch,
wrong BSS color causes behavior abnormal, especially DL-OFDMA.

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

wifi: rtw89: coex: use new introduction BTC version format

Previous patch has added format version derived from firmware version.
Use the format version, and remove constant version number from chip_info.

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

wifi: rtw89: 8852b: turn off PoP function in monitor mode

PoP stands for Packet on Packet that can improve performance in noisy
environment, but it could get RX stuck suddenly. In normal mode, firmware
can help to resolve the stuck, but firmware doesn't work in monitor mode.
Therefore, turn off PoP to avoid RX stuck.

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

wifi: rtw89: switch BANDEDGE and TX_SHAPE based on OFDMA trigger frame

There are some registers for transmit waveform control, two of them used
in this change are for BANDEDGE and TX_SHAPE control. BANDEDGE controls
whether to apply band edge filter to transmit waveform. TX_SHAPE controls
whether to apply triangular mask to transmit waveform. It is found for
some chip, these two should be turned off during OFDMA UL traffic for
better performance.

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

wifi: rtw89: read CFO from FD or preamble CFO field of phy status ie_type 1 accordingly

Add macro to get FD(frequency domain) CFO field from ie_type 1, and correct
the naming for preamble CFO field. Each IC could assign the CFO source to
either FD CFO or preamble CFO in chip_info. Based on the suggestion from HW
designer, rtw8852b and its derived versions will have better CFO tracking
performance with FD CFO.

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

wifi: rtw89: 8852b: correct TX power controlled by BT-coexistence

When coexistence mechanism is under free-run mode, it could adjust WiFi
and BT TX power to avoid interference with each other. For other cases,
it should keep original TX power from regular predefined tables, so
set correct values to 255 for these cases.

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

wifi: rtw89: 8852b: add chip_ops related to RF calibration

Since RF calibrations are added, add chip_ops to call them. These chip_ops
include initial, full calibration, configuration when switching band and
scanning, and track work in period of 2 seconds.

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

wifi: rtw89: 8852b: add basic attributes of chip_info

Add 8852b specific constant tables and basic attributes containing
common chip_ops, firmware name, supported TX/RX NSS, number of CAM,
coexistence version, control register set, and so on.

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

wifi: rtw89: 8852b: add functions to control BB to assist RF calibrations

When we are going to do RF calibrations, they need BB helpers to control
TX PLCP, power, path and mode. Also, it they need helpers to backup and
restore some registers before and after RF calibrations. Then, use flow of
RF calibrations will be like backup registers, configure calibration,
configure TX parameters, measure calibration result, and finally restore
registers.

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

wifi: rtw89: 8852b: add chip_ops to configure TX/RX path

To support variant models, such as 1x1 or 1T2R, we need this chip_ops to
change the 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/20221009125403.19662-8-pkshih@realtek.com

wifi: rtw89: 8852b: add chip_ops to query PPDU

Add to parse PPDU to get frequency and RSSI of received packets.

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

wifi: rtw89: 8852b: add chip_ops related to BT coexistence

These chip_ops are used to assist BT coexistence module to control chip
specific operations, such as initial, pre-AGC, BT grant, set wifi priority
and tx power, RX gain, and get BT counter.

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

wifi: rtw89: 8852b: add chip_ops to get thermal

Thermal value reflects temperature that will affect RF performance, so
we re-calibrate RF characteristics if delta of thermal over a threshold.

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

wifi: rtw89: 8852b: add basic baseband chip_ops

chip_ops::bb_reset is to reset baseband state after loading parameters,
because its state could be unpredictable at that moment. The other is
chip_ops::bb_sethw that is to set some baseband settings not including in
parameter tables.

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

wifi: rtw89: 8852b: add power on/off functions

We need power on function to enable hardware circuits of MAC/BB/RF, and
then download firmware and load PHY parameters. After more settings, it
starts to work. When it enters idle, use power off function to have the
lowest power consumption.

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

wifi: rtw89: 8852b: add chip_ops::set_channel_help

This chip_ops is to assist set_channel, because we need setup and restore
hardware before and after set_channel.

Before set_channel, we stop transmitting, reset PPDU status, disable TSSI,
and disable ADC. After set_channel, do opposite things in reverse order.

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

wifi: rtw89: 8852b: add chip_ops::set_channel

set_channel is main function to configure channel and bandwidth for all
layers, namely MAC, BB and RF. Additionally, MAC layer enables CCK rate
checking to avoid wrong rate from driver. BB layer configures SCO
(Sample Clock Offset) for CCK, TX gain error/offset, and reset baseband
hardware circuit after all configurations done.

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

wifi: rtw89: 8852b: add HFC quota arrays

HFC is short for HCI flow control. These arrays are used to set quota
according to operating modes, which are SCC or download firmware.

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

wifi: rtw89: 8852b: add chip_ops to read phy cap

This efuse region is to store PHY calibration, and it is a separated region
from the region that stores MAC address. Then, use these data to configure
via chip_ops::power_trim that is a calibration mechanism of TX power.

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

wifi: rtw89: 8852b: add chip_ops to read efuse

efuse stores individual data about a chip itself, such as MAC address,
country code, RF and crystal calibration data, and so on. Define a struct
to help access efuse content, and copy them into a common struct.

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

wifi: rtw89: 8852b: add chip_ops::set_txpwr

This chip_ops is to set TX power according to country, channel, rate and
so on. Since shared code is used to configure TX power, we only implement
specific part in this patch.

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

wifi: rtw89: 8852b: configure DLE mem

Configure DLE (data link engine) memory size for operating modes.

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

wifi: rtw89: check DLE FIFO size with reserved size

For SCC mode, some FIFO are reserved, so compare the quantity after minus
the reserved size.

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

wifi: rtw89: 8852b: implement chip_ops::{enable,disable}_bb_rf

Implement to power on/off BB and RF via MAC registers.

Add return type of chip_ops::disable_bb_rf, because it could fail to
disable. Also, correct naming of register 0x0200 used by the ops 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/20220927062611.30484-5-pkshih@realtek.com

wifi: rtw89: mac: define DMA channel mask to avoid unsupported channels

Six channels are unsupported by 8852b, so mask them out to prevent to
access undefined registers in this chip.

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