After enabling packet offload, the TX will be stuck after resume from
WoWLAN mode. And the 8852c gets error messages like
rtw89_8852ce 0000:04:00.0: No busy txwd pages available
rtw89_8852ce 0000:04:00.0: queue 0 txwd 100 is not idle
rtw89_8852ce 0000:04:00.0: queue 0 txwd 101 is not idle
rtw89_8852ce 0000:04:00.0: queue 0 txwd 102 is not idle
rtw89_8852ce 0000:04:00.0: queue 0 txwd 103 is not idle
If suspend/resume many times that firmware will download failed and
disconnection.
To fix these issues, We removed the rtw89_hci_disable_intr() and
rtw89_hci_enable_intr() during rtw89_wow_swap_fw() to prevent add packet
offload can't receive c2h back due to interrupt disable. Only 8852C and
8922A needs to disable interrupt before downloading fw.
Furthermore, we avoid using low power HCI mode on WoWLAN mode, to prevent
interrupt enabled, then get interrupt and calculate RXBD mismatched due to
software RXBD index already reset but hardware RXBD index not yet.
Fixes: 5c12bb66b7 ("wifi: rtw89: refine packet offload flow")
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/20240502022505.28966-3-pkshih@realtek.com
Remove unnecessary includes from driver. The first step is to add
necessary includes to driver's header files to make them can be included
individually. Then, driver's C files include driver's header files first,
and check if still missed header files of kernel.
The results show that most C files only include driver's header files.
Only core.c needs to include additional linux/firmware.h.
Also sort includes in alphabetic order.
Compile tested only.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/20240429024711.30992-1-pkshih@realtek.com
The driver is already in a directory named rtl8xxxu, there's no need to
duplicate that in the filename as well. Now file listing looks a lot more
reasonable:
8188e.c 8192c.c 8192f.c 8723a.c core.c Makefile rtl8xxxu.h
8188f.c 8192e.c 8710b.c 8723b.c Kconfig regs.h
No functional changes, compile tested only.
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/20240426141939.3881678-2-kvalo@kernel.org
I noticed by random that rtl8xxxu includes linux/wireless.h even though it
doesn't need it. While investigating a bit more I found even more unused
include files:
#include <linux/init.h>
#include <linux/sched.h>
#include <linux/ethtool.h>
It looks like that the includes are just copied to every file without checking
if the file really needs the include. So more includes could be removed but
that would need more careful analysis per each file.
No functional changes, compile tested only.
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/20240426141939.3881678-1-kvalo@kernel.org
Power sequence is a flow to enable/disable WiFi card with hardware
parameters. Adjust power and clock parameters according to results
of internal simulation and verification, so apply them to have better
power consumption.
Signed-off-by: Chia-Yuan Li <leo.li@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/20240426061200.44262-2-pkshih@realtek.com
Improve readability:
* add empty lines
* use abs_diff in rtl92d_dm_txpower_tracking_callback_thermalmeter
* roll up repeated statements into a for loop in
rtl92d_dm_txpower_tracking_callback_thermalmeter
* shorten lines by replacing many instances of "rtlpriv->dm" with "dm"
pointer in rtl92d_dm_txpower_tracking_callback_thermalmeter
* sort some declarations by length
* refactor _rtl92d_get_txpower_writeval_by_regulatory a little
* refactor _rtl92de_readpowervalue_fromprom a little
Delete unused structs tag_dynamic_init_gain_operation_type_definition
and swat.
Simplify rtl92d_fill_h2c_cmd a little and delete a pointless wrapper
function.
Tested with a single MAC single PHY USB dongle from Aliexpress labelled
"CC&C WL-6210-V3".
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://msgid.link/f6acfa78-2f4e-47f1-95d4-65aa77510113@gmail.com
Create the new module rtl8192d-common and move some code into it from
rtl8192de. Now the rtl8192de driver (PCI) and the new rtl8192du driver
(USB) can share some of the code.
This is mostly the code that required little effort to make it
shareable. There are a few more functions which they could share, with
more changes.
Add phy_iq_calibrate member to struct rtl_hal_ops to allow moving the
TX power tracking code from dm.c.
The other changes in this patch are adjusting whitespace, renaming some
functions, making some arrays const, and making checkpatch.pl less
unhappy.
rtl8192de is compile-tested only. rtl8192d-common is tested with the
new rtl8192du driver.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/69c4358a-6fbf-4433-92a6-341c83e9dd48@gmail.com
Structs rx_desc_92d and rx_fwinfo_92d will not work for big endian
systems.
Delete rx_desc_92d because it's big and barely used, and instead use
the get_rx_desc_rxmcs and get_rx_desc_rxht functions, which work on big
endian systems too.
Fix rx_fwinfo_92d by duplicating four of its members in the correct
order.
Tested only with RTL8192DU, which will use the same code.
Tested only on a little endian system.
Cc: stable@vger.kernel.org
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/698463da-5ef1-40c7-b744-fa51ad847caf@gmail.com
Some (all?) management frames are incorrectly reported to mac80211 as
decrypted when actually the hardware did not decrypt them. This results
in speeds 3-5 times lower than expected, 20-30 Mbps instead of 100
Mbps.
Fix this by checking the encryption type field of the RX descriptor.
rtw88 does the same thing.
This fix was tested only with rtl8192du, which will use the same code.
Cc: stable@vger.kernel.org
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/4d600435-f0ea-46b0-bdb4-e60f173da8dd@gmail.com
Different channels have different TX power settings. rtl8192de is using
the TX power setting from the wrong channel in the 5 GHz band because
_rtl92c_phy_get_rightchnlplace expects an array which includes all the
channel numbers, but it's using an array which includes only the 5 GHz
channel numbers.
Use the array channel_all (defined in rtl8192de/phy.c) instead of
the incorrect channel5g (defined in core.c).
Tested only with rtl8192du, which will use the same TX power code.
Cc: stable@vger.kernel.org
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/c7653517-cf88-4f57-b79a-8edb0a8b32f0@gmail.com
This function is to let Bluetooth know Wi-Fi is using which channel,
and ask Bluetooth do not hop into the nearby channel. Wi-Fi channel
is saved at role info, this patch make the logic also get the channel
value from version 8 role info.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/20240423130502.32682-7-pkshih@realtek.com
The feature can help to know how the firmware mechanism working.
There are several trigger point set in firmware. If driver send
the H2C command to firmware to enable the trigger, firmware will
toggle GPIO to perform the firmware mechanism.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/20240418021207.32173-8-pkshih@realtek.com
When the PTA breaks Wi-Fi traffic request caused Bluetooth traffic,
it means Bluetooth polluted the Wi-Fi traffic. When Wi-Fi is TX, the
mechanism can ignore the polluted Wi-Fi packet retry counter, it is
help to the stability of Wi-Fi TX rate. The chip RTL8922A has not only
one MAC, so need to include the all MAC as reference.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/20240418021207.32173-6-pkshih@realtek.com
PTA(packet traffic arbitration) is a coexistence hardware feature.
Wi-Fi & Bluetooth owns their PTA, the function is to show whose PTA
control the traffic now. RTL8922A PTA control is controlled by hardware
logic, there is no register to monitor the setting.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/20240418021207.32173-5-pkshih@realtek.com
The Wi-Fi/Bluetooth slot are toggled by firmware timer when Wi-Fi doing
firmware scan, and Wi-Fi slot don't allow Bluetooth do traffic when
Wi-Fi slot. It will trigger Bluetooth audio lag in a random rate, because
Bluetooth can not have enough time slot to keep enough data to play audio.
This patch make Bluetooth can do traffic during Wi-Fi slot, this can help
Bluetooth to collect audio data in time.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/20240418021207.32173-2-pkshih@realtek.com
Until now RTL8192CU family was using the MAC init table from RTL8723AU,
but these tables are not identical in the two vendor drivers. Import
the correct table for RTL8192CU.
Also move the existing MAC init table to rtl8xxxu_8723a.c, which is
the only remaining user.
Tested with the Netcore NW362 (RTL8192CU).
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/a53ed8b9-27fc-4871-a20a-ad42c6d210d3@gmail.com
In order to connect to networks which require 802.11w, add the
MFP_CAPABLE flag and let mac80211 do the actual crypto in software.
When a robust management frame is received, rx_dec->swdec is not set,
even though the HW did not decrypt it. Extend the check and don't set
RX_FLAG_DECRYPTED for these frames in order to use SW decryption.
Use the security flag in the RX descriptor for this purpose, like it is
done in the rtw88 driver.
Cc: stable@vger.kernel.org
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/20240418071813.1883174-3-martin.kaistra@linutronix.de
We will support MLO on 802.11be chip, e.g. RTL8922A, in the future. At that
time being, we will set WIPHY_FLAG_SUPPORTS_MLO according to chip info and
FW features at runtime. But, with WIPHY_FLAG_SUPPORTS_MLO flag, cfg80211
will disable WEXT. In case inconsistent user experience, if 802.11be chip,
we disable WEXT uniformly from now on.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/20240417090050.42607-1-pkshih@realtek.com
Don't subtract 1 from the power index. This was added in commit
2fc0b8e5a1 ("rtl8xxxu: Add TX power base values for gen1 parts")
for unknown reasons. The vendor drivers don't do this.
Also correct the calculations of values written to
REG_OFDM0_X{C,D}_TX_IQ_IMBALANCE. According to the vendor driver,
these are used for TX power training.
With these changes rtl8xxxu sets the TX power of RTL8192CU the same
as the vendor driver.
None of this appears to have any effect on my RTL8192CU device.
Cc: stable@vger.kernel.org
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/6ae5945b-644e-45e4-a78f-4c7d9c987910@gmail.com
According to BIOS configuration of Realtek ACPI DSM function 7,
RTW89_ACPI_DSM_FUNC_6GHZ_SP_SUP, we handle the regd policy of 6 GHz SP.
If BIOS indicates to override driver settings, we only allow the countries,
which are enabled by BIOS, to use 6 GHz SP power. Other countries will be
applied to select default power when recalculating 6 GHz regulatory power
selection.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/20240412115729.8316-9-pkshih@realtek.com
Realtek ACPI DSM func 7, RTW89_ACPI_DSM_FUNC_6GHZ_SP_SUP, accepts a format
via ACPI buffer as below.
| index | description |
--------------------------------------------
| [0-3] | signature |
| [4] | revision |
| [5] | override driver settings, or not |
| [6] | configuration if override |
| [7] | reserved |
where field of [6] is a bitmap by country,
and for now, only define BIT(0) is for US.
Through this function with overriding, BIOS can indicate to allow/block
6 GHz SP power by country.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/20240412115729.8316-8-pkshih@realtek.com
Originally, we have an ACPI function to determine whether to enable UNII-4.
Since IC (Industry Canada) has allowed UNII-4, the ACPI result is extended
to be two bits as below.
* BIT(0): determine if rtw89_regd::FCC enable UNII-4
* BIT(1): determine if rtw89_regd::IC enable UNII-4
Besides, to take old platforms into account, we enable UNII-4 on IC if and
only if BIOS configuration enable it.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/20240412115729.8316-7-pkshih@realtek.com
