The rtw89 is continuously adjusting code to support MLO. The major changes
are listed below:
rtw88:
* fix USB not transmitting beacon in AP mode
rtw89:
* complete BT-coexistence code for RTL8852BT
* fix throughput degrade of VHT rate for RTL8851B/8852A/8852B/8852BT
* enable WoWLAN net-detect for more one chip, RTL8922A
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuyEnvMdOsBl1WjpdjlvZYmhshd8FAmbZCZEACgkQjlvZYmhs
hd8JkhAAoSROgMtLBakR5tGkkGeIqqdYF1/6tXes+nrr08taLMLaqRco1W9xvJGJ
5jIn6YdEIB1DyDvU8YR7+1YwZxr8C5Etu4qle6G691eEVi61ksxUV12zwFvEQM+9
8PwU/b0pSjhpu12CLJSOFDcSiOkyYtwCSar23Cek4jjNE+anUfhoPUnaeSSiiv2j
Kd4AtsLM/GWZVQr/FQgMumeB9y2rlZ00wg0WDSjjpHu2EuAJql/d4kbMgFHCljmS
Il2l7nZ6euzab1D8WorXIYgoMG1a7eBeT/SeQiwhS9DmhZj8q4ncFsXTegj0pxI7
qLiJHeUUbEuDis7qCP4GpQ2jto1D1tNhe8ExKv0OGAOn+Iwhgo/2x2h0kHUqBiuT
8FY4SvHcQRRdThKT9Uyr6T67+4NGNTC5Mbx3+cfNf7RSy6ONNPRX/BOOuT5v6tw1
xNrgyc8LsorEi+Cna+Y3Y0reerG8W4we5rrOqG0DEikJq8rp3JWZw5vvCgYitRoA
KbBhaj31+Ppw8vbc/WBZrGhIzgh1ven945muP+c5Pt55uHFURjnMOOfmln/Pecrl
hOjuiZVNGJU0iW9Z9i2wGkbih14omVG16iWyMLgknrL3fSNZW79v4j4Uf0ZCyb6G
cPiVCIb9OQHNeNlx6IH4L5FMOpMl8KEym9uFDT7QUhrvAX9M42A=
=G2FN
-----END PGP SIGNATURE-----
Merge tag 'rtw-next-2024-09-05' of https://github.com/pkshih/rtw
rtw-next patches for v6.12
The rtw89 is continuously adjusting code to support MLO. The major changes
are listed below:
rtw88:
* fix USB not transmitting beacon in AP mode
rtw89:
* complete BT-coexistence code for RTL8852BT
* fix throughput degrade of VHT rate for RTL8851B/8852A/8852B/8852BT
* enable WoWLAN net-detect for more one chip, RTL8922A
Because the loop-expression will do one more time before getting false from
cond-expression, the original code copied one more entry size beyond valid
region.
Fix it by moving the entry copy to loop-body.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240902015803.20420-1-pkshih@realtek.com
To get more accurate RSSI, this commit includes frequency domain RSSI
info in RSSI calculation. Add correspond physts parsing and macro to
get frequency domain RSSI information for supported IC.
Signed-off-by: Eric Huang <echuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240828055217.10263-3-pkshih@realtek.com
Use RSSI without subtracting offset as packet detection lower bound and
set an absolute minimal threshold. It's equivalent to setting a higher
noise floor, thereby reducing false alarm and improving interference
endurance.
Signed-off-by: Eric Huang <echuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240828055217.10263-2-pkshih@realtek.com
mwifiex has recently started to see active development which is good
news. rtw89 is also under active development and got several new
features. Otherwise not really anything out of ordinary.
We have one conflict in ath12k but that's easy to fix:
https://lore.kernel.org/all/20240808104348.6846e064@canb.auug.org.au/
Major changes:
mwifiex
* support for up to ten Authentication and Key Management (AKM) suites
* host MAC Sublayer Management Entity (MLME) client and AP mode support
* WPA-PSK-SHA256 AKM suite support
rtw88
* improve USB performance by aggregation
rtw89
* Wi-Fi 6 chip RTL8852BE-VT support
* WoWLAN net-detect support
* hardware encryption in unicast management frames support
* hardware rfkill support
ath12k
* DebugFS support for transmit DE stats
* Make ASPM support hardware-dependent
iwlwifi
* channel puncturing for US/CAN from UEFI
* bump FW API to 93 for BZ/SC devices
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEiBjanGPFTz4PRfLobhckVSbrbZsFAmbYfCARHGt2YWxvQGtl
cm5lbC5vcmcACgkQbhckVSbrbZt+Qwf/X9oQ4sf8jV6eOV7EhoWhIHnQadvo5YBZ
ulBm8In0QGjEOVWkI7kXGabKP5jhne2lVIyP1eFfP2/td/A2yDWIuEeBfDQD6f4K
aiUGAa1gs4ZtGKJBniw/ukflSqJlR99N2qBO5T/smDm3Nw/aC522SO7BoLTpoJDQ
SuW4atFHMShXYf/vIrAA2yB9ok2yw/QM+27M9qjj6D7zzqsQxDl9wKGW+2v8KiSa
rXXbfnwfaQP21CYv5xYbEPACSRSV5Dr0TNopivWYxmm9svjLzwFN2JM2fHPxBEDh
wP6Ojp+Z32c1VbQtclLrwIQdlZ5yhU5MEDlVg5VLym9F83hv+oXTbA==
=lgVx
-----END PGP SIGNATURE-----
Merge tag 'wireless-next-2024-09-04' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Kalle Valo says:
====================
pull-request: wireless-next-2024-09-04
here's a pull request to net-next tree, more info below. Please let me know if
there are any problems.
====================
Conflicts:
drivers/net/wireless/ath/ath12k/hw.c
38055789d1 ("wifi: ath12k: use 128 bytes aligned iova in transmit path for WCN7850")
8be12629b4 ("wifi: ath12k: restore ASPM for supported hardwares only")
https://lore.kernel.org/87msldyj97.fsf@kernel.org
Link: https://patch.msgid.link/20240904153205.64C11C4CEC2@smtp.kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The scan interval option is the period in unit of second for WoWLAN
firmware to do each scan. We get the option from cfg80211 and practice it.
If the interval is too short for firmware to finish one scan, the firmware
will start next scan immediately after finishing one and the WiFi chip
could never enter idle mode to reduce power consumption.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240826090439.17242-5-pkshih@realtek.com
The C2H packet of FW-IPS mode is not handled by driver in the suspend
flow, and lead to WoWLAN firmware fail to enter PS mode and even some
SER happen. So add wait function for H2C of FW-IPS mode to check driver
handle the C2H packet before disabling interrupt and make the net-detect
function work fine.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240826090439.17242-3-pkshih@realtek.com
Each condition binding to the same wait should be unique. AOAC code misused
the wait of FW offload series and broke the above rule. It added another
macro to generate wait condition of WoWLAN/AOAC, but the results conflict
to the ones of FW offload series. It means that we might be completed
wrongly in logic. We don't want things work/read like this and should
have avoided this.
Fix this by adding another wait which aims for WoWLAN functions.
Fixes: ff53fce5c7 ("wifi: rtw89: wow: update latest PTK GTK info to mac80211 after resume")
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240826090439.17242-2-pkshih@realtek.com
A mac_id as an instance in firmware has to be assigned for each station
including AP and connected stations. Firmware will use the mac_id to
control TX rate and do statistics.
Assignment rule is to assign mac_id to each vif when adding vif.
For station mode, sta->mac_id will reuse vif->mac_id. For AP mode,
dynamically allocate an sta->mac_id to a station, and vif->mac_id is
used to send broadcast/multicast packets which are not belong to
a station. For example,
vif->mac_id sta->mac_id
vif0 (STA mode) 0 0
vif1 (AP mode) 1 2...
By the way, remove unused RTW_BC_MC_MACID, which was planed to send
broadcast/multicast packets on fixed mac_id.
Tested-on RTL8822CE with STA + AP SCC mode.
Link: https://lore.kernel.org/linux-wireless/e4be0a75-43b2-4ae5-9aab-5c4a88e78097@gmail.com/
Cc: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240819025248.17939-1-pkshih@realtek.com
All USB devices supported by rtw88 have the same problem: they don't
transmit beacons in AP mode. (Some?) SDIO devices are also affected.
The cause appears to be clearing BIT_EN_BCNQ_DL of REG_FWHW_TXQ_CTRL
before uploading the beacon reserved page, so don't clear the bit for
USB and SDIO devices.
Tested with RTL8811CU and RTL8723DU.
Cc: <stable@vger.kernel.org> # 6.6.x
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/49de73b5-698f-4865-ab63-100e28dfc4a1@gmail.com
Configure supported link number by chip. And, introduce driver capability
flag for MLO. Driver should depend on runtime FW features and chip info to
determine whether to set the MLO capability flag or not. Once the MLO flag
is set, driver will consider/register/initialize things for MLO usages.
However, we just add the driver MLO capability flag ahead and don't really
set it. Then, we can start to tweak driver architecture for MLO. Some code
should depend on this flag. And after tweaking driver architecture is done,
we will set it based on runtime conditions as mentioned above.
Besides, MLD number supported by HW should be
chip supported mac_id number / chip supported link number
Without driver MLO capability flag, we allocate stations based on supported
mac_id number. With driver MLO capability flag, we allocate stations based
on supported MLD number.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240819091724.33730-9-pkshih@realtek.com
The target enum has been renamed to rtw89_"chanctx"_idx. So for
readability, rename roc_entity_idx to roc_"chanctx"_idx to align.
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/20240819091724.33730-8-pkshih@realtek.com
No longer access chan with hard-code RTW89_CHANCTX_X whenever possible.
Instead, obtain the right chanctx from somewhere and use it in RTL8922A
RFK (RF calibration) related code.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240819091724.33730-7-pkshih@realtek.com
No longer access chan with hard-code RTW89_CHANCTX_X whenever possible.
Instead, obtain the right chanctx from somewhere and use it in RTL8852C
RFK (RF calibration) related code.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240819091724.33730-6-pkshih@realtek.com
No longer access chan with hard-code RTW89_CHANCTX_X whenever possible.
Instead, obtain the right chanctx from somewhere and use it in RTL8852BX
RFK (RF calibration) related code.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240819091724.33730-5-pkshih@realtek.com
No longer access chan with hard-code RTW89_CHANCTX_X whenever possible.
Instead, obtain the right chanctx from somewhere and use it in RTL8852A
RFK (RF calibration) related code.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240819091724.33730-4-pkshih@realtek.com
No longer access chan with hard-code RTW89_CHANCTX_X whenever possible.
Instead, obtain the right chanctx from somewhere and use it in RTL8851B
RFK (RF calibration) related code.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240819091724.33730-3-pkshih@realtek.com
Originally, all chips have implemented rfk_band_changed() and access chan
with hard-code RTW89_CHANCTX_0 in it. But, it's problematic when the chip
supports multiple channels.
So, change the prototype of rfk_band_changed() and pass chan ahead. And,
we will refine the implementation of each chip 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/20240819091724.33730-2-pkshih@realtek.com
There are many features need the information those record at Wi-Fi role
structure. Implement the corresponding code for using.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240816124614.25592-5-pkshih@realtek.com
To get Wi-Fi channel & bandwidth information from new Wi-Fi role format.
Bluetooth will negotiate which channel to do TX/RX with connected device.
And Bluetooth will maintain a hopping map, that describe the usable
channels. To avoid the interference from Wi-Fi 2.4GHz/Bluetooth each other,
Bluetooth must not to hop into Wi-Fi channel.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240816124614.25592-4-pkshih@realtek.com
Add the firmware related version code for RTL8852BT version 0.29.90.0.
And add the version 7 report control structure format. Firmware will
collect counters like mailbox count, RF on/off count, and some Bluetooth
related counters into this structure and pass to driver periodically.
It will help to understand how the firmware mechanism working.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240816124614.25592-2-pkshih@realtek.com
If the PPDU length for VHT rate exceeds 0x40000, calculating the PSDU
length will overflow. TMAC will determine the length to be too small and
as a result, all packets will be sent as ZLD (Zero Length Delimiter).
Fixes: 5f7e92c59b ("wifi: rtw89: 8852b: set AMSDU limit to 5000")
Signed-off-by: Chia-Yuan Li <leo.li@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240815134054.44649-1-pkshih@realtek.com
The rtw89 uses debugfs to access registers and driver states. To get
a range of registers, the range value is set and stored to a variable, and
get the set of register values by the stored range. However, the variable
is a static global variable, which multiple adapters will be a problem,
so move the variable to adapter context rtw89_dev.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240816115700.17390-1-pkshih@realtek.com
In 'rtw_coex_action_bt_a2dp_pan', 'wl_cpt_test' and 'bt_cpt_test' are
hardcoded to false, so corresponding 'table_case' and 'tdma_case'
assignments are never met.
Also 'rtw_coex_set_rf_para(rtwdev, chip->wl_rf_para_rx[1])' is never
executed. Assuming that CPT was never fully implemented, remove
lookalike leftovers. Compile tested only.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 76f631cb40 ("rtw88: coex: update the mechanism for A2DP + PAN")
Signed-off-by: Dmitry Kandybka <d.kandybka@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240809085310.10512-1-d.kandybka@gmail.com
Coverity reported that u8 rx_mask << 24 will become signed 32 bits, which
casting to unsigned 64 bits will do sign extension. For example,
putting 0x80000000 (signed 32 bits) to a u64 variable will become
0xFFFFFFFF_80000000.
The real case we meet is:
rx_mask[0...3] = ff ff 00 00
ra_mask = 0xffffffff_ff0ff000
After this fix:
rx_mask[0...3] = ff ff 00 00
ra_mask = 0x00000000_ff0ff000
Fortunately driver does bitwise-AND with incorrect ra_mask and supported
rates (1ss and 2ss rate only) afterward, so the final rate mask of
original code is still correct.
Addresses-Coverity-ID: 1504762 ("Unintended sign extension")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240809072012.84152-5-pkshih@realtek.com
The handler of firmware C2H event RTW89_MAC_C2H_FUNC_READ_WOW_CAM isn't
implemented, but driver expects number of handlers is
NUM_OF_RTW89_MAC_C2H_FUNC_WOW causing out-of-bounds access. Fix it by
removing ID.
Addresses-Coverity-ID: 1598775 ("Out-of-bounds read")
Fixes: ff53fce5c7 ("wifi: rtw89: wow: update latest PTK GTK info to mac80211 after resume")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240809072012.84152-4-pkshih@realtek.com
TX EVM will significantly decrease for long packets when
the TX idle time increases. Introduce digital compensation
based on TX idle time, to mitigate TX EVM degradation, and
TX throughput improved from 1871 to 1947 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/20240809072012.84152-3-pkshih@realtek.com
Firmware from v1 will include fw_element so that the driver will loading
parameters of BB and RF, TX power related tables from firmware. For the
current flow, if fw_element is present, the driver will prioritize
loading parameters and tables from firmware; otherwise, it will
revert to the original loading method.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240809072012.84152-2-pkshih@realtek.com
Enable USB RX aggregation when there is at least 1 Mbps RX or TX
traffic, otherwise disable it.
USB RX aggregation improves the RX speed of RTL8811CU on certain ARM
systems, like the NanoPi NEO Core2. Before: 28 Mbps, after: 231 Mbps.
It also improves the RX speed of RTL8822CU on some x86_64 systems.
Before: ~200 Mbps, after: ~300 Mbps.
The official drivers for these chips use the same logic for SDIO, but
for some reason the SDIO driver in rtw88 always enables RX aggregation,
so this patch only toggles aggregation for USB devices.
RTL8703B is likely not found in USB devices, and RTL8723DU doesn't like
aggregation.
Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/b4c0d54c-6755-4b0f-9dd7-f9196fd74b68@gmail.com
The chips can be configured to aggregate several frames into a single
USB transfer. Modify rtw_usb_rx_handler() to support this case.
RX aggregation improves the RX speed of RTL8811CU on certain ARM
systems, like the NanoPi NEO Core2. It also improves the RX speed of
RTL8822CU on some x86_64 systems.
Currently none of the chips are configured to aggregate frames.
Tested with RTL8822CU, RTL8811CU, and RTL8723DU.
Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/f845826d-de71-492d-9a22-e48c07989a1f@gmail.com
Update the number of received unicast data frames and bytes every time
a frame is received. This is what the PCI and SDIO drivers do.
This has an influence on the power saving, bluetooth coexistence, and
(in a future patch) the use of RX aggregation.
Tested with RTL8822CU, RTL8811CU, and RTL8723DU.
Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/75a2ca52-8f01-45c5-926f-d3a68ae3b284@gmail.com
This is needed in order to make USB RX aggregation work with RTL8811CU
(and presumably RTL8822BU and RTL8822CU also).
I don't know what BIT_DMA_BURST_CNT, BIT_DMA_MODE, and BIT_DROP_DATA_EN
are doing.
Tested with RTL8822CU, RTL8811CU, and RTL8723DU.
The RX speed is unchanged in my tests.
Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/ac569c6f-7129-4341-b523-901fe10cabff@gmail.com
The rtl8xxxu has all the rtl8192cu USB IDs except for the
following 3 so add them to the untested section so they
can be used with the rtl8xxxu as the rtl8192cu are well
supported.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240806082233.3837436-1-pbrobinson@gmail.com
The Kconfig notes mention staging drivers that have
since been removed so update the driver's description
so it no longer references the staging rtl8723au and
rtl8192u drivers which have now been deleted.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240805221910.3765214-1-pbrobinson@gmail.com
The delay option is the period in unit of second for WoWLAN firmware
to wait before the first scan. We get the option from cfg80211 and
practice it. Another, in some platform, WoWLAN firmware may found
configured network and then trigger resume process, before suspend
process is completed, lead to the wakeup function failed.
So the default value is set one to avoid the issue.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240805090028.27768-5-pkshih@realtek.com
Net-detect is an option of WoWLAN to allow the device to
be woken up from suspend mode when configured network is detected.
When user enables net-detect and lets the device enter suspend
state, WoWLAN firmware will periodically scan until beacon or
probe response of configured networks are received. If configured
networks are detected, WoWLAN firmware will trigger resume process.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240805090028.27768-4-pkshih@realtek.com
When net-detect is enabled, WoWLAN firmware will periodically
scan until beacon or probe response of configured networks are
received. To reduce power consumption, the FW-IPS mode is
implemented to keep WiFi chip in idle mode between each scan.
The FW-IPS is controlled by WoWLAN firmware to turn of some critical
electrical components, and is different from the original IPS mode
which most electrical components are turned off.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240805090028.27768-3-pkshih@realtek.com
Driver has supported different WoWLAN reason code by commit 0e52102177
("wifi: rtw89: wow: update WoWLAN reason register for different FW")
since firmware version 0.27.80.0. The old driver can't support two
kinds of WoWLAN reason, so increase firmware format to v1.
Also driver tables of BB and RF registers and power values will be added
into v1 format.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240805090028.27768-2-pkshih@realtek.com
GCC complains:
In file included from include/linux/ieee80211.h:21,
from include/net/mac80211.h:20,
from drivers/net/wireless/realtek/rtlwifi/rtl8192du/../wifi.h:14,
from drivers/net/wireless/realtek/rtlwifi/rtl8192du/hw.c:4:
In function 'u32p_replace_bits',
inlined from '_rtl92du_init_queue_reserved_page.isra' at drivers/net/wireless/realtek/rtlwifi/rtl8192du/hw.c:225:2:
>> include/linux/bitfield.h:189:18: warning: 'value32' is used uninitialized [-Wuninitialized]
Part of the variable is indeed left uninitialised.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202408062100.DWhN0CYH-lkp@intel.com/
Fixes: e769c67105 ("wifi: rtlwifi: Add rtl8192du/hw.{c,h}")
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/2a808244-93d0-492c-b304-ae1974df5df9@gmail.com
It may get wrong bitrate when connecting to AP set VHT 20MHz,
and thus we fix it to follow Wi-Fi spec.
Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240731070506.46100-6-pkshih@realtek.com
Add hardware encryption support for unicast management frames for
8922AE and 8852CE. Other chips will continue to use software
encryption for unicast management frames.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240731070506.46100-5-pkshih@realtek.com
Update scan offload H2C format to fit firmware version 35.21.
The new fields indicate lengths of variable length members, so
when driver and firmware are using mismatch version, FW could
handle the parsing better.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240731070506.46100-3-pkshih@realtek.com
For firmware version 0.35.31 and above, update H2C RFK
pre-notify to new implementation. Rename existing H2C
to v0 for backward compatibility.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240731070506.46100-2-pkshih@realtek.com
Originally, rtw89_btc_phymap() and rtw89_btc_path_phymap() access chan
with hard-code RTW89_CHANCTX_0. But, they are problematic when the chip
supports multiple channels.
So, change their prototype and pass chanctx_idx ahead. Let callers still
pass RTW89_CHANCTX_0 for now, but we will refine callers 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/20240727080650.12195-8-pkshih@realtek.com
Originally, these H2C commands access chan with hard-code RTW89_CHANCTX_0.
They are problematic when the chip supports multiple channels. So, correct
them by accessing right chan under rtwvif.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240727080650.12195-7-pkshih@realtek.com
