wifi: rtw88: Add rtw8812a.{c,h}

These contain code specific to RTL8812AU.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/a0057683-79eb-4ab2-8f74-11a3bc58adfb@gmail.com

wifi: rtw88: Add rtw8821a.{c,h}

These contain code specific to RTL8821AU.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/37218648-ada7-4fad-b7bd-d2aee28cefb9@gmail.com

wifi: rtw88: Add rtw88xxa.{c,h}

These contain code shared by both RTL8821AU and RTL8812AU chips.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/b8590382-a954-412d-a96b-63e360b97acc@gmail.com

wifi: rtw88: Add rtw8821a_table.{c,h}

These contain various arrays for initialising RTL8821AU. Also TX power
limits.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/087c7260-fcc3-4e22-886b-ac477cad9198@gmail.com

wifi: rtw88: Add rtw8812a_table.{c,h}

These contain various arrays for initialising RTL8812AU. Also TX power
limits.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/086f476c-e832-4867-963c-a64a63252fd6@gmail.com

wifi: rtw89: coex: set higher priority to BT when WL scan and BT A2DP exist

If WiFi operation channel & scan channel both at 2.4GHz, original will keep
going at WL > BT priority table for a long time. It makes A2DP can not sent
audio data to SUT device in time then performed a lag audio. Assign
a BT > WL priority table when A2DP exist, to avoid the issue.

Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241031023032.7102-1-pkshih@realtek.com

wifi: rtw89: 8852b: change RF mode to normal mode when set channel

Set the RF mode from 0xA(low power mode) to 0x3(Normal mode) to avoid
abnormal TX waveform in OFDM rate. Originally the RF mode will be changed
to normal mode by the firmware after entering LPS once. Therefore, this
change does not affect power saving.

Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241030091603.6073-1-pkshih@realtek.com

wifi: rtw89: coex: check NULL return of kmalloc in btc_fw_set_monreg()

kmalloc may fail, return value might be NULL and will cause
NULL pointer dereference. Add check NULL return of kmalloc in
btc_fw_set_monreg().

Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
Fixes: b952cb0a6e2d ("wifi: rtw89: coex: Add register monitor report v7 format")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/516a91f3997534f708af43c7592cbafdd53dd599.1730253508.git.xiaopei01@kylinos.cn

wifi: rtw89: 8922a: fill the missing OP1dB configuration

OP1dB stands for Output 1dB Compression Point. At this point, the power
amplifier starts to enter the saturation region, resulting in distortion.
The configuration of OP1dB can optimize the RX gain saturation region,
improving RX throughput from 573 to 675 Mbps.

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

wifi: rtw89: mac: no configure CMAC/DMAC tables for firmware secure boot

The initial CMAC/DMAC tables used by WiFi 6 chips are not needed to be
called for firmware secure boot. Otherwise, it causes firmware abnormal
and throw warnings.

  rtw89_8852be 0000:03:00.0: FW status = 0x1400
  rtw89_8852be 0000:03:00.0: FW BADADDR = 0xb872f800
  rtw89_8852be 0000:03:00.0: FW EPC/RA = 0xb89333b7
  rtw89_8852be 0000:03:00.0: FW MISC = 0x0
  rtw89_8852be 0000:03:00.0: R_AX_HALT_C2H = 0x10002010
  rtw89_8852be 0000:03:00.0: R_AX_SER_DBG_INFO = 0x0
  rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97
  rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c95
  rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c99
  rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9b
  rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9f
  rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9b
  rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c99
  rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9d
  rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97
  rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97
  rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97
  rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c99
  rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97
  rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9f
  rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c99

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

wifi: rtw89: fw: use common function to parse security section for WiFi 6 chips

The MSSC (multiple security section count) can be regular number (shown in
below figure) or 0xFF (supported already). For WiFi 7 or newer WiFi 6
chips, the MSSC will be 0xFF. But early WiFi 6 chip such as RTL8852B
could be either one of the cases.

Extend __parse_security_section() to support both with/without secure
boot mode accordingly.

           +---------------------------+ -\
           |      firmware header      |  |
           |                           |  |
           | +-----------------------+ |  |
           | | section type/size * N | |  |
           | +-----------------------+ |  |
           +---------------------------+ -/
           :                           :
           +---------------------------+ -\
           | secure section type (ID:9)|  |
           |                           |  |
      +----|-> [ security key data ]   |  |
      |    +---------------------------+ -/
      |    |MSS Pool for above section |
      |    |  [ security key data 1 ]  |
      +----|- [ security key data 2 ]  |
by mss_idx |  [ security key data 3 ]  |
           |  ...                 M    | * M = MSSC (MSSC != 0xFF)
           +---------------------------+

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

wifi: rtw89: fw: move v1 MSSC out of __parse_security_section() to share with v0

The security section can be a common parser for v0 and v1 format of
firmware header, so move retrieval code of v1 MSSC from the function, and
then sharing becomes possible.

Not logic change at all.

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

wifi: rtw89: fw: set recorded IDMEM share mode in firmware header to register

For WiFi 6 chips, firmware secure boot will run on a IDMEM mode specified
in firmware header. Retrieve the mode from firmware, and set to registers
accordingly.

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

wifi: rtw89: fw: shrink download size of security section for RTL8852B

For RTL8852B, when current firmware is secure boot, the security section
needs a special treatment that shrink its size to 960.

As figure below, not only shrink the amount of download size of security
section (2), but also need to modify the section size in firmware header
(1) that is also downloaded to chip.

   +---------------------------+
   |      firmware header      |
   |                           |
   | +-----------------------+ |
   | | section type, size N -|-|-------+
   | | ...               (1) | |       |
   | +-----------------------+ |       |
   +---------------------------+       | 2048 shrink to 960
   :                           :       |
   +---------------------------+ -\    |
   |  security section type 9  |  |    |
   |           (2)             |  | <--+
   |                           |  |
   +---------------------------+ -/

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

wifi: rtw89: efuse: read firmware secure info v0 from efuse for WiFi 6 chips

WiFi 6 chips could program secure information in v0 or v1 format. Use
existing v1 parser or newly added v0 parser to recognize firmware key
that is going to be used.

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

wifi: rtw89: efuse: move recognize firmware MSS info v1 to common

The WiFi 6 chip use the same firmware MSS information v1 read from efuse,
so move this logic to common.

No change logic at all.

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

wifi: rtw89: efuse: move reading efuse of fw secure info to common

The secure key used by certain hardware module is programmed in efuse, so
driver should read the information from efuse before downloading firmware.

Originally only RTL8922AE can support firmware secure boot, and read efuse
during chip power on. To extend to support all chips, move the caller to
common power on flow and add separate functions to read efuse for
WiFi 6 chips.

No logic change at all.

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

wifi: rtw89: set pause_data field to avoid transmitting data in scan channels

Set pause_data to all of the scan channels, excluding the OP channel,
to prevent data frame transmission to the scan channels, which causes
retransmission. Additionally, this flag won't affect the transmission
of probe requests from the scan channels.

Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241026022143.7304-1-pkshih@realtek.com

wifi: rtw89: don't check done-ack for entering PS

In WoWLAN mode, driver will disable interrupt after calling H2C command
for entering PS mode, but it may lead to failing to enter deep PS mode by
firmware because the done-ack of the H2C from firmware is not handled by
driver. In fact, the done-ack for entering PS is not necessary for driver
to check, so remove it.

Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241024055509.8000-1-pkshih@realtek.com

wifi: rtw88: 8812a: Mitigate beacon loss

The RTL8812AU has a reception problem, maybe only in the 5 GHz band.
Sometimes, in some positions, it stops receiving anything even though
the distance to the AP is only ~3 meters and there are no obstacles.
Moving it a few centimeters fixes it.

Switch the initial gain to maximum coverage when there is beacon loss.
This only helps sometimes. This is similar to what the official driver
does.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/203f5043-4fe1-4f35-8b8f-d3b6f44e1fd9@gmail.com

wifi: rtw88: 8821a: Regularly ask for BT info updates

The RTL8821AU firmware sends C2H_BT_INFO by itself when bluetooth
headphones are connected, but not when they are disconnected. This leads
to the coexistence code still using the A2DP algorithm long after the
headphones are disconnected, which means the wifi speeds are much lower
than they should be. Work around this by asking for updates every two
seconds if the chip is RTL8821AU.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/358acdd2-6aae-46c1-9c66-fcce4e700b96@gmail.com

wifi: rtw88: coex: Support chips without a scoreboard

All the chips currently supported have a "scoreboard": the chip keeps
track of certain things related to bluetooth, for example, whether
bluetooth is active. The information can be read from register 0xaa.

RTL8821AU doesn't have this. Implement bluetooth activity detection in
rtw_coex_monitor_bt_enable() based on the bluetooth TX/RX counters.

This is mostly important for RTL8811AU, the version of RTL8821AU without
bluetooth. Without this change, the driver thinks bluetooth is active
and the wifi speeds are low.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/5058f23d-2086-42cd-82ad-eef31a348467@gmail.com

wifi: rtw88: Detect beacon loss with chips other than 8822c

The driver is supposed to avoid entering LPS (power saving) when there
is beacon loss, but only RTL8822C detects the beacon loss (because it
has beacon filtering in the firmware).

Detect beacon loss with the other chips by checking if we received less
than half the expected number of beacons in the last 2-second interval.

This gets rid of the occasional "failed to get tx report from firmware"
warnings with RTL8821AU. It may also avoid some disconnections.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/f52b2fcf-bf94-48bc-89bd-e55ebc3a2f2d@gmail.com

wifi: rtw88: usb: Set pkt_info.ls for the reserved page

"ls" meaning "last segment". Without this RTL8812AU can't upload the
reserved page in USB 2 mode. (Somehow it's fine in USB 3 mode.)

Also tested with RTL8822CU, RTL8812BU, RTL8811CU, RTL8723DU, RTL8811AU.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/e443f5d9-4b53-4f64-985c-64313ec80bef@gmail.com

wifi: rtw88: Move pwr_track_tbl to struct rtw_rfe_def

RTL8812AU uses one set of TX power tracking tables for RFE 3, and
another set for everything else.

Move pwr_track_tbl from struct rtw_chip_info to struct rtw_rfe_def in
order to load the right set of tables for each RFE (RF front end) type.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/904d0ab1-c046-40cd-a3a3-d4fdcf663c9d@gmail.com

wifi: rtw88: Support TX page sizes bigger than 128

All the chips supported so far have a TX page size of 128 bytes.

Change the type of the page_size member of struct rtw_chip_info from u8
to u16 in order to support RTL8821AU (page size of 256 bytes) and
RTL8812AU (page size of 512 bytes). Also change the types of several
related variables and function parameters from u8 to u16.

The TX page size is used, among other things, to construct the beacon,
null data, QOS null data, and PS poll templates which are uploaded to
the chip's reserved page. Each template needs to be aligned on a
multiple of the TX page size. Power saving can't work if the TX page
size is wrong.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/acdefbb1-3daf-4349-9e03-9472754d5f1e@gmail.com

wifi: rtw88: Make txagc_remnant_ofdm an array

txagc_remnant_ofdm member of struct rtw_dm_info should be different for
each RF path, so make it an array of size RTW_RF_PATH_MAX (4).

Until now all the chips using this had only one RF path, but RTL8812AU
has two, and RTL8814AU has four.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/68571ba9-e504-4b2d-bfa1-62f468753649@gmail.com

wifi: rtw88: Enable data rate fallback for older chips

RTL8811AU fails to perform the 4-way handshake when the AP is too far
because it transmits the EAPOL frames at MCS9 and when that doesn't
work it retries 48 times with the same rate, to no avail.

Retrying 48 times with the same rate seems pointless. Set the
appropriate field in the TX descriptor to allow it to use lower rates
when retrying.

Set it for RTL8723D and RTL8703B because they interpret this field the
same way as RTL8811A.

The newer RTL8822C, RTL8822B, RTL8821C seem to interpret this field in
the TX descriptor differently, so leave it alone for those chips.

Tested with RTL8811AU and RTL8723DU.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/2b3e3e6f-541b-4a3b-8ca3-65b267e6a95a@gmail.com

wifi: rtw88: Let each driver control the power on/off process

RTL8821AU and RTL8812AU have to do some things differently, so let
them have full control.

The other chips use the same functions as before.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/98ab839f-9100-44ae-9551-9af743a4aa3a@gmail.com

wifi: rtw88: Allow rtw_chip_info.ltecoex_addr to be NULL

RTL8821A doesn't have this. Trying to use it results in error messages,
so don't try if ltecoex_addr is NULL.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/d1004817-1760-41d1-9136-3d799757c444@gmail.com

wifi: rtw88: Extend the init table parsing for RTL8812AU

The chips supported so far only use the first condition, and so the
parsing code ignores the second condition. RTL8812AU's init tables use
the second condition also. Make the parsing code check it.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/1bee6b74-6eab-44a3-9f40-794ca006c72d@gmail.com

wifi: rtw88: Allow different C2H RA report sizes

The RTL8821AU and RTL8812AU have smaller RA report size, only 4 bytes.
Avoid the "invalid ra report c2h length" error.

Also, use a struct and u8_get_bits() to access the RA report C2H.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/c3e73c3a-fb2f-4013-9f06-d5274211e282@gmail.com

wifi: rtw88: Dump the HW features only for some chips

RTL8821AU and RTL8812AU don't support this. They hit the "failed to read
hw feature report" error.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/8becd851-8760-4480-8e8c-c4869ce72507@gmail.com

wifi: rtw88: Add some definitions for RTL8821AU/RTL8812AU

Add 8821A and 8812A chip type enums.

Add cck_high_power member to struct rtw_hal. This will be used to
calculate the RX signal strength of RTL8812AU.

Add various register definitions which will be used by the new drivers.

Move some existing register definitions from rtw8821c.h and rtw8822b.h.
They were duplicated in those headers and will also be used by the new
drivers.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/9279a9cd-6f86-4dc3-a095-7c36cb9b9d06@gmail.com

wifi: rtw88: Report the signal strength only if it's known

RTL8811CU doesn't report the signal strength for many (any?) data
frames. When the signal strength is not known, set
RX_FLAG_NO_SIGNAL_VAL in order to avoid reporting a signal
strength of 0.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/f7e1e448-2c9b-498f-b8b1-a14dd967d7d3@gmail.com

wifi: rtw89: 8922a: extend RFK handling and consider MLO

Extend FW and driver handling on RFK to support it on both HW bands.
Then, according to MLO cases, do the corresponding RF settings.

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

wifi: rtw89: tweak setting of channel and TX power for MLO

Setting of channel and TX power depend on channel contexts, but original
code cannot handle combination of MCC (multi-channel concurrency) and MLO
well. So according to active interfaces, we generate a table for current
channel contexts. And then based on entity mode, we get the corresponding
channel context to apply during channel or TX power setting. When MLO is
supported, there will be dual-PHY and we will apply the channel context of
the 2nd link to the 2nd PHY.

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

wifi: rtw89: chan: manage active interfaces

To set channel well for combination of MCC (multi-channel concurrency) and
impending MLO support, we need a method to manage relation between active
interfaces and channel contexts. If an interface owns at least one active
link, we call it an active interface. We add a list to manage active ones.

Basically, the list follows the active order except for the below case. To
be compatible with legacy behavior, the first interface that owns the first
channel context will put at the first entry in the list when recalculating.

Besides, MCC can also select and fill roles based on the above active list.

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

wifi: rtw89: Add encryption support for MLO connections

In order to make encryption/decryption work properly with MLO
connections, MLD address needs to be filled in so circuits can
operate with the correct information.

Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241022083106.149252-3-pkshih@realtek.com

wifi: rtw89: Add header conversion for MLO connections

For MLO connections, this setting replaces 802.11 header addresses
to according link addresses based on each packet's destination.
The fields most likely to be replaced would be both A1 and A2.
For legacy connections, it's the same with or without the conversion.

Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241022083106.149252-2-pkshih@realtek.com

wifi: rtw89: unlock on error path in rtw89_ops_unassign_vif_chanctx()

We need to call mutex_unlock() on this error path.

Fixes: aad0394e7a02 ("wifi: rtw89: tweak driver architecture for impending MLO support")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/8683a712-ffc2-466b-8382-0b264719f8ef@stanley.mountain

wifi: rtw89: Fix TX fail with A2DP after scanning

There might be some racing between BT and WiFi after scan. Since
one of the TX related register will be modified by both FW and
rtw89_set_channel() in driver, which could cause Tx fail. Reorder
the calling sequence to only notify coexistence mechanism after
rtw89_set_channel() is called, so that there are no concurrent
operations.

Fixes: 5f499ce69b8d ("wifi: rtw89: pause/proceed MCC for ROC and HW scan")
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241021063219.22613-1-pkshih@realtek.com

wifi: rtw89: coex: Set Wi-Fi/Bluetooth priority for Wi-Fi scan case

The priority table should be changed according to what the in using
Bluetooth application is. To avoid Bluetooth audio + HID (mouse) will
trigger the lag experience, update the priority table.

Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241019063131.9462-1-pkshih@realtek.com

wifi: rtw89: fix -Wenum-compare-conditional warnings

This is one of three drivers that trigger -Wenum-compare-conditional warnings
with clang:

drivers/net/wireless/realtek/rtw89/core.c:1806:14: error: conditional expression between different enumeration types ('enum nl80211_eht_gi' and 'enum nl80211_he_gi') [-Werror,-Wenum-compare-conditional]
 1806 |                 return eht ? NL80211_RATE_INFO_EHT_GI_0_8 :
      |                            ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 1807 |                              NL80211_RATE_INFO_HE_GI_0_8;
      |                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/realtek/rtw89/core.c:1810:14: error: conditional expression between different enumeration types ('enum nl80211_eht_gi' and 'enum nl80211_he_gi') [-Werror,-Wenum-compare-conditional]
 1810 |                 return eht ? NL80211_RATE_INFO_EHT_GI_1_6 :
      |                            ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 1811 |                              NL80211_RATE_INFO_HE_GI_1_6;
      |                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/realtek/rtw89/core.c:1813:14: error: conditional expression between different enumeration types ('enum nl80211_eht_gi' and 'enum nl80211_he_gi') [-Werror,-Wenum-compare-conditional]
 1813 |                 return eht ? NL80211_RATE_INFO_EHT_GI_3_2 :
      |                            ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 1814 |                              NL80211_RATE_INFO_HE_GI_3_2;
      |                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/realtek/rtw89/core.c:1818:15: error: conditional expression between different enumeration types ('enum nl80211_eht_gi' and 'enum nl80211_he_gi') [-Werror,-Wenum-compare-conditional]
 1818 |                         return eht ? NL80211_RATE_INFO_EHT_GI_3_2 :
      |                                    ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 1819 |                                      NL80211_RATE_INFO_HE_GI_3_2;
      |                                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~

In this case, all four warnings can be easily avoided by splitting the
function into two separate ones, in a way that helps readability as well,
at the expense of a few extra source lines.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241018152311.4023979-1-arnd@kernel.org

wifi: rtlwifi: use MODULE_FIRMWARE() to declare used firmware

Some used firmware are missing to be added to MODULE_FIRMWARE().
Add them accordingly.

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

wifi: rtw88: Refactor looping in rtw_phy_store_tx_power_by_rate

The previous implementation included an unnecessary else
condition paired with a continue statement. Since a check
is already performed to determine if the band is either
2G or 5G, the else condition will never be triggered.
We can remove this check.

Signed-off-by: Mohammed Anees <pvmohammedanees2003@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241017080638.13074-1-pvmohammedanees2003@gmail.com

wifi: rtw89: regd: block 6 GHz if marked as N/A in regd map

If 6 GHz of a country is marked as N/A in our regd map,
we block 6 GHz channels now.

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

wifi: rtw89: pci: add quirks by PCI subsystem ID for thermal protection

Specific PCI subsystem ID (SSID) of WiFi cards is used by specific
customer who want to enable various features with different arguments.

Define PCI SSID quirks tables to enable thermal protection with two kinds
of thermal values for 110 and 120 degree Celsius.

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

wifi: rtw89: add thermal protection

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

wifi: rtw89: sar: add supported UNII-4 frequency range along with UNII-3 of SAR subband

The UNII-4 uses the same SAR value of UNII-3, so add UNII-4 frequency
range and change the enum name to represent UNII-3 and UNII-4.

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

wifi: rtw89: 8852c: use 'int' as return type of error code pwr_{on,off}_func()

The return type of error code of rtw8852c_pwr_{on,off}_func() and its
callee is 'int'. Correct it.

Addresses-Coverity-ID: 1626056 ("Overflowed constant")
Addresses-Coverity-ID: 1627945 ("Overflowed constant")

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

wifi: rtw89: 8852bt: use 'int' as return type of error code pwr_{on,off}_func()

The return type of error code of rtw8852bt_pwr_{on,off}_func() and its
callee is 'int'. Correct it.

Addresses-Coverity-ID: 1630962 ("Overflowed constant")
Addresses-Coverity-ID: 1632126 ("Overflowed constant")

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

wifi: rtw89: 8852b: use 'int' as return type of error code pwr_{on,off}_func()

The return type of error code of rtw8852b_pwr_{on,off}_func() and its
callee is 'int'. Correct it.

Addresses-Coverity-ID: 1622433 ("Overflowed constant")
Addresses-Coverity-ID: 1630710 ("Overflowed constant")

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

wifi: rtw89: 8851b: use 'int' as return type of error code pwr_{on,off}_func()

The return type of error code of rtw8851b_pwr_{on,off}_func() and its
callee is 'int'. Correct it.

Addresses-Coverity-ID: 1624679 ("Overflowed constant")
Addresses-Coverity-ID: 1630970 ("Overflowed constant")

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

wifi: rtw89: pci: use 'int' as return type of error code in poll_{tx,rx}dma_ch_idle()

The return type of error code of read_poll_timeout() and
rtw89_pci_poll_{tx,rx}dma_ch_idle_ax() and must be 'int'.
Correct them accordingly.

Addresses-Coverity-ID: 1622341 ("Overflowed constant")
Addresses-Coverity-ID: 1627296 ("Overflowed constant")

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

wifi: rtw89: wow: cast nd_config->delay to u64 in tsf arithmetic

The type of tsf arithmetic is
   u64 += u16 * int;

When (u16 * int) is larger than 0x7FFFFFFF, the value casting to u64 with
sign-extension will become all 1 in upper 32 bits part.

To meet the case, u16 value should be larger than 20491
(0x7FFFFFFF / 104800). Fortunately the meaning of 20491 is delay time of
WoWLAN net detection in unit of second, so 20491 seconds (5.7 hours)
might not a real case we can meet.

Addresses-Coverity-ID: 1620910 ("Unintended sign extension")

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

Merge tag 'rtw-next-2024-10-10' of https://github.com/pkshih/rtw

rtw-next patches for v6.13

No big change at this point. Regular development and fixes are listed:

rtl8xxxu:
 - correct beaconing for the case of STA + AP

rtw88:
 - consolidate parser of RX descriptor as preparation to support coming
   chips

rtw89:
 - update BT-coexistence to improve user experience for RTL8852BE and
   RTL8852BE-VT
 - correct RTL8922AE RF calibration timeout time and print out firmware
   log
 - set proper PCI EQ value for RTL8852CE and RTL8922AE
 - adjust to support MLO continuously

wifi: cw1200: Remove unused cw1200_queue_requeue_all()

cw1200_queue_requeue_all() has been unused since it was added in 2013 by commit
a910e4a94f69 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets")

Remove it.

Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241012203852.229151-1-linux@treblig.org

wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()

Replace one-element array with a flexible-array member in `struct
mwifiex_ie_types_wildcard_ssid_params` to fix the following warning
on a MT8173 Chromebook (mt8173-elm-hana):

[  356.775250] ------------[ cut here ]------------
[  356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)
[  356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]

The "(size 6)" above is exactly the length of the SSID of the network
this device was connected to. The source of the warning looks like:

    ssid_len = user_scan_in->ssid_list[i].ssid_len;
    [...]
    memcpy(wildcard_ssid_tlv->ssid,
           user_scan_in->ssid_list[i].ssid, ssid_len);

There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this
struct, but it already didn't account for the size of the one-element
array, so it doesn't need to be changed.

Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Acked-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241007222301.24154-1-alpernebiyasak@gmail.com

wifi: brcmfmac: of: use devm_clk_get_optional_enabled_with_rate()

Fold the separate clk_set_rate() call into the clock getter.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241007131639.98358-1-brgl@bgdev.pl

wifi: brcmsmac: Remove unused brcms_debugfs_get_devdir()

brcms_debugfs_get_devdir() has been unused since it was added by commit
8e21df23894e ("brcmsmac: hardware info in debugfs")

Remove it.

Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241004004259.470853-1-linux@treblig.org

wifi: brcmfmac: Remove unused brcmf_cfg80211_get_iftype()

brcmf_cfg80211_get_iftype() has been unused since 2013's commit
5cd51c2bad56 ("brcmfmac: Find correct MAC descriptor in case of TDLS.")

Remove it.

Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241004004252.470836-1-linux@treblig.org

wifi: wilc1000: Set MAC after operation mode

It seems it is necessary to set WILC MAC address after operation mode,
otherwise the MAC address of the WILC MAC is reset back to what is in
nvmem. This causes a failure to associate with AP after the WILC MAC
address was overridden by userspace.

Test case:
"
ap$ cat << EOF > hostap.conf
interface=wlan0
ssid=ssid
hw_mode=g
channel=6
wpa=2
wpa_passphrase=pass
wpa_key_mgmt=WPA-PSK
EOF
ap$ hostapd -d hostap.conf
ap$ ifconfig wlan0 10.0.0.1
"

"
sta$ ifconfig wlan0 hw ether 00:11:22:33:44:55
sta$ wpa_supplicant -i wlan0 -c <(wpa_passphrase ssid pass)
sta$ ifconfig wlan0 10.0.0.2
sta$ ping 10.0.0.1 # fails without this patch
"

AP still indicates SA with original MAC address from nvmem without this patch:
"
nl80211: RX frame da=ff:ff:ff:ff:ff:ff sa=60:01:23:45:67:89 bssid=ff:ff:ff:ff:ff:ff ...
                                          ^^^^^^^^^^^^^^^^^
"

Fixes: 83d9b54ee5d4 ("wifi: wilc1000: read MAC address from fuse at probe")
Tested-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241003132504.52233-1-marex@denx.de

wifi: mwifiex: cleanup struct mwifiex_private

Remove set but otherwise unused 'adhoc_is_link_sensed' and
'assoc_resp_ht_param' members of 'struct mwifiex_private' and
simplify related code in 'mwifiex_ret_802_11_associate()'.
Compile tested only.

Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240927084317.96687-2-dmantipov@yandex.ru

wifi: mwifiex: cleanup struct mwifiex_auto_tdls_peer

Remove set but otherwise unused 'do_setup' member of
'struct mwifiex_auto_tdls_peer'. Compile tested only.

Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240927084317.96687-1-dmantipov@yandex.ru

wifi: wilc1000: Add WILC3000 support

Add support for the WILC3000 chip. The chip is similar to WILC1000,
except that the register layout is slightly different and it does
not support WPA3/SAE.

Reviewed-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Tested-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Tested-on: WILC1000SD 07 SDIO WILC_WIFI_FW_REL_16_1_2
Tested-on: WILC1000SD 07 SPI WILC_WIFI_FW_REL_16_1_2
Tested-on: WILC3000 A SDIO WILC_WIFI_FW_REL_16_1_1
Tested-on: WILC3000 A SPI WILC_WIFI_FW_REL_16_1_1
Signed-off-by: Ajay Singh <ajay.kathat@microchip.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241004114551.40236-7-marex@denx.de

wifi: wilc1000: Register wiphy after reading out chipid

Register wiphy after reading out chipid, so the chipid can be
used to determine chip features and not advertise WPA3/SAE
support to userspace on WILC3000. Note that wilc_netdev_cleanup()
will deregister the wiphy in fail path.

Tested-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Tested-on: WILC1000SD 07 SDIO WILC_WIFI_FW_REL_16_1_2
Tested-on: WILC3000 A SDIO WILC_WIFI_FW_REL_16_1_1
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241004114551.40236-6-marex@denx.de

wifi: wilc1000: Fold wilc_create_wiphy() into cfg80211.c

The wilc_create_wiphy() is not used outside of cfg80211.c .
Make the function static and remove its entry from cfg80211.h

Reviewed-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241004114551.40236-5-marex@denx.de

wifi: wilc1000: Fill in missing error handling

Add error handling to chip_wakeup() and propagate the errors throughout
the entire driver. Add error handling to acquire_bus()/release_bus() and
host_sleep_notify()/host_wakeup_notify() functions as a result as well.
Fill the error handling to all call sites.

Reviewed-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241004114551.40236-4-marex@denx.de

wifi: wilc1000: Fold chip_allow_sleep()/chip_wakeup() into wlan.c

Neither chip_allow_sleep()/chip_wakeup() is used outside of wlan.c .
Make both functions static and remove both the exported symbol and
entries from wlan.h .

Make chip_allow_sleep() return error code in preparation for the
follow up patches.

Move acquire_bus() and release_bus() to avoid forward declaration
of chip_allow_sleep()/chip_wakeup().

Reviewed-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241004114551.40236-3-marex@denx.de

wifi: wilc1000: Clean up usage of wilc_get_chipid()

Reduce the use of wilc_get_chipid(), use cached chip ID wherever
possible. Remove duplicated partial chip ID read implementations
from the driver. Update wilc_get_chipid() to always read the chip
ID out of the hardware and update the cached chip ID, and make it
return a proper return value instead of a chipid. Call wilc_get_chipid()
early to make the cached chip ID available to various sites using
is_wilc1000() to access the cached chip ID.

Reviewed-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241004114551.40236-2-marex@denx.de

dt-bindings: wireless: wilc1000: Document WILC3000 compatible string

Document compatible string for the WILC3000 chip. The chip is similar
to WILC1000, except that the register layout is slightly different and
it does not support WPA3/SAE.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241004114551.40236-1-marex@denx.de

wifi: wilc1000: Keep slot powered on during suspend/resume

The WILC3000 can suspend and enter low power state. According to local
measurements, the WILC3000 consumes the same amount of power if the slot
is powered up and WILC3000 is suspended, and if the WILC3000 is powered
off. Use the former option, keep the WILC3000 powered up as that allows
for things like WoWlan to work.

Note that this is tested on WILC3000 only, not on WILC1000 .

Signed-off-by: Marek Vasut <marex@denx.de>
Tested-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240926195113.2823392-1-marex@denx.de

wifi: rt2x00: convert comma to semicolon

To ensure code clarity and prevent potential errors, it's advisable
to employ the ';' as a statement separator, except when ',' are
intentionally used for specific purposes.

Signed-off-by: Yan Zhen <yanzhen@vivo.com>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240920025917.1959932-1-yanzhen@vivo.com

wifi: mwifiex: add missing locking for cfg80211 calls

cfg80211_rx_assoc_resp() and cfg80211_rx_mlme_mgmt() need to be called
with the wiphy locked, so lock it before calling these functions.

Fixes: 36995892c271 ("wifi: mwifiex: add host mlme for client mode")
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240918-mwifiex-cleanup-1-v2-1-2d0597187d3c@pengutronix.de

wifi: ipw: select CRYPTO_LIB_ARC4

With the WEP/TKIP code having moved to libipw, it now
needs to select CRYPTO_LIB_ARC4 to have the dependency,
and I forgot to move that.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202410111727.FxATs8Yj-lkp@intel.com/
Fixes: 02f220b52670 ("wifi: ipw2x00/lib80211: move remaining lib80211 into libipw")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241011115820.070c468b271d.Iac76e81b5cd9a5b949b8c154381128e8131d581d@changeid

wifi: rtw89: wow: do not configure CPU IO to receive packets for old firmware

The older firmware of 8852A and 8852B can't receive packets via
CPU IO function and will lead to WoWLAN fail if calling it.
So use firmware feature to distinguish.

Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241004065408.10261-1-pkshih@realtek.com

wifi: rtw89: coex: Add function to reorder Wi-Fi firmware report index

To parsing firmware report correctly, driver need to re-order the report
index to match with different chips and different Wi-Fi firmware version.
Use wrong index to parse the report will lead the coexistence run into
wrong mechanism.

Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241003105140.10867-5-pkshih@realtek.com

wifi: rtw89: coex: Solved BT PAN profile idle decrease Wi-Fi throughput

Some Bluetooth device will make up connection as PAN link, though the
connection is idle, it will still report the PAN link is active. The
coexistence mechanism will enable TDMA to protect the PAN, it makes
Wi-Fi throughput degrade at least 50%. But the link is idle, don't
need so much bandwidth. Add TDMA case to let Wi-Fi can do traffic 80%
bandwidth.

Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241003105140.10867-4-pkshih@realtek.com

wifi: rtw89: coex: Reorder Bluetooth info related logic

Reorder Bluetooth firmware related event index, it should be the same
with Wi-Fi firmware definition. To fix coexistence can not recognize
Bluetooth PAN(Personal area network) profile correctly, modified the
related logic.

Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241003105140.10867-3-pkshih@realtek.com

wifi: rtw89: coex: Update priority setting for Wi-Fi is scanning

Update coexistence priority setting for Wi-Fi scanning channel, the new
setting will allow Wi-Fi do RX while Bluetooth audio is not busy. Forced
to set new TDMA policy while RF calibration request come, to make sure
the calibration can do well, and switch to normal setting while the
calibration is done. Remove the code that no longer use.

Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241003105140.10867-2-pkshih@realtek.com

Merge net-next/main to resolve conflicts

The wireless-next tree was based on something older, and there
are now conflicts between -rc2 and work here. Merge net-next,
which has enough of -rc2 for the conflicts to happen, resolving
them in the process.

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

Revert "wifi: cfg80211: unexport wireless_nlevent_flush()"

Revert this, I neglected to take into account the fact that
cfg80211 itself can be a module, but wext is always builtin.

Fixes: aee809aaa2d1 ("wifi: cfg80211: unexport wireless_nlevent_flush()")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

net: phy: microchip_t1: SQI support for LAN887x

Add support for measuring Signal Quality Index for LAN887x T1 PHY.
Signal Quality Index (SQI) is measure of Link Channel Quality from
0 to 7, with 7 as the best. By default, a link loss event shall
indicate an SQI of 0.

Signed-off-by: Tarun Alle <Tarun.Alle@microchip.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20241007063943.3233-1-tarun.alle@microchip.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Merge branch 'net-phy-marvell-88q2xxx-enable-auto-negotiation-for-mv88q2110'

Niklas Söderlund says:

====================
net: phy: marvell-88q2xxx: Enable auto negotiation for mv88q2110

This series enables auto negotiation for the mv88q2110 device.
Previously this feature have been disabled for mv88q2110, while enabled
for other devices supported by this driver.

The initial driver implementation states this is due to the
configuration sequence provided by the vendor did not work. By comparing
the initialization sequence of other devices this driver supports and
the out-of-tree PHY driver for mv88q2110 found in the Renesas BSP [1]
I was able to figure out a working configuration.

As I have no access to the datasheets of either of these devices it
would be super if someone who has could sanity check the initialization
sequence.

With this series I'm able to auto negotiate both 1000Mbps and 100Mbps
links without issue.

    # ethtool eth0
    Settings for eth0:
            Supported ports: [  ]
            Supported link modes:   100baseT1/Full
                                    1000baseT1/Full
            Supported pause frame use: Symmetric Receive-only
            Supports auto-negotiation: Yes
            Supported FEC modes: Not reported
            Advertised link modes:  100baseT1/Full
                                    1000baseT1/Full
            Advertised pause frame use: No
            Advertised auto-negotiation: Yes
            Advertised FEC modes: Not reported
            Link partner advertised link modes:  100baseT1/Full
                                                 1000baseT1/Full
            Link partner advertised pause frame use: No
            Link partner advertised auto-negotiation: Yes
            Link partner advertised FEC modes: Not reported
            Speed: 1000Mb/s
            Duplex: Full
            Auto-negotiation: on
            master-slave cfg: preferred master
            master-slave status: slave
            Port: Twisted Pair
            PHYAD: 0
            Transceiver: external
            MDI-X: Unknown
            Link detected: yes
            SQI: 15/15

And the performance is good too. Without this change I was not able to
manually configure a 1000Mbps link, only 100Mbps ones. So this gives a
huge performance boost for my use-case.

    [  5] local 10.1.0.2 port 5201 connected to 10.1.0.1 port 38346
    [ ID] Interval           Transfer     Bitrate         Retr  Cwnd
    [  5]   0.00-1.00   sec  96.8 MBytes   812 Mbits/sec    0    469 KBytes
    [  5]   1.00-2.00   sec  94.3 MBytes   791 Mbits/sec    0    469 KBytes
    [  5]   2.00-3.00   sec  96.1 MBytes   806 Mbits/sec    0    469 KBytes
    [  5]   3.00-4.00   sec  98.3 MBytes   825 Mbits/sec    0    469 KBytes
    [  5]   4.00-5.00   sec  98.4 MBytes   825 Mbits/sec    0    469 KBytes
    [  5]   5.00-6.00   sec  98.4 MBytes   826 Mbits/sec    0    469 KBytes
    [  5]   6.00-7.00   sec  98.9 MBytes   830 Mbits/sec    0    469 KBytes
    [  5]   7.00-8.00   sec  91.7 MBytes   769 Mbits/sec    0    469 KBytes
    [  5]   8.00-9.00   sec  99.4 MBytes   834 Mbits/sec    0    747 KBytes
    [  5]   9.00-10.00  sec   101 MBytes   851 Mbits/sec    0    747 KBytes

Patch 1/3 and 2/3 are preparation patches that align and move functions
around as the mv88q2110 code paths can now reuses much of what is done
for mv88q2220. While patch 3/3 adds the new initialization sequence and
removes the auto negotiation limit for mv88q2110.

1.  https://github.com/renesas-rcar/linux-bsp/commit/2a1f07d0e722a18188cfe62842b61f2fbc0ba812
====================

Link: https://patch.msgid.link/20241005112412.544360-1-niklas.soderlund+renesas@ragnatech.se
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

net: phy: marvell-88q2xxx: Enable auto negotiation for mv88q2110

The initial marvell-88q2xxx driver only supported the Marvell 88Q2110
PHY without auto negotiation support. The reason documented states that
the provided initialization sequence did not to work. Now a method to
enable auto negotiation have been found by comparing the initialization
of other supported devices and an out-of-tree PHY driver.

Perform the minimal needed initialization of the PHY to get auto
negotiation working and remove the limitation that disables the auto
negotiation feature for the mv88q2110 device.

With this change a 1000Mbps full duplex link is able to be negotiated
between two mv88q2110 and the link works perfectly. The other side also
reflects the manually configure settings of the master device.

    # ethtool eth0
    Settings for eth0:
            Supported ports: [  ]
            Supported link modes:   100baseT1/Full
                                    1000baseT1/Full
            Supported pause frame use: Symmetric Receive-only
            Supports auto-negotiation: Yes
            Supported FEC modes: Not reported
            Advertised link modes:  100baseT1/Full
                                    1000baseT1/Full
            Advertised pause frame use: No
            Advertised auto-negotiation: Yes
            Advertised FEC modes: Not reported
            Link partner advertised link modes:  100baseT1/Full
                                                 1000baseT1/Full
            Link partner advertised pause frame use: No
            Link partner advertised auto-negotiation: Yes
            Link partner advertised FEC modes: Not reported
            Speed: 1000Mb/s
            Duplex: Full
            Auto-negotiation: on
            master-slave cfg: preferred master
            master-slave status: slave
            Port: Twisted Pair
            PHYAD: 0
            Transceiver: external
            MDI-X: Unknown
            Link detected: yes
            SQI: 15/15

Before this change I was not able to manually configure 1000Mbps link,
only a 100Mpps link so this change providers an improvement in
performance for this device.

    [  5] local 10.1.0.2 port 5201 connected to 10.1.0.1 port 38346
    [ ID] Interval           Transfer     Bitrate         Retr  Cwnd
    [  5]   0.00-1.00   sec  96.8 MBytes   812 Mbits/sec    0    469 KBytes
    [  5]   1.00-2.00   sec  94.3 MBytes   791 Mbits/sec    0    469 KBytes
    [  5]   2.00-3.00   sec  96.1 MBytes   806 Mbits/sec    0    469 KBytes
    [  5]   3.00-4.00   sec  98.3 MBytes   825 Mbits/sec    0    469 KBytes
    [  5]   4.00-5.00   sec  98.4 MBytes   825 Mbits/sec    0    469 KBytes
    [  5]   5.00-6.00   sec  98.4 MBytes   826 Mbits/sec    0    469 KBytes
    [  5]   6.00-7.00   sec  98.9 MBytes   830 Mbits/sec    0    469 KBytes
    [  5]   7.00-8.00   sec  91.7 MBytes   769 Mbits/sec    0    469 KBytes
    [  5]   8.00-9.00   sec  99.4 MBytes   834 Mbits/sec    0    747 KBytes
    [  5]   9.00-10.00  sec   101 MBytes   851 Mbits/sec    0    747 KBytes

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Tested-by: Stefan Eichenberger <eichest@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20241005112412.544360-4-niklas.soderlund+renesas@ragnatech.se
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

net: phy: marvell-88q2xxx: Make register writer function generic

In preparation to adding auto negotiation support to mv88q2110 move and
rename the helper function used to write an array of register values to
the PHY.

Just as for mv88q2220 devices this helper will be needed to for the
initial configuration of the mv88q2110 to support auto negotiation.

The function is moved verbatim, there is no change in behavior.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Dimitri Fedrau <dima.fedrau@gmail.com>
Tested-by: Stefan Eichenberger <eichest@gmail.com>
Link: https://patch.msgid.link/20241005112412.544360-3-niklas.soderlund+renesas@ragnatech.se
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

net: phy: marvell-88q2xxx: Align soft reset for mv88q2110 and mv88q2220

The soft reset implementations for mv88q2110 and mv88q2220 differ as the
later need to consider that auto negation is supported on mv88q2220
devices. In preparation of enabling auto negotiation on mv88q2110 merge
the two rest functions into a device generic one.

The mv88q2220 behavior is kept as is but extended to wait for the reset
bit to be clears before continuing, as was done previously on mv88q2220.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Dimitri Fedrau <dima.fedrau@gmail.com>
Tested-by: Stefan Eichenberger <eichest@gmail.com>
Link: https://patch.msgid.link/20241005112412.544360-2-niklas.soderlund+renesas@ragnatech.se
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

fsl/fman: Fix a typo

Fix a typo in comments: bellow -> below.

Reported-by: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Andrew Kreimer <algonell@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20241006130829.13967-1-algonell@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

net: phy: aquantia: allow forcing order of MDI pairs

Despite supporting Auto MDI-X, it looks like Aquantia only supports
swapping pair (1,2) with pair (3,6) like it used to be for MDI-X on
100MBit/s networks.

When all 4 pairs are in use (for 1000MBit/s or faster) the link does not
come up with pair order is not configured correctly, either using
MDI_CFG pin or using the "PMA Receive Reserved Vendor Provisioning 1"
register.

Normally, the order of MDI pairs being either ABCD or DCBA is configured
by pulling the MDI_CFG pin.

However, some hardware designs require overriding the value configured
by that bootstrap pin. The PHY allows doing that by setting a bit in
"PMA Receive Reserved Vendor Provisioning 1" register which allows
ignoring the state of the MDI_CFG pin and another bit configuring
whether the order of MDI pairs should be normal (ABCD) or reverse
(DCBA). Pair polarity is not affected and remains identical in both
settings.

Introduce property "marvell,mdi-cfg-order" which allows forcing either
normal or reverse order of the MDI pairs from DT.

If the property isn't present, the behavior is unchanged and MDI pair
order configuration is untouched (ie. either the result of MDI_CFG pin
pull-up/pull-down, or pair order override already configured by the
bootloader before Linux is started).

Forcing normal pair order is required on the Adtran SDG-8733A Wi-Fi 7
residential gateway.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/9ed760ff87d5fc456f31e407ead548bbb754497d.1728058550.git.daniel@makrotopia.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

dt-bindings: net: marvell,aquantia: add property to override MDI_CFG

Usually the MDI pair order reversal configuration is defined by
bootstrap pin MDI_CFG. Some designs, however, require overriding the MDI
pair order and force either normal or reverse order.

Add property 'marvell,mdi-cfg-order' to allow forcing either normal or
reverse order of the MDI pairs.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/7ccf25d6d7859f1ce9983c81a2051cfdfb0e0a99.1728058550.git.daniel@makrotopia.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Merge branch 'selftests-mlxsw-stabilize-red-tests'

Petr Machata says:

====================
selftests: mlxsw: Stabilize RED tests

Tweak the mlxsw-specific RED selftests to increase stability on
Spectrum-3 and Spectrum-4 machines.
====================

Link: https://patch.msgid.link/cover.1728316370.git.petrm@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

selftests: mlxsw: sch_red_core: Lower TBF rate

The RED test uses a pair of TBF shapers. The first to get predictably-sized
stream of traffic, and second to get a 100% saturated chokepoint. To this
chokepoint it injects individual packets. Because the chokepoint is
saturated, these additional packets go straight to the backlog. This allows
the test to check RED behavior across various queue sizes.

The shapers are rated at 1Gbps, for historical reasons (before mlxsw
supported TBF offload, the test used port speed to create the chokepoints).
Machines with a low-power CPU may have trouble consistently generating
1Gbps of traffic, and the test then spuriously fails.

Instead, drop the rate to 200Mbps (Spectrum has a guaranteed shaper rate
granularity of 200Mbps, so anything lower is not guaranteed to work well).
Because that means fewer packets will be mirrored in the ECN-mark test,
adjust the passing condition accordingly.

Signed-off-by: Petr Machata <petrm@nvidia.com>
Link: https://patch.msgid.link/c6712f9c5de75ae0bc2ab3d8ea7d92aaaf93af95.1728316370.git.petrm@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

selftests: mlxsw: sch_red_core: Send more packets for drop tests

This test works by injecting into a port with a maxed-out queue a couple
packets and checks if a corresponding number of packets were dropped. This
has worked well on Spectrum<4, but on Spectrum-4 it has been noisy. This
is in line with the observation that on Spectrum-4, queue size tends to
fluctuate more. A handful of packets could then still be accepted to the
queue even though it was nominally full just recently.

In order to accommodate this behavior, send many more packets. The buffer
can fit N extra packets, but not N% packets. This therefore allows us to
set wider absolute margins, while actually narrowing them relatively.

Signed-off-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/abc869b9f6003d400d6293ddd5edb2f4517f44d5.1728316370.git.petrm@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

selftests: mlxsw: sch_red_core: Sleep before querying queue depth

The qdisc stats are taken from the port's periodic HW stats, which are
updated once a second. We try to accommodate the latency by using busywait
in build_backlog().

The issue in that seems to be that when do_mark_test() builds the backlog,
it makes the decision whether to send more packets based on the first
instance of the queue depth stat exceeding the current value, when in fact
more traffic is on the way and the queue depth would increase further. This
leads to failures in TC 1 of mark-mirror test, where we see the following
failure:

TEST: TC 0: marked packets mirror'd                                 [ OK ]
TEST: TC 1: marked packets mirror'd                                 [FAIL]
        Spurious packets (1680 -> 2290) observed without buffer pressure

Fix by waiting for the full second before reading the queue depth for the
first time, to make sure it reflects all in-flight traffic.

Signed-off-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Amit Cohen <amcohen@nvidia.com>
Link: https://patch.msgid.link/321dcf8b3e9a1f0766429c8cf3e3f1746f1bc375.1728316370.git.petrm@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

selftests: mlxsw: sch_red_core: Increase backlog size tolerance

Backlog fluctuates on Spectrum-4 much more than on <4. In practice we can
sample queue depth values going from about -12% to about +7% of the
configured RED limit. The test which checks the queue size has a limit of
+-10%, and as a result often fails. We attempted to fix the issue by
busywaiting for several seconds hoping to get within the bounds, but that
still proved to be too noisy (or the wait time would be impractically
long). Unfortunately we have to bump the value tolerance from 10% to 15%,
which in this patch do.

Signed-off-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Amit Cohen <amcohen@nvidia.com>
Link: https://patch.msgid.link/f54950df2a8fcba46c3ddc1053376352fa2e592b.1728316370.git.petrm@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

selftests: mlxsw: sch_red_ets: Increase required backlog

Backlog fluctuates on Spectrum-4 much more than on <4. Increasing the
desired backlog seems to help, as the constant fluctuations do not overlap
into the territory where packets are marked.

Signed-off-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Amit Cohen <amcohen@nvidia.com>
Link: https://patch.msgid.link/0821fb3aa8bb6a6c0d3000baab04995517c9a0cc.1728316370.git.petrm@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

net: phy: smsc: use devm_clk_get_optional_enabled_with_rate()

Fold the separate call to clk_set_rate() into the clock getter.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20241007134100.107921-1-brgl@bgdev.pl
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

chelsio/chtls: Remove unused chtls_set_tcb_tflag

chtls_set_tcb_tflag() has been unused since 2021's commit
827d329105bf ("chtls: Remove invalid set_tcb call")

Remove it.

Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20241007004652.150065-1-linux@treblig.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

caif: Remove unused cfsrvl_getphyid

cfsrvl_getphyid() has been unused since 2011's commit
f36214408470 ("caif: Use RCU and lists in cfcnfg.c for managing caif link layers")

Remove it.

Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20241007004456.149899-1-linux@treblig.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>