In case of an error, no one will use the allocated structure. Call
ieee80211_free_hw, same as in rtl_usb_disconnect.
Signed-off-by: Reto Schneider <code@reto-schneider.ch>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200622132113.14508-4-code@reto-schneider.ch
Prevent code from calling itself indirectly, causing the driver to hang
and consume 100% CPU.
Without this fix, the following script can bring down a single CPU
system:
```
while true; do
rmmod rtl8192cu
modprobe rtl8192cu
done
```
Signed-off-by: Reto Schneider <code@reto-schneider.ch>
ACKed-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200622132113.14508-2-code@reto-schneider.ch
Sparse reports the following issue:
CHECK drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c:500:26: warning: incorrect type in initializer (different base types)
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c:500:26: expected restricted __le32 [usertype] *pdesc
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c:500:26: got unsigned int [usertype] *
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200604005733.7905-3-Larry.Finger@lwfinger.net
Add a set of logic with corresponding coexistence parameters to
handle the situation under BT inquiry/page.
We will set PSTDMA while WL-Busy + BT inquiry/page to separate
WL/BT slots. PSTDMA can protect WL data rate and BT performance.
If WL-Busy + BT inquiry/page and there was BT device paired,
We will set the mechanism to 4Slot PSTDMA.
In 4Slot PSTDMA, the paired devices can perform more smoothly
and prevent some issues trigger from insufficient data.
And to avoid A2DP glitch or disconnection, we will adjust ACL
data priority higher than inquiry/page.
In addition, we found sometimes BT inquiry/page still working
last for seconds after BT had notified inquiry/page finished.
It will lead to A2DP glitch cause of ACL data, inquiry/page
priority toggled. To fix the corner, we add a timer to remain
the inquiry/page status.
And we found WL busy/idle threshold is too sensitive,
it will keep switching in some weak network environment and
coexistence mechanism will switch between TDMA and PSTDMA.
The very frequently switching may destroyed not only the
handshake with AP, but BT performance. And it will trigger
some unexpected error.
To prevent the frequently switching, we add a timer to delay
the status change while WL busy switch to idle.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200715023324.8600-1-yhchuang@realtek.com
New device ID 0xc82f found on Lenovo ThinkCenter.
Tested it with c822 driver, works good.
PCI id:
03:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd.
Device [10ec:c82f]
Subsystem: Lenovo Device [17aa:c02f]
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200612082745.204400-1-aaron.ma@canonical.com
Some platforms cannot read the DBI register successfully for the
ASPM settings. After the read failed, the bus could be unstable,
and the device just became unavailable [1]. For those platforms,
the ASPM should be disabled. But as the ASPM can help the driver
to save the power consumption in power save mode, the ASPM is still
needed. So, add a module parameter for them to disable it, then
the device can still work, while others can benefit from the less
power consumption that brings by ASPM enabled.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=206411
[2] Note that my lenovo T430 is the same.
Fixes: 3dff7c6e37 ("rtw88: allows to enable/disable HCI link PS mechanism")
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200605074703.32726-1-yhchuang@realtek.com
Since single rf path chips don't support TX SPBC, tell mac80211
to not advertise it.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200603094218.19942-5-yhchuang@realtek.com
Beamforming is used for directional signal transmission/reception.
Beamformee plays the role for signal reception, and makes the RX
performance better in middle distance range.
Implement beamformee related callbacks for 8821c.
Since 8821c only support 1ss rate, nc_index in beamformee setting
needs to be adjusted based on the capability.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200603094218.19942-4-yhchuang@realtek.com
The TX power requires to be adjusted based on the thermal value.
The actual power will decrease if the thermal value raised, and
will increase if the thermal value lowered. Driver comapres the
thermal value, as moving averages. If it changes over a limit,
driver will modify the TX power index to compensate.
Implement rtw_chip_ops::pwr_track() for 8821c.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200603094218.19942-3-yhchuang@realtek.com
CCK PD can reduce the number of false alarm of the CCK rates.
It dynamically adjusts the power threshold and CS ratio.
The values are compared to the values of the previous level, if
the level is changed, set new values of power threshold and CS
ratio.
Implement rtw_chip_ops::cck_pd_set() for 8821c.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200603094218.19942-2-yhchuang@realtek.com
In order to get a better TX EVM, do calibration after association.
The calibration needed for 8821c is the IQK, which is done in the
firmware. Implement the rtw_chip_ops::phy_calibration() to trigger
firmware to calibrate.
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200616091625.26489-8-yhchuang@realtek.com
False alarm statistics can be used to adjust the RX gain. This
helps the driver to adapt to different circumstances.
Implement rtw_chip_ops::false_alarm_statistics() for 8821c.
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200616091625.26489-7-yhchuang@realtek.com
Some RX packets contain also information about environment status.
Implement rtw_chip_ops::query_rx_desc() for 8821c. Parse the RX
descriptor which describes the current condition of the received
packet.
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200616091625.26489-6-yhchuang@realtek.com
8821c is capable of 2.4G and 5G.
Implement rtw_chip_ops::set_channel() to set 2G and 5G channels.
This includes MAC, BB and RF related settings.
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200616091625.26489-5-yhchuang@realtek.com
To improve user experience in field, we need DIG to adjust RX initial
gain depends on field situation.
Define the register addresses for 8821c.
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200616091625.26489-4-yhchuang@realtek.com
To configure the transmit power of 8821c implement trasmit
power index setting callback function for 8821c. This is very
similar to the callback function of 8822b.
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200616091625.26489-3-yhchuang@realtek.com
RTL8821CE chipsets are 802.11ac dual-band WiFi + BT combo chips.
This patch adds the basic functions such as parameter tables, chip
information, power on flow.
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200616091625.26489-2-yhchuang@realtek.com
Since commit 84af7a6194 ("checkpatch: kconfig: prefer 'help' over
'---help---'"), the number of '---help---' has been gradually
decreasing, but there are still more than 2400 instances.
This commit finishes the conversion. While I touched the lines,
I also fixed the indentation.
There are a variety of indentation styles found.
a) 4 spaces + '---help---'
b) 7 spaces + '---help---'
c) 8 spaces + '---help---'
d) 1 space + 1 tab + '---help---'
e) 1 tab + '---help---' (correct indentation)
f) 1 tab + 1 space + '---help---'
g) 1 tab + 2 spaces + '---help---'
In order to convert all of them to 1 tab + 'help', I ran the
following commend:
$ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/'
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The CCK TX setting when switch channel will fix the CCK to
path A only, so if the antenna is configured to path B
(e.g. iw phy set antenna 0x2 0x3 "TX B/RX AB"), then the CCK
packets can never be delivered to the air if only path B is
connected with an antenna (it can possibly be transmitted
through path A, but as path B is configured, the expected
behavior is incorrect).
This can also solve the racing issue of CCK TX setting between
driver and firmware. The CCK TX setting in driver should be
removed. Otherwise, the CCK TX setting would be wrong when the
racing occurs.
Fixes: 297bcf8222 ("rtw88: add support for set/get antennas")
Signed-off-by: Chien-Hsun Liao <ben.liao@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200522091234.24495-1-yhchuang@realtek.com
For older versions of gcc, the array = {0}; will cause warnings:
drivers/net/wireless/realtek/rtw88/rtw8822c.c: In function 'rtw8822c_power_trim':
>> drivers/net/wireless/realtek/rtw88/rtw8822c.c:1039:2: warning:
>> missing braces around initializer [-Wmissing-braces]
s8 bb_gain[2][8] = {0};
^
drivers/net/wireless/realtek/rtw88/rtw8822c.c:1039:2: warning: (near
initialization for 'bb_gain[0]') [-Wmissing-braces]
Fixes: 5ad4d8957b ("rtw88: set power trim according to efuse PG values")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200522035521.12295-1-yhchuang@realtek.com
Connecting to an AP with WPA2 security may fail. The IQK
and the EAPOL 4-way handshake may overlap because the
driver does IQK right after assoc success.
For 802.11n devices, the IQK is done in the driver and it
could require more than 100ms to complete. During IQK, any
TX/RX events are paused. So if the EAPOL 4-way handshake
started before IQK finished, then the 1/4 and 2/4 part of
the handshake could be dropped. The AP will then issue
deauth with reason IEEE8021X_FAILED (23).
To resolve this, move IQK routine into managed TX prepare
(ieee80211_ops::mgd_prepare_tx()). The callback is called
before the managed frames (auth/assoc) are sent. This will
make sure that the IQK is completed before the handshake
starts. But don't do IQK during scanning because doing it
on each channel will take too long.
For 802.11ac devices, the IQK is done in firmware and it
takes less time to complete. Therefore we don't see a
failure during the EAPOL 4-way handshake. But it is still
worth moving the IQK into ieee80211_ops::mgd_prepare_tx().
Fixes: f5df1a8b43 ("rtw88: 8723d: Add 8723DE to Kconfig and Makefile")
Tested-by: You-Sheng Yang <vicamo.yang@canonical.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200529025009.2468-4-yhchuang@realtek.com
Coex mechanism used to make BT have higher priority and more time to
transfer data when BT inquiry-page, which leads to poor WiFi performance.
Should take WiFi traffic into consideration. If the WiFi is having heavy
traffic, use another parameter to make sure WiFi has more chance to TX/RX,
while guarantee the priority of BT for inquiry. If the WiFi isn't busy
(connected or not), set proper parameter to fix originals.
Fixes: f5df1a8b43 ("rtw88: 8723d: Add 8723DE to Kconfig and Makefile")
Tested-by: You-Sheng Yang <vicamo.yang@canonical.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200529025009.2468-3-yhchuang@realtek.com
Without setting antenna control owner, the WiFi could be disconnected if
the BT has traffic. Because the antenna is switched to BT side for its
traffic, and the WiFi will have no chance to transfer data. Set control
owner to prevent WiFi disconnect issue.
Fixes: f5df1a8b43 ("rtw88: 8723d: Add 8723DE to Kconfig and Makefile")
Tested-by: You-Sheng Yang <vicamo.yang@canonical.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200529025009.2468-2-yhchuang@realtek.com
This reverts commit 07d0f55349.
For rtw88 driver, the SDIO is going to be supported, so there is
no need to remove the SDIO related power sequence settings. And
while the power sequence parser will pass in the mask of the HCI,
the SDIO part will not be used to set registers accordingly.
Moreover, the power sequence table is released as a whole package,
so the next time if we are going to update, the SDIO settings will
be overwritten. So, revert this now.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200520055350.23328-1-yhchuang@realtek.com
The for-loop seems to be redundant, the assignments for indexes
0..2 are being over-written by the last index 3 in the loop. Remove
the loop and use index 3 instead.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200515102226.29819-1-colin.king@canonical.com
Currently ldo_pwr has the LDO25 voltage bits set to zero and then
it is overwritten with the new voltage setting. The assignment
looks incorrect, it should be bit-wise or'ing in the new voltage
setting rather than a direct assignment.
Addresses-Coverity: ("Unused value")
Fixes: 1afb5eb7a0 ("rtw88: 8723d: Add cfg_ldo25 to control LDO25")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200514181329.16292-1-colin.king@canonical.com
Rename the name of the kernel module for rtw88's core and pci.
Add proper prefix 'rtw88_' to easily recognize them, also can
avoid confusion with other drivers. (ex. r8822be in staging)
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200515052327.31874-8-yhchuang@realtek.com
remove the unused about pci after extracting chip modules
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200515052327.31874-7-yhchuang@realtek.com
Make objects about 8723d functions and 8723d tables,
i.e. rtw8723d.o and rtw8723d_table.o, an individual
kernel module called rtw88_8723d.ko.
For 8723d pcie chip, i.e. 8723DE chip, add a chip
entry point module called rtw88_8723de.ko which
will depend on rtw88_8723d.ko and rtwpci.ko.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200515052327.31874-6-yhchuang@realtek.com
Make objects about 8822b functions and 8822b tables,
i.e. rtw8822b.o and rtw8822b_table.o, an individual
kernel module called rtw88_8822b.ko.
For 8822b pcie chip, i.e. 8822BE chip, add a chip
entry point module called rtw88_8822be.ko which
will depend on rtw88_8822b.ko and rtwpci.ko.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200515052327.31874-5-yhchuang@realtek.com
Make objects about 8822c functions and 8822c tables,
i.e. rtw8822c.o and rtw8822c_table.o, an individual
kernel module called rtw88_8822c.ko.
For 8822c pcie chip, i.e. 8822CE chip, add a chip
entry point module called rtw88_8822ce.ko which
will depend on rtw88_8822c.ko and rtwpci.ko.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200515052327.31874-4-yhchuang@realtek.com
In the current design, chip entry points are built into
the pci module. That makes the pci module depend on chips.
According to dependence, once the pci module is loaded,
kernel will load chip functionalities, including those that
may not be currently used.
We plan to split chip entry points from the pci module.
Thence we export pci symbols that will be used in chip
entry point modules.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200515052327.31874-3-yhchuang@realtek.com
In the current design, various chip functions and tables
are built into rtw88 core. That causes kernel to load its
functionalities even if a chip isn't currently used. We
plan to make each chip's functionalities a separate
kernel module to reduce rtw88 core. And kernel will be
able to load the necessary.
Before extracting chip functionalities, we export symbols
inside rtw88 core which will be used in chip modules.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200515052327.31874-2-yhchuang@realtek.com
Seven years ago we tried to fix a leak but actually introduced a double
free instead. It was an understandable mistake because the code was a
bit confusing and the free was done in the wrong place. The "skb"
pointer is freed in both _rtl_usb_tx_urb_setup() and _rtl_usb_transmit().
The free belongs _rtl_usb_transmit() instead of _rtl_usb_tx_urb_setup()
and I've cleaned the code up a bit to hopefully make it more clear.
Fixes: 36ef0b473f ("rtlwifi: usb: add missing freeing of skbuff")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200513093951.GD347693@mwanda
Fix the following warning:
drivers/net/wireless/realtek/rtl818x/rtl8187/rtl8225.c:609:17: warning:
‘rtl8225z2_tx_power_ofdm’ defined but not used
static const u8 rtl8225z2_tx_power_ofdm[] = {
Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: ChenTao <chentao107@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200513011754.28432-1-chentao107@huawei.com
sparse warnings: (new ones prefixed by >>)
>> drivers/net/wireless/realtek/rtw88/rtw8723d.c:1899:6: sparse: sparse:
symbol 'rtw8723d_pwr_track' was not declared. Should it be static?
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200512103534.5889-1-yhchuang@realtek.com
8723D adds some experimental features to word 0x06 of cam entry, so fill
zeros to initialize them to off state. For existing chips, these two words
are reserved and always zeros, so this change is harmless for them.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200512102621.5148-9-yhchuang@realtek.com
8723D is a Wifi+BT combo card. To make them work properly, we need coex
mechanism to avoid interference, such as TX simultaneously. Basically,
coex.c provide main algorithm to deal with many use cases, and this commit
adds some parameters and ops differ from other chips, because coex
hardware and WiFi generation are changed.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200512102621.5148-8-yhchuang@realtek.com
Since 8723D use different address of ltecoex register, this commit add a
new field in chip_info and fill proper address. Then, ltecoex_read_reg()
and ltecoex_reg_write() can use them to access ltecoex according to chip.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200512102621.5148-7-yhchuang@realtek.com
Flush queue is used to check if queue is empty, before doing something
else. Since 8723D uses different registers and page number of
availabl/reserved occupy 8 bits instead of 16 bits, so use a 'wsize' field
to discriminate which rtw_read{8,16} is adopted.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200512102621.5148-6-yhchuang@realtek.com
Without this patch, wifi card can't initialize properly due to BT in USB
suspend state. So, we disable BT USB suspend (wakeup) in shutdown callback
that is the moment before rebooting. To save BT USB power, we can't do this
in 'remove' callback.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200512102621.5148-5-yhchuang@realtek.com
When chip's temperature is changed, RF characters are changed. To keep the
characters to be consistent, 8723d uses thermal meter to assist in
calibrating LCK, IQK, crystal and TX power.
A base thermal value is programmed in efuse, all calibration data in
MP process is based on this thermal value. So we calucate the delta of
thermal value between the base value, and use this delta to reference XTAL
and TX power offset tables to know how much we need to adjust.
For IQK and LCK, driver checks if delta of thermal value is over 8, then
they are triggered.
For crystal adjustment, when delta of thermal value is changed, we check
XTAL tables to get offset of XTAL value. If thermal value is larger than
base value, positive table (_p as suffix) is used. Otherwise, we use
negative table (_n as suffix). Then, we add offset to XTAL default value
programmed in efuse, and write sum value to register.
To compensate TX power, there are two hierarchical tables. First level use
delta of thermal value to access eight tables to yield delta of TX power
index. Then, plus base TX power index to get index of BB swing table
(second level tables) where register value is induced.
BB swing table can't deal with all cases, if index of BB swing table is
over the size of the table. In this case, TX AGC is used to compensate the
remnant part. Assume 'upper' is the upper bound of BB swing table, and
'target' is the desired index. Then, we can illustrate them as
compensation method BB swing TX AGC
------------------- -------- --------------
target > upper upper target - upper
target < 0 0 target
otherwise target 0
For debug purpose, add a column 'rem' to tx_pwr_tbl entry, and it looks
like
path rate pwr base (byr lmt ) rem
A CCK_1M 32(0x20) 34 -2 ( 0 -2) 0
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200512102621.5148-4-yhchuang@realtek.com
IQ calibration is used to calibrate RF characteristic to yield expected
performance. Basically, we do calibration twice and compare the similarity
to determine calibration is good or not, if not we do the third
calibration, and then compare with the results of first and second
calibration. If it still not similar, IQK is failed.
Before doing calibration, we need to backup registers that will be
modified in calibration procedure, and restore these registers after
calibration is done.
A calibration procedure can divided into four sub-procedures that are
S1-TX, S1-RX, S0-TX and S0-RX. Where, S1 and S0 represent to path A and B
respectively. Each sub-procedure configure proper registers, and then
rigger one-shot calibration and poll until completion. For RX calibration,
it needs to do twice one-shot calibration, first one is to yield parameter
used by second one.
The result of TX part is stored for TX power tracking that adjusts TX AGC
to output expected power.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200512102621.5148-3-yhchuang@realtek.com
