wifi: rtw89: mcc: drop queued chanctx changes when stopping

When MCC is about to stop, there may be some chanctx changes which are
queued for work but have not yet been run. To avoid these changes from
being processed in a wrong state (e.g. next new MCC instance), cancel
the queued work and drop queued changes.

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

wifi: rtw89: mcc: pass whom to stop at when pausing chanctx

When stopping MCC, FW can stop at a given MCC role following H2C command.
When pausing chanctx during MCC, in general, the caller expects to process
things with its chanctx. So, pass the caller as target and let FW stop MCC
at it.

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

wifi: rtw88: Fix the random "error beacon valid" messages for USB

All the USB devices have a problem in AP mode: uploading the updated
beacon to the chip's reserved page can randomly fail:

[34996.474304] rtw88_8723du 1-2:1.2: error beacon valid
[34996.474788] rtw88_8723du 1-2:1.2: failed to download drv rsvd page
[34999.956369] rtw88_8723du 1-2:1.2: error beacon valid
[34999.956846] rtw88_8723du 1-2:1.2: failed to download drv rsvd page
[34999.956855] rtw88_8723du 1-2:1.2: failed to download beacon
[35017.978296] rtw88_8723du 1-2:1.2: error beacon valid
[35017.978805] rtw88_8723du 1-2:1.2: failed to download drv rsvd page
[35017.978823] rtw88_8723du 1-2:1.2: failed to download beacon
[35023.200395] rtw88_8723du 1-2:1.2: error beacon valid
[35023.200869] rtw88_8723du 1-2:1.2: failed to download drv rsvd page
[35023.200875] rtw88_8723du 1-2:1.2: failed to download beacon
[35478.680547] rtw88_8723du 1-2:1.2: error beacon valid
[35478.681023] rtw88_8723du 1-2:1.2: failed to download drv rsvd page

Disable some beacon-related hardware functions before uploading the
beacon and enable them again after.

Tested with RTL8723DU, RTL8812BU, RTL8822CE.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/c248c40a-d432-47ed-90e0-d81ee6c32464@gmail.com

wifi: rtw88: usb: Upload the firmware in bigger chunks

RTL8811AU stops responding during the firmware download on some systems:

[  809.256440] rtw_8821au 5-2.1:1.0: Firmware version 42.4.0, H2C version 0
[  812.759142] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: renamed from wlan0
[  837.315388] rtw_8821au 1-4:1.0: write register 0x1ef4 failed with -110
[  867.524259] rtw_8821au 1-4:1.0: write register 0x1ef8 failed with -110
[  868.930976] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: entered promiscuous mode
[  897.730952] rtw_8821au 1-4:1.0: write register 0x1efc failed with -110

Maybe it takes too long when writing the firmware 4 bytes at a time.

Write 196 bytes at a time for RTL8821AU, RTL8811AU, and RTL8812AU,
and 254 bytes at a time for RTL8723DU. These are the sizes used in
their official drivers. Tested with all these chips.

Cc: stable@vger.kernel.org
Link: https://github.com/lwfinger/rtw88/issues/344
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/43f1daad-3ec0-4a3b-a50c-9cd9eb2c2f52@gmail.com

wifi: rtw88: usb: Reduce control message timeout to 500 ms

RTL8811AU stops responding during the firmware download on some systems:

[  809.256440] rtw_8821au 5-2.1:1.0: Firmware version 42.4.0, H2C version 0
[  812.759142] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: renamed from wlan0
[  837.315388] rtw_8821au 1-4:1.0: write register 0x1ef4 failed with -110
[  867.524259] rtw_8821au 1-4:1.0: write register 0x1ef8 failed with -110
[  868.930976] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: entered promiscuous mode
[  897.730952] rtw_8821au 1-4:1.0: write register 0x1efc failed with -110

Each write takes 30 seconds to fail because that's the timeout currently
used for control messages in rtw_usb_write().

In this scenario the firmware download takes at least 2000 seconds.
Because this is done from the USB probe function, the long delay makes
other things in the system hang.

Reduce the timeout to 500 ms. This is the value used by the official USB
wifi drivers from Realtek.

Of course this only makes things hang for ~30 seconds instead of ~30
minutes. It doesn't fix the firmware download.

Tested with RTL8822CU, RTL8812BU, RTL8811CU, RTL8814AU, RTL8811AU,
RTL8812AU, RTL8821AU, RTL8723DU.

Cc: stable@vger.kernel.org
Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support")
Link: https://github.com/lwfinger/rtw88/issues/344
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/1e35dd26-3f10-40b1-b2b4-f72184a26611@gmail.com

wifi: rtw89: pci: enlarge retry times of RX tag to 1000

RX tag is sequence number to ensure RX DMA is complete. On platform
Gigabyte X870 AORUS ELITE WIFI7, sometimes it needs longer retry times
to complete RX DMA, or driver throws warnings and connection drops:

  rtw89_8922ae 0000:07:00.0: failed to update 162 RXBD info: -11
  rtw89_8922ae 0000:07:00.0: failed to update 163 RXBD info: -11
  rtw89_8922ae 0000:07:00.0: failed to update 32 RXBD info: -11
  rtw89_8922ae 0000:07:00.0: failed to release TX skbs

Fixes: 0bc7d1d4e63c ("wifi: rtw89: pci: validate RX tag for RXQ and RPQ")
Reported-by: Samuel Reyes <zohrlaffz@gmail.com>
Closes: https://lore.kernel.org/linux-wireless/f4355539f3ac46bbaf9c586d059a8cbb@realtek.com/T/#t
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250509013433.7573-1-pkshih@realtek.com

wifi: rtw89: leave idle mode when setting WEP encryption for AP mode

Due to mac80211 triggering the hardware to enter idle mode, it fails
to install WEP key causing connected station can't ping successfully.
Currently, it forces the hardware to leave idle mode before driver
adding WEP keys.

Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250507031203.8256-1-pkshih@realtek.com

wifi: rtw89: pci: configure manual DAC mode via PCI config API only

To support 36-bit DMA, configure chip proprietary bit via PCI config API
or chip DBI interface. However, the PCI device mmap isn't set yet and
the DBI is also inaccessible via mmap, so only if the bit can be accessible
via PCI config API, chip can support 36-bit DMA. Otherwise, fallback to
32-bit DMA.

With NULL mmap address, kernel throws trace:

  BUG: unable to handle page fault for address: 0000000000001090
  #PF: supervisor write access in kernel mode
  #PF: error_code(0x0002) - not-present page
  PGD 0 P4D 0
  Oops: Oops: 0002 [#1] PREEMPT SMP PTI
  CPU: 1 UID: 0 PID: 71 Comm: irq/26-pciehp Tainted: G           OE      6.14.2-061402-generic #202504101348
  Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
  RIP: 0010:rtw89_pci_ops_write16+0x12/0x30 [rtw89_pci]
  RSP: 0018:ffffb0ffc0acf9d8 EFLAGS: 00010206
  RAX: ffffffffc158f9c0 RBX: ffff94865e702020 RCX: 0000000000000000
  RDX: 0000000000000718 RSI: 0000000000001090 RDI: ffff94865e702020
  RBP: ffffb0ffc0acf9d8 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000015
  R13: 0000000000000719 R14: ffffb0ffc0acfa1f R15: ffffffffc1813060
  FS:  0000000000000000(0000) GS:ffff9486f3480000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000001090 CR3: 0000000090440001 CR4: 00000000000626f0
  Call Trace:
   <TASK>
   rtw89_pci_read_config_byte+0x6d/0x120 [rtw89_pci]
   rtw89_pci_cfg_dac+0x5b/0xb0 [rtw89_pci]
   rtw89_pci_probe+0xa96/0xbd0 [rtw89_pci]
   ? __pfx___device_attach_driver+0x10/0x10
   ? __pfx___device_attach_driver+0x10/0x10
   local_pci_probe+0x47/0xa0
   pci_call_probe+0x5d/0x190
   pci_device_probe+0xa7/0x160
   really_probe+0xf9/0x370
   ? pm_runtime_barrier+0x55/0xa0
   __driver_probe_device+0x8c/0x140
   driver_probe_device+0x24/0xd0
   __device_attach_driver+0xcd/0x170
   bus_for_each_drv+0x99/0x100
   __device_attach+0xb4/0x1d0
   device_attach+0x10/0x20
   pci_bus_add_device+0x59/0x90
   pci_bus_add_devices+0x31/0x80
   pciehp_configure_device+0xaa/0x170
   pciehp_enable_slot+0xd6/0x240
   pciehp_handle_presence_or_link_change+0xf1/0x180
   pciehp_ist+0x162/0x1c0
   irq_thread_fn+0x24/0x70
   irq_thread+0xef/0x1c0
   ? __pfx_irq_thread_fn+0x10/0x10
   ? __pfx_irq_thread_dtor+0x10/0x10
   ? __pfx_irq_thread+0x10/0x10
   kthread+0xfc/0x230
   ? __pfx_kthread+0x10/0x10
   ret_from_fork+0x47/0x70
   ? __pfx_kthread+0x10/0x10
   ret_from_fork_asm+0x1a/0x30
   </TASK>

Fixes: 1fd4b3fe52ef ("wifi: rtw89: pci: support 36-bit PCI DMA address")
Reported-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Closes: https://lore.kernel.org/linux-wireless/ccaf49b6-ff41-4917-90f1-f53cadaaa0da@gmail.com/T/#u
Closes: https://github.com/openwrt/openwrt/issues/17025
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250506015356.7995-1-pkshih@realtek.com

wifi: rtw89: declare MLO support if prerequisites are met

When the following prerequisites are met, driver will enable support_mlo.
It means that driver will declare WIPHY_FLAG_SUPPORTS_MLO, and then deal
with MLO related things.

The main prerequisites are as below.
1. all prerequisites for running with chanctx
2. FW feature NOTIFY_AP_INFO

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

wifi: rtw89: debug: add mlo_mode dbgfs

Add an dbgfs mlo_mode to get/set MLO mode. And, support to trigger MLSR
switching. Setting it will automatically disable MLO Dynamic Mechanism
(DM). Then MLO things can follow commands via dbgfs mlo_mode instead of
MLO DM. The disabled DM(s) can be checked/cleared via dbgfs disable_dm.

The following is an use example.

Read it to show current MLD status.
$ cat mlo_mode

MLD(s) status: (MLO DM: enable)
#0: MLO mode 0, valid 0x6, active 0x2

Write it to switch to MLSR on link id 2.
$ echo 0 2 > mlo_mode
$ cat mlo_mode

MLD(s) status: (MLO DM: disable)
#0: MLO mode 0, valid 0x6, active 0x4

Besides, to be safer, add RWLOCK attribute to dbgfs disable_dm.

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

wifi: rtw89: debug: add FW log component for MLO

This allows showing MLO related logs when FW debug mode is on.

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

wifi: rtw89: debug: add MLD table dump

Add definition for MLD table dump, this is for debug purpose only.

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

wifi: rtw89: debug: extend dbgfs for MLO

Extend dbgfs vif/sta info to show current designated link.

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

wifi: rtw89: add MLO track for MLSR switch decision

Add MLSR switch mechanism based on tracking RSSI. Switch to a 2 GHz link
(if any) when average RSSI is lower than threshold -53. And, switch out
from a 2 GHz link when average RSSI is larger than threshold -38.

The sequence of MLSR switch handling is like the following.
1. initialize target link and configure to PS mode
2. configure current designated link to PS mode
3. configure target link to non-PS mode
4. deinitialize currently active links except target link

The above flow also implies that target link becomes new designated link.

Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250505072440.45113-7-pkshih@realtek.com

wifi: rtw89: add handling of mlo_link_cfg H2C command and C2H event

The mlo_link_cfg H2C command is used to tell FW to enter/leave PS mode
on a given link. And, need to wait for status of C2H event to ensure if
FW deals with it successfully.

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

wifi: rtw89: chan: re-calculate MLO DBCC mode during setting channel

Wi-Fi 7 chips have dual HW bands. After impending MLO support, they
can work with HW-[0] / HW-[1] / HW-[0,1] according to active links.
So, during setting channel, also re-calculate the MLO DBCC mode flag.
Then, leaf chip functions of setting channel can configure with HWs
based on current case.

Besides, tweak the initial and idle MLO DBCC mode of Wi-Fi 7 chips to
MLO_1_PLUS_1_1RF to work with dual HW bands. And, after disconnecting,
due to no active links, MLO DBCC mode will re-calculate to idle case,
i.e. MLO_1_PLUS_1_1RF.

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

wifi: rtw89: send nullfunc based on the given link

The nullfunc sender function is link specific. Use core_tx_write_link
with sw_mld flag to TX the nullfunc via the given link.

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

wifi: rtw89: allow driver to do specific band TX for MLO

For data packets that can be sent on any band, fill in main mac_id
and let HW decide. For packets that we wish to transmit on specific
band, fill in sw_mld field so HW would only send it on that band.
Main mac_id is the corresponding mac_id on band 0.

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

wifi: rtw89: extract link part from core tx write function

Extract core_tx_write_link from core_tx_write to accept given links as
parameters. To make the follow-up changes of TX description more clear,
tweak SW functions to split things ahead.

(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>
Link: https://patch.msgid.link/20250505072440.45113-2-pkshih@realtek.com

wifi: rtw88: rtw8822bu VID/PID for BUFFALO WI-U2-866DM

Add VID/PID 0411/03d1 for recently released
BUFFALO WI-U2-866DM USB WiFi adapter.

Signed-off-by: Yuuki NAGAO <wf.yn386@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250503003227.6673-1-wf.yn386@gmail.com

wifi: rtw88: Handle RTL8723D(S) with blank efuse

Some users have RTL8723DS chips with nearly blank efuse. Currently these
chips cannot connect when using rtw88, but they do work using the old
out-of-tree driver.

Use reasonable default values for TX power, antenna configuration, and
crystal cap if the chip's efuse is missing these things.

RTL8723D can use the same default values as RTL8703B, so simply move
the code from rtl8703b_read_efuse() to the shared function
__rtl8723x_read_efuse().

Link: https://github.com/lwfinger/rtw88/issues/157
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/5734afe7-0870-40b2-acd4-5657a02d7c56@gmail.com

wifi: rtw88: Fix RX aggregation settings for RTL8723DS

Use the same RX aggregation size and timeout used by the out-of-tree
RTL8723DS driver. Also set mystery bit 31 of REG_RXDMA_AGG_PG_TH. This
improves the RX speed from ~44 Mbps to ~67 Mbps.

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/4c79fdc1-54bc-4986-9931-bb3ceb418b97@gmail.com

wifi: rtw89: constrain TX power according to dynamic antenna power table

Dynamic Antenna Gain (DAG) adjusts TX power based on antenna gain. To
prevent signal distortion from excessive power increases, a dynamic
antenna power table limits the maximum adjustable TX power.

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

wifi: rtw89: phy: add C2H event handler for report of FW scan

Newer firmware will notify driver of the Packet Detection (PD)
value on the channel after switch channels during FW scan.

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

wifi: rtw89: Fix inadverent sharing of struct ieee80211_supported_band data

Internally wiphy writes to individual channels in this structure,
so we must not share one static definition of channel list between
multiple device instances, because that causes hard to debug
breakage.

For example, with two rtw89 driven devices in the system, channel
information may get incoherent, preventing channel use.

Signed-off-by: Ondrej Jirman <megi@xff.cz>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250429122916.1734879-3-megi@xff.cz

wifi: rtw89: Convert rtw89_core_set_supported_band to use devm_*

The code can be simplified by using device managed memory
allocations. Simplify it.

Signed-off-by: Ondrej Jirman <megi@xff.cz>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250429122916.1734879-2-megi@xff.cz

wifi: rtw89: introduce helper to get designated link for MLO

A link bound to HW band 0 was previously always assumed to exist, because
it's true on non-MLD connection, and MLO connection is not supported yet.
Now, start to consider MLO cases and prepare to enable MLO support in the
following. Add skeleton of designated link. For single-link cases, helper
returns the one. For multi-link cases, priorities can be scheduled. Then,
drop assumption of link bound to HW band 0.

One exception is that MCC doesn't work with MLD yet, so it still expects
link on HW band 0 somewhere.

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

wifi: rtw89: roc: dynamically handle link id and link instance index

Originally, a macro, RTW89_ROC_BY_LINK_INDEX, is used to decide the link
which deals with the ROC process. Before enabling MLO support, it's fine
to hard-code RTW89_ROC_BY_LINK_INDEX as 0 since the link instance-0 (on
HW-0) is always active. But, for the impending enablement of MLO support,
tweak the leaf functions to dynamically handle ROC link instance index.

Besides, in the follow-up, ROC caller will get a designated link and will
then drop RTW89_ROC_BY_LINK_INDEX.

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

wifi: rtw89: Fill in correct Rx link ID for MLO

For MLO connections, RX link ID is required to do address conversion.
Fill it in by the hardware info.

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

wifi: rtw89: add MLD capabilities declaration

Add MLD capabilities so association requests can carry multi-link
element with correct content.

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

wifi: rtw89: extend join_info H2C command for MLO fields

The join_info H2C command is used to indicate a station is connected and
tell FW to create/maintain an instance for it. Extend to fill MLO fields.

Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-7-pkshih@realtek.com

wifi: rtw89: Configure scan band when mlo_dbcc_mode changes

Previously only the first band is used for scanning. With MLO, update
scan parameters accordingly by so we can choose to scan from either band.
C2H event return value reflects current scanning band, mask it out so
we don't treat correct return value as fail.

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

wifi: rtw89: extend mapping from Qsel to DMA ch for MLO

After impending MLO support, TX Qsel would come from other HW band rather
than HW-0. For example, when working on HW-1, TX release report may fill
QSEL_XX_1 and cause warning "Cannot map qsel to dma: ...". So, extend the
mapping to recognize multiple HW bands.

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

wifi: rtw89: Adjust management queue mapping for [MLO, HW-1]

Adjust mapping of management packets accordingly to send it on the
second hardware band. Previously only single band is used and we
plan to enable MLO, so the second band will be needed. Data packets
will be steered by hardware so no related changes are required.

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

wifi: rtw89: 8922a: use SW CRYPTO when broadcast in MLO mode

8922A doesn't support broadcast/multicast traffic under MLO mode.
So let mac80211 do the encryption/decryption for us when the
connection is in MLO mode. Future BE ICs fixes this issue.

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

wifi: rtw89: 8922a: rfk: adjust timeout time of RX DCK

The RX DCK in firmware could retry 3 times if calibration value is not
stable. Roughly each calibration can be done within 16 ms, so expect
16 * 4 (with additional 16 ms) will be enough. More, in coming MLO, it
will do calibration on two path, so multiply 2.

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

wifi: rtw89: fw: Remove "const" on allocation type

In preparation for making the kmalloc family of allocators type aware,
we need to make sure that the returned type from the allocation matches
the type of the variable being assigned. (Before, the allocator would
always return "void *", which can be implicitly cast to any pointer type.)

The assigned type is "struct rtw89_reg2_def *" but the returned type,
while technically matching, will be const qualified. As there isn't a
general way to discard "const" qualifiers, adjust the returned type to
match the assigned type. No change in allocation size results.

Signed-off-by: Kees Cook <kees@kernel.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250426060935.work.049-kees@kernel.org

wifi: rtlwifi: Remove unused rtl_bb_delay()

The last use of rtl_bb_delay() was removed in 2014's
commit 5c99f04fec93 ("rtlwifi: rtl8723be: Update driver to match Realtek
release of 06/28/14")

Remove it.

Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250425235340.288340-4-linux@treblig.org

wifi: rtlwifi: Remove uncalled stub rtl*_phy_ap_calibrate

  rtl92d_phy_ap_calibrate(),
  rtl92du_phy_ap_calibrate(),
  rtl92ee_phy_ap_calibrate(), and
  rtl8821ae_phy_ap_calibrate()

are all empty function stubs that are never called anywhere.

Remove them.

Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250425235340.288340-3-linux@treblig.org

wifi: rtlwifi: Remove unused rtl_usb_{resume|suspend}

rtl_usb_resume() and rtl_usb_suspend() are trivial stubs that were
added in 2011's
commit 2ca20f79e0d8 ("rtlwifi: Add usb driver")
but aren't wired up anywhere (though commit 442888c706e9 ("rtlwifi:
rtl8192cu: Add routines dm, fw, led and sw")  added commented
out assignments).

Remove them.

Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250425235340.288340-2-linux@treblig.org

wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723

RTL8723BE found on some ASUSTek laptops, such as F441U and X555UQ with
subsystem ID 11ad:1723 are known to output large amounts of PCIe AER
errors during and after boot up, causing heavy lags and at times lock-ups:

  pcieport 0000:00:1c.5: AER: Correctable error message received from 0000:00:1c.5
  pcieport 0000:00:1c.5: PCIe Bus Error: severity=Correctable, type=Physical Layer, (Receiver ID)
  pcieport 0000:00:1c.5:   device [8086:9d15] error status/mask=00000001/00002000
  pcieport 0000:00:1c.5:    [ 0] RxErr

Disable ASPM on this combo as a quirk.

This patch is a revision of a previous patch (linked below) which
attempted to disable ASPM for RTL8723BE on all Intel Skylake and Kaby Lake
PCIe bridges. I take a more conservative approach as all known reports
point to ASUSTek laptops of these two generations with this particular
wireless card.

Please note, however, before the rtl8723be finishes probing, the AER
errors remained. After the module finishes probing, all AER errors would
indeed be eliminated, along with heavy lags, poor network throughput,
and/or occasional lock-ups.

Cc: <stable@vger.kernel.org>
Fixes: a619d1abe20c ("rtlwifi: rtl8723be: Add new driver")
Reported-by: Liangliang Zou <rawdiamondmc@outlook.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218127
Link: https://lore.kernel.org/lkml/05390e0b-27fd-4190-971e-e70a498c8221@lwfinger.net/T/
Tested-by: Liangliang Zou <rawdiamondmc@outlook.com>
Signed-off-by: Mingcong Bai <jeffbai@aosc.io>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250422061755.356535-1-jeffbai@aosc.io

wifi: rtw89: mcc: avoid that loose pattern sets negative timing for auxiliary GO

A MCC (multi-channel concurrency) schedule is like the following.

   |<                mcc interval                 >|
   |<    duration ref     >|<    duration aux     >|
   |< tob ref >|< toa ref >|< tob aux >|< toa aux >|
               V                       V
           tbtt ref                tbtt aux
               |<    beacon offset    >|

Original logic might unexpectedly calculate toa (time offset ahead) of
auxiliary role to be negative even when there is no role timing limit.
If toa-aux is negative, TBTT-aux would in logic fall into duration-ref.
Then, if auxiliary role is GO unfortunately, it cannot guarantee that
beacons will TX well. So now, when deciding the lower bound of toa-ref,
take toa-aux into account. Make toa-aux at least be zero in normal cases.

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

wifi: rtw89: mcc: refine filling function of start TSF

Since tob (time offset behind) could be negative, change the type of tob in
microsecond to s32. And, refine accumulation with while-loop by calculation
with roundup_u64(). Besides, as long as one of the MCC roles is GO, use the
short MCC start time.

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

wifi: rtw89: mcc: support courtesy mechanism on both roles at the same time

MCC has a courtesy mechanism which allows one role to use another's
duration in a given cycle. Originally, this courtesy mechanism only
supports in one direction. However, in some field cases, both of MCC
roles may simultaneously have timing configurations that are not good
enough. So, support courtesy mechanism in both directions.

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

wifi: rtw89: mcc: update entire plan when courtesy config changes

MCC has a courtesy mechanism which allows one role to use another's
duration in a given cycle. Courtesy mechanism will be enabled when
one role has a not perfect duration. Otherwise, not. When MCC updates,
duration of each role will be re-calculated. And then, the new courtesy
config might be different from the old one. However, to change courtesy
config, the entire MCC plan requires to be renewed when MCC updates.

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

wifi: rtw89: mcc: handle the case where NoA start time has passed

MCC will limit the time a role can use in a schedule according to the
periodic NoA. Original logic didn't consider the case where NoA start
time has passed. It might lead to inaccurate result. So, tweak it.

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

wifi: rtw89: mcc: make GO+STA mode calculate dynamic beacon offset

There are two roles during MCC and the offset between their TBTT is called
beacon offset. Originally, when MCC runs GO+STA mode, it used fixed beacon
offset to simplify some logic because GO role can master its TSF. However,
if MCC is stopped and restarted before a same GO is down, its TSF might be
discontinuous. Then, there might be undefined behavior happens in GC sides.
So, to let a same GO have a continuous TSF, MCC no longer changes its TSF
to meet a fixed beacon offset. Instead, GO+STA mode also calculates beacon
offset dynamically as what GC+STA mode did.

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

wifi: rtw89: don't re-randomize TSF of AP/GO

When APs or GOs are up, their TSF start point are randomized to avoid
collisions. However, the TSF of an existing AP/GO would be randomized
multiple times. It caused the TSF is discontinuous to the corresponding
STA/GC sides. So, once TSF has been randomized, don't re-randomize it
unless SER (system error recovery) happens unfortunately.

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

wifi: rtw89: mcc: make GO announce one-time NoA for HW scan process

Since FW cannot handle HW scan process and MCC (multi-channel concurrency)
mode simultaneously, if a HW scan is requested during MCC, MCC mode will be
paused temporarily. Then, the GO role if any might be absent. So, calculate
an estimated time for the requested HW scan process and search for existing
GO roles to fill one-time NoA.

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

wifi: rtw89: refactor flow that hw scan handles channel list

FW has a limited amount of channels that can be dealt with by one HW scan
H2C command. Based on the limit, channels in scan request might be parsed
into SW structure piece by piece along with multiple HW scan H2C commands.
But, in order to estimate things of entire HW scan process, it's required
to have the whole parsed channel list when HW scan is going to start. So,
tweak HW scan flow to prepare the whole channel list ahead. Still, each HW
scan H2C command takes allowed amount of channels from the list according
to the limit.

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

wifi: rtw89: add suffix "_ax" to Wi-Fi 6 HW scan struct and func

These stuffs have no suffix, but not universal, and only work for Wi-Fi 6.
Since the corresponding HW scan struct/func of Wi-Fi 7 have suffix "_be",
to avoid misunderstanding and improve readability, also add suffix "_ax"
to these Wi-Fi 6 stuffs.

(No logic is changed.)

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

wifi: rtw89: acpi: introduce country specific TAS enabling

A new ACPI table entry format for TAS is defined, which includes
a "specific country" field. In this field, determine which
country can enable TAS.

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

wifi: rtw89: 8922a: increase beacon loss to 6 seconds

Intermittent beacon loss from specific AP triggers disconnection
and reconnection. Increasing the beacon loss count will make the
connection more stable.

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

wifi: rtw89: set pre-calculated antenna matrices for HE trigger frame

Pre-calculated antenna matrices can improve 160MHz uplink OFDMA
performance, but they are only needed for the HE trigger frame.

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

wifi: rtw89: regd: indicate if regd_UK TX power settings follow regd_ETSI

Before adopting regd_UK TX power settings, some certifications are needed
and might be platform-level. Without that, should adopt regd_ETSI TX power
settings. But for now, there is no way to inform driver of it yet. So, add
a flag first. But for now, comprehensively use regd_ETSI TX power settings
to restrict regd_UK.

Plan to define an ACPI DSM function to inform driver whether to use regd_UK
own TX power settings or not afterwards.

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

wifi: rtw89: 8922a: fix TX fail with wrong VCO setting

An incorrect Voltage Controlled Oscillator (VCO) setting
may cause Synthesizer (SYN) unlock, which may lead to a
failure in the TX authentication request.

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

wifi: rtw89: 8852c: update supported firmware format to 2

After firmware 0.27.125.0, it adds more fields to support firmware secure
boot. Though current driver has supported the format, old driver can't
recognize the new format, increase firmware format to 2 to avoid failed
to load the firmware by old driver.

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

wifi: rtw88: do not ignore hardware read error during DPK

In 'rtw8822c_dpk_cal_coef1()', do not ignore error returned
by 'check_hw_ready()' but issue a warning to denote possible
DPK issue. Compile tested only.

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

Fixes: 5227c2ee453d ("rtw88: 8822c: add SW DPK support")
Suggested-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250415090720.194048-1-dmantipov@yandex.ru

wifi: rtw88: sdio: call rtw_sdio_indicate_tx_status unconditionally

The rtw88-sdio do not work in AP mode due to the lack of TX status report
for management frames.

Make the invocation of rtw_sdio_indicate_tx_status unconditional and cover
all packet queues

Tested-on: rtl8723ds

Fixes: 65371a3f14e7 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets")
Signed-off-by: Zhen XIN <zhen.xin@nokia-sbell.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250410154217.1849977-2-zhen.xin@nokia-sbell.com

wifi: rtw88: sdio: map mgmt frames to queue TX_DESC_QSEL_MGMT

The rtw88-sdio do not work in AP mode due to the lack of TX status report
for management frames.

Map the management frames to queue TX_DESC_QSEL_MGMT, which enables the
chip to generate TX reports for these frames

Tested-on: rtl8723ds

Fixes: 65371a3f14e7 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets")
Signed-off-by: Zhen XIN <zhen.xin@nokia-sbell.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250410154217.1849977-3-zhen.xin@nokia-sbell.com

wifi: rtw88: Fix the module names printed in dmesg

The rtw88 module names all start with the "rtw88_" prefix, but the
messages in dmesg mostly use the "rtw_" prefix. The messages from
rtw88_8723cs don't even have the underscore.

Use the KBUILD_MODNAME macro in every driver. This ensures that the
messages in dmesg will always use the module name.

Before:

Mar 17 15:54:19 ideapad2 kernel: rtw_8814au 2-4:1.0: Firmware version 33.6.0, H2C version 6

After:

Mar 17 16:33:35 ideapad2 kernel: rtw88_8814au 2-4:1.0: Firmware version 33.6.0, H2C version 6

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/29cd29ba-bc51-4d5b-ad48-a43c6ce72d56@gmail.com

wifi: rtw88: Don't set SUPPORTS_AMSDU_IN_AMPDU for RTL8814AU

RTL8814AU doesn't work well with SUPPORTS_AMSDU_IN_AMPDU. The RX speed
is noticeably lower and the VHT RX statistics are strange. Typical
values with SUPPORTS_AMSDU_IN_AMPDU:

Reverse mode, remote host 192.168.0.1 is sending
[  5] local 192.168.0.50 port 60710 connected to 192.168.0.1 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  74.6 MBytes   626 Mbits/sec
[  5]   1.00-2.00   sec  79.2 MBytes   665 Mbits/sec
[  5]   2.00-3.00   sec  84.9 MBytes   712 Mbits/sec
[  5]   3.00-4.00   sec  83.8 MBytes   703 Mbits/sec
[  5]   4.00-5.00   sec  85.9 MBytes   720 Mbits/sec
[  5]   5.00-6.00   sec  78.9 MBytes   662 Mbits/sec
[  5]   6.00-7.00   sec  81.2 MBytes   682 Mbits/sec
[  5]   7.00-8.00   sec  80.5 MBytes   675 Mbits/sec
[  5]   8.00-9.00   sec  79.4 MBytes   666 Mbits/sec
[  5]   9.00-10.00  sec  82.2 MBytes   689 Mbits/sec
[  5]  10.00-11.00  sec  82.0 MBytes   688 Mbits/sec
[  5]  11.00-12.00  sec  84.2 MBytes   707 Mbits/sec
[  5]  12.00-13.00  sec  71.0 MBytes   596 Mbits/sec
[  5]  13.00-14.00  sec  69.4 MBytes   582 Mbits/sec
[  5]  14.00-15.00  sec  80.2 MBytes   673 Mbits/sec
[  5]  15.00-16.00  sec  74.5 MBytes   625 Mbits/sec

[Rx Counter]:
 * CCA (CCK, OFDM, Total) = (0, 2455, 2455)
 * False Alarm (CCK, OFDM, Total) = (0, 69, 69)
 * CCK cnt (ok, err) = (0, 0)
 * OFDM cnt (ok, err) = (1239, 2)
 * HT cnt (ok, err) = (0, 0)
 * VHT cnt (ok, err) = (21, 12109)

The "VHT ok" number is not believable.

And without SUPPORTS_AMSDU_IN_AMPDU:

Reverse mode, remote host 192.168.0.1 is sending
[  5] local 192.168.0.50 port 50030 connected to 192.168.0.1 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  70.5 MBytes   591 Mbits/sec
[  5]   1.00-2.00   sec  86.9 MBytes   729 Mbits/sec
[  5]   2.00-3.00   sec  98.6 MBytes   827 Mbits/sec
[  5]   3.00-4.00   sec  97.4 MBytes   817 Mbits/sec
[  5]   4.00-5.00   sec  98.6 MBytes   827 Mbits/sec
[  5]   5.00-6.00   sec  96.9 MBytes   813 Mbits/sec
[  5]   6.00-7.00   sec  98.2 MBytes   824 Mbits/sec
[  5]   7.00-8.00   sec  98.0 MBytes   822 Mbits/sec
[  5]   8.00-9.00   sec  99.9 MBytes   838 Mbits/sec
[  5]   9.00-10.00  sec  99.2 MBytes   833 Mbits/sec
[  5]  10.00-11.00  sec  98.0 MBytes   822 Mbits/sec
[  5]  11.00-12.00  sec  98.1 MBytes   823 Mbits/sec
[  5]  12.00-13.00  sec  97.0 MBytes   814 Mbits/sec
[  5]  13.00-14.00  sec  98.2 MBytes   824 Mbits/sec
[  5]  14.00-15.00  sec  98.5 MBytes   826 Mbits/sec
[  5]  15.00-16.00  sec  97.4 MBytes   817 Mbits/sec

[Rx Counter]:
 * CCA (CCK, OFDM, Total) = (0, 3860, 3860)
 * False Alarm (CCK, OFDM, Total) = (0, 2, 2)
 * CCK cnt (ok, err) = (0, 0)
 * OFDM cnt (ok, err) = (1486, 0)
 * HT cnt (ok, err) = (0, 0)
 * VHT cnt (ok, err) = (7399, 9118)

Add a new member "amsdu_in_ampdu" in struct rtw_chip_info and use it
to set SUPPORTS_AMSDU_IN_AMPDU only for the other chips.

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/6202ccfb-feb0-4107-a08d-db2699e179f0@gmail.com

wifi: rtw88: Set AMPDU factor to hardware for RTL8814A

Tell the chip the maximum AMPDU size supported by the AP. This greatly
improves the TX speed of RTL8814AU in the 2.4 GHz band. Before: ~90
Mbps. After: ~300 Mbps.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/4edc2a63-81b3-431c-9a37-5a7d899a6cc2@gmail.com

wifi: rtw88: usb: Enable RX aggregation for RTL8814AU

Let the chip transfer several frames in a single USB Request Block.
This is supposed to improve the RX speed.

It can use the same code used for RTL8822CU, RTL8822BU, and RTL8821CU.

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/672397ac-dd4d-4420-8b3e-7011578e2243@gmail.com

wifi: rtw88: usb: Enable switching the RTL8814AU to USB 3

The Realtek wifi 5 devices which support USB 3 are weird: when first
plugged in, they pretend to be USB 2. The driver needs to send some
commands to the device, which make it disappear and come back as a
USB 3 device.

The method used to switch the RTL8812AU also works for the RTL8814AU.

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/d3608f70-e04f-4f6b-987a-022c8e317165@gmail.com

wifi: rtw88: usb: Remove redundant 'flush_workqueue()' calls

'destroy_workqueue()' already drains the queue before destroying it, so
there is no need to flush it explicitly.

Remove the redundant 'flush_workqueue()' calls.

This was generated with coccinelle:

@@
expression E;
@@

- flush_workqueue(E);
  destroy_workqueue(E);

Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250324080303.408084-1-nichen@iscas.ac.cn

wifi: rtw88: sdio: Remove redundant 'flush_workqueue()' calls

'destroy_workqueue()' already drains the queue before destroying it, so
there is no need to flush it explicitly.

Remove the redundant 'flush_workqueue()' calls.

This was generated with coccinelle:

@@
expression E;
@@

- flush_workqueue(E);
  destroy_workqueue(E);

Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250324075910.407999-1-nichen@iscas.ac.cn

wifi: rtw89: 8852bx: support different SAR configs by antenna

Calculate difference of SAR configs between RF path A and RF path B.
And then, based on the calculated result, set the TX power reference
CR (control register). Finally, declare to support SAR by antenna in
8852b/8852bt chip info.

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

wifi: rtw89: 8852c: support different SAR configs by antenna

Set SAR configs to the corresponding CRs (control registers) according to
RF path. Then, declare to support SAR by antenna in chip info.

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

wifi: rtw89: 8922a: support different SAR configs by antenna

Set SAR configs to the corresponding CRs (control registers) according to
RF path. Then, declare to support SAR by antenna in chip info.

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

wifi: rtw89: sar: add skeleton for different configs by antenna

Some SAR sources, e.g. ACPI, may allow different SAR configs by antenna.
Previously, the minimum config between antennas was taken. Because there
are differences between HW design, different chips might have different
solutions to achieve this. So, it cannot be done through a single common
handling. Now, add the relevant skeleton for this purpose ahead.

First, add a flag into chip info to describe whether it has implemented
this function or not. Second, support to query SAR config for a given RF
path. With it, each chip can implement its own handling. Then, if a chip
declares to support this function, when it queries SAR config without a
given RF path, it gets a maximum config between antennas.

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

wifi: rtw89: acpi: support loading GEO SAR tables

Support to load GEO (geography) SAR tables with ACPI RWGS method. When
SAR values could be different by regulatory, GEO SAR can be used. The
format of GEO SAR is like the following, where regulatory number, band
number, and delta number are determined by header of either static SAR
or dynamic SAR. (It also means that no GEO SAR will be considered when
neither static SAR nor dynamic SAR is configured.)

                               delta number
                             /               \
                    + +-----+-----------------+
                  / | | max | delta...        | \
                 /  | +-----+-----------------+  band
                /   | | max | delta...        |  number
               /    | +-----+-----------------+
              /     | |...                    | /
                    + +-----+-----------------+
                    | | max | delta...        | \
       regulatory   | +-----+-----------------+  band
       number       | | max | delta...        |  number
                    | +-----+-----------------+
                    | |...                    | /
                    + +-----+-----------------+
              \     | |...                    |
               \    | |...                    |
                \   | |...                    |
                 \  | |                       |
                  \ | |                       |
                    + +-----+-----------------+

Each entry of GEO SAR contains delta field(s), which are offset(s) used
to tweak the loaded static/dynamic SAR table(s) by antenna, and one max
field, which describes the maximum of the final SAR values after tweaked.
Different entries should be configured based on both regulatory and band.

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

wifi: rtw89: acpi: support loading dynamic SAR tables and indicator

Support to load dynamic SAR tables with ACPI RWRD method. The content
format of a single dynamic SAR table is basically the same as static
SAR table. However, it's able to carry multiple dynamic SAR tables at
one time. And, its header contains one more field to describe how many
dynamic SAR tables are filled in the content. Either static SAR table
or dynamic SAR tables can be supported, but not both simultaneously.

Besides, also support to load indicator of dynamic SAR with ACPI RWSI
method. The indicator will describe a target dynamic SAR table, which
should be followed currently, by antenna. It can be changed at runtime
according to platform mode. For example, tablet mode can use different
SAR from normal mode. So, track indicator configuration if dynamic SAR
is configured.

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

wifi: rtw89: acpi: support loading static SAR table

Support to load static SAR table with ACPI WRDS method. The format of
a static SAR table is like the following, where according to header,
antenna number could be either 2 or 4 and subband number could either
contain 6 GHz or not. And then, an entry of it describes a TX power
limitation with a given unit, which is also based on header, for the
antenna under the subband. Though things can be determined by header,
still not all combinations are allowed in content. For the recognizing
flow, there is a list of allowed combinations.

               +--------------------------------+
               |             header             |
               +--------------------------------+
               +---+---+---+---+---+------------+ +
             / |   |   |   |   |   | ...        | | \
               +---+---+---+---+---+------------+ |
      antenna  |   |   |   |   |   | ...        | |
      number   +---+---+---+---+---+------------+ |   content
               |...|   |   |   |   | ...        | |
               +---+---+---+---+---+------------+ |
             \ |...|   |   |   |   | ...        | | /
               +---+---+---+---+---+------------+ +
                \                              /
                          subband number

Following the format above, try to load a static SAR table and normalize
its content into SW structure. If any recognized is loaded, SW SAR flow
is then set up with source from ACPI.

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

wifi: rtw89: acpi: introduce method evaluation function for reuse

The following implementations will evaluate different ACPI methods, but
the pre-process flow of them are the same. So, introduce a function for
these pre-process things. Besides, also change ACPI RTAG method to call
this function.

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

wifi: rtw89: sar: add skeleton for SAR configuration via ACPI

To support SAR configuration in BIOS via ACPI, add related subbnad/band
converting/handling function and define SW format to store result after
parsing. Then, register a new SAR source, i.e. ACPI, into SAR flow and
implement its query function.

Besides, tweak priority of common SAR to be the highest. And, ACPI SAR
can just be configured once when no other sources is already working.
For now, evaluating SAR via ACPI returns -ENOENT, i.e. ACPI SAR doesn't
really work yet. The evaluating flow will be implemented in the following.

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

wifi: rtw89: sar: introduce structure to wrap query parameters

The following implementations will support SAR source from ACPI/BIOS.
And when querying, it needs to take more parameters into account. To
avoid changing function prototype of querying SAR everytime when new
SAR source is introduced, wrap query parameters into a structure first.

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

wifi: rtw89: regd: introduce string getter for reuse

Introduce a function to get the string for a given regulatory. It will be
used in the following. Besides, drop similar things in debug code and use
this too.

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

wifi: rtw89: fix typo of "access" in rtw89_sar_info description

The "acces" should be "access".
So, fix it.

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

wifi: rtw89: phy: reset value of force TX power for MAC ID

The force TX power function is disabled, but the force TX power value is
preserved, causing misunderstand the behavior in debug. Clear all values.

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

wifi: rtw89: fw: cast mfw_hdr pointer from address of zeroth byte of firmware->data

The firmware->size is validated before using firmware->data, but Coverity
still reports:
  Downcasting "firmware->data" from "u8 const *" to "struct rtw89_mfw_hdr"
  implies that the data that this pointer points to is tainted."

Using &firmware->data[0] to avoid the warning. No change logic at all.

Addresses-Coverity-ID: 1494046 ("Untrusted loop bound")
Addresses-Coverity-ID: 1544385 ("Untrusted array index read")

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

wifi: rtw89: set 2TX for 1SS rate by default

To improve performance in range, for 1SS rate, transmit the same signal
on 2 antenna, which is called 2TX.

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

wifi: mt76: mt7996: fix locking in mt7996_mac_sta_rc_work()

The 'continue' statements need to be under spinlock, since
the spinlock needs to be held as a loop invariant.

Fixes: 0762bdd30279 ("wifi: mt76: mt7996: rework mt7996_mac_sta_rc_work to support MLO")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Merge tag 'mt76-next-2025-03-19' of https://github.com/nbd168/wireless

Felix Fietkau says:
====================
mt76 patches for 6.15

- preparation for mt7996 mlo support
- fixes
====================

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

wifi: mt76: mt76x2u: add TP-Link TL-WDN6200 ID to device table

The TP-Link TL-WDN6200 "Driverless" version cards use a MT7612U chipset.

Add the USB ID to mt76x2u driver.

Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Link: https://patch.msgid.link/20250317102235.1421726-1-uwu@icenowy.me
Signed-off-by: Felix Fietkau <nbd@nbd.name>

wifi: mt76: mt792x: re-register CHANCTX_STA_CSA only for the mt7921 series

CSA is currently not supported on mt7925, so CSA is only registered for
the mt7921 series

Cc: stable@vger.kernel.org
Fixes: 8aa2f59260eb ("wifi: mt76: mt7921: introduce CSA support")
Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com>
Link: https://patch.msgid.link/20250313054044.2638837-1-mingyen.hsieh@mediatek.com
Signed-off-by: Felix Fietkau <nbd@nbd.name>

wifi: mt76: mt7996: Update mt7996_tx to MLO support

Rework mt7996_tx routine in order to support multi-link
setup.

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-21-015b3d6fd928@kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>

wifi: mt76: mt7996: rework mt7996_ampdu_action to support MLO

Active/de-active TX/RX BA sessssion for each active links running
mt7996_ampdu_action routine.

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-20-015b3d6fd928@kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>

wifi: mt76: mt7996: rework set/get_tsf callabcks to support MLO

This is a preliminary patch in order to enable MLO for MT7996 driver.

Co-developed-by: Bo Jiao <Bo.Jiao@mediatek.com>
Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com>
Co-developed-by: Peter Chiu <chui-hao.chiu@mediatek.com>
Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com>
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-19-015b3d6fd928@kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>

wifi: mt76: mt7996: set vif default link_id adding/removing vif links

This info will be consumed by subsequent patches (e.g. in set/get tsf
routines).

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-18-015b3d6fd928@kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>

wifi: mt76: mt7996: rework mt7996_mcu_beacon_inband_discov to support MLO

Rework mt7996_mcu_beacon_inband_discov routine in order to support
multi-link setup.

Co-developed-by: Bo Jiao <Bo.Jiao@mediatek.com>
Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com>
Co-developed-by: Peter Chiu <chui-hao.chiu@mediatek.com>
Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com>
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-17-015b3d6fd928@kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>

wifi: mt76: mt7996: rework mt7996_mcu_add_obss_spr to support MLO

Rework mt7996_mcu_add_obss_spr routine in order to support multi-link
setup.

Co-developed-by: Bo Jiao <Bo.Jiao@mediatek.com>
Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com>
Co-developed-by: Peter Chiu <chui-hao.chiu@mediatek.com>
Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com>
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-16-015b3d6fd928@kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>

wifi: mt76: mt7996: rework mt7996_net_fill_forward_path to support MLO

Rework mt7996_net_fill_forward_path routine in order to support multi-link
setup.

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-15-015b3d6fd928@kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>

wifi: mt76: mt7996: rework mt7996_update_mu_group to support MLO

Rework mt7996_update_mu_group routine in order to support multi-link
setup.

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-14-015b3d6fd928@kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>

wifi: mt76: mt7996: rework mt7996_mac_sta_poll to support MLO

Rework mt7996_mac_sta_poll routine in order to support multi-link
setup.

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-13-015b3d6fd928@kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>

wifi: mt76: mt7996: rework mt7996_mac_sta_rc_work to support MLO

Rework mt7996_mac_sta_rc_work routine in order to support multi-link
setup.

Co-developed-by: Bo Jiao <Bo.Jiao@mediatek.com>
Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com>
Co-developed-by: Peter Chiu <chui-hao.chiu@mediatek.com>
Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com>
Co-developed-by: Shayne Chen <shayne.chen@mediatek.com>
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-12-015b3d6fd928@kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>

wifi: mt76: mt7996: remove mt7996_mac_enable_rtscts()

It is controlled by FW, also, driver should not directly write WTBL to
prevent WTBL overwritten issues.

Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-11-015b3d6fd928@kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>

wifi: mt76: mt7996: rework mt7996_sta_hw_queue_read to support MLO

Extend mt7996_sta_hw_queue_read to support multi-link setup.

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-10-015b3d6fd928@kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>

wifi: mt76: mt7996: rework mt7996_set_hw_key to support MLO

Modify mt7996_set_hw_key routine to work in a multi-link setup.
This is a preliminary patch to enable MLO for MT7996 driver

Co-developed-by: Bo Jiao <Bo.Jiao@mediatek.com>
Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com>
Co-developed-by: Peter Chiu <chui-hao.chiu@mediatek.com>
Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com>
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-9-015b3d6fd928@kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>

wifi: mt76: mt7996: Add mt7996_sta_link to mt7996_mcu_add_bss_info signature

This is a preliminary patch to introduce MLO support for MT996 driver.

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-8-015b3d6fd928@kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>