summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek
AgeCommit message (Collapse)AuthorFilesLines
2019-11-20rtw88: pci: use for loop instead of while loop for DBI/MDIOYan-Hsuan Chuang1-12/+14
Use a for loop to polling DBI/MDIO read/write flags to avoid infinite loop happens Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-11-20rtw88: pci: use macros to access PCI DBI/MDIO registersYan-Hsuan Chuang2-11/+20
Add some register and bit macros to access DBI/MDIO register. This should not change the logic. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-11-20rtlwifi: set proper udelay within rf_serial_readPing-Ke Shih3-7/+4
Since read RF register is an indirect access that hardware needs time to accomplish read action, but there's no ready bit, so delay is required to guarantee the read value is correct. After investigating internal documents, these delays are reduced as proper values. Reported-by: Lucas Stach <dev@lynxeye.de> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-11-20rtlwifi: rf_lock use non-irqsave spin_lockPing-Ke Shih6-36/+24
rf_lock is used to protect RF register access, but they will not called from interrupt context, so *_irqsave version isn't necessary. Then, these delays don't affect IRQ services. The old code holds spin_lock_irqsave() that will be detected a long delay as below: kworker/-276 4d... 0us : _raw_spin_lock_irqsave kworker/-276 4d... 0us : rtl8723_phy_rf_serial_read <-rtl8723de_phy_set_rf_reg kworker/-276 4d... 1us : rtl8723_phy_query_bb_reg <-rtl8723_phy_rf_serial_read kworker/-276 4d... 3us : rtl8723_phy_set_bb_reg <-rtl8723_phy_rf_serial_read kworker/-276 4d... 4us : __const_udelay <-rtl8723_phy_rf_serial_read kworker/-276 4d... 4us!: delay_mwaitx <-rtl8723_phy_rf_serial_read kworker/-276 4d... 1004us : rtl8723_phy_set_bb_reg <-rtl8723_phy_rf_serial_read [...] Reported-by: Lucas Stach <dev@lynxeye.de> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-11-15rtw88: remove duplicated include from ps.cYueHaibing1-1/+0
Remove duplicated include. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-11-15rtl8xxxu: Remove set but not used variable 'rsr'Zheng Yongjun1-2/+1
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c: In function rtl8xxxu_gen2_config_channel: drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:1266:13: warning: variable rsr set but not used [-Wunused-but-set-variable] rsr is never used, so remove it. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-11-14rtl8xxxu: Add support for Edimax EW-7611ULBJes Sorensen1-1/+3
A number of people have reported the Edimax EW-7611ULB works fine. Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-11-14rtlwifi: rtl8192de: Fix missing enable interrupt flagLarry Finger1-4/+5
In commit 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers"), the flag that indicates that interrupts are enabled was never set. In addition, there are several places when enable/disable interrupts were commented out are restored. A sychronize_interrupts() call is removed. Fixes: 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers") Cc: Stable <stable@vger.kernel.org> # v3.18+ Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-11-14rtlwifi: rtl8192de: Fix missing callback that tests for hw release of bufferLarry Finger3-0/+20
In commit 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers"), a callback needed to check if the hardware has released a buffer indicating that a DMA operation is completed was not added. Fixes: 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers") Cc: Stable <stable@vger.kernel.org> # v3.18+ Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-11-14rtlwifi: rtl8192de: Fix missing code to retrieve RX buffer addressLarry Finger1-3/+5
In commit 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers"), a callback to get the RX buffer address was added to the PCI driver. Unfortunately, driver rtl8192de was not modified appropriately and the code runs into a WARN_ONCE() call. The use of an incorrect array is also fixed. Fixes: 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers") Cc: Stable <stable@vger.kernel.org> # 3.18+ Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-11-08rtw88: signal completion even on firmware-request failureBrian Norris1-0/+1
Otherwise, the waiters (e.g., "modprobe rtwpci") will block forever. Fixes: f530c1961af2 ("rtw88: fix potential NULL pointer access for firmware") Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Brian Norris <briannorris@chromium.org> Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-11-06rtw88: fix potential NULL pointer access for firmwareYan-Hsuan Chuang1-1/+3
Driver could access a NULL firmware pointer if we don't return here. Fixes: 5195b90426409 ("rtw88: avoid FW info flood") Reported-by: kbuild test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-11-06rtlwifi: fix memory leak in rtl92c_set_fw_rsvdpagepkt()Ping-Ke Shih1-0/+2
This leak was found by testing the EDIMAX EW-7612 on Raspberry Pi 3B+ with Linux 5.4-rc5 (multi_v7_defconfig + rtlwifi + kmemleak) and noticed a single memory leak during probe: unreferenced object 0xec13ee40 (size 176): comm "kworker/u8:1", pid 36, jiffies 4294939321 (age 5580.790s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<fc1bbb3e>] __netdev_alloc_skb+0x9c/0x164 [<863dfa6e>] rtl92c_set_fw_rsvdpagepkt+0x254/0x340 [rtl8192c_common] [<9572be0d>] rtl92cu_set_hw_reg+0xf48/0xfa4 [rtl8192cu] [<116df4d8>] rtl_op_bss_info_changed+0x234/0x96c [rtlwifi] [<8933575f>] ieee80211_bss_info_change_notify+0xb8/0x264 [mac80211] [<d4061e86>] ieee80211_assoc_success+0x934/0x1798 [mac80211] [<e55adb56>] ieee80211_rx_mgmt_assoc_resp+0x174/0x314 [mac80211] [<5974629e>] ieee80211_sta_rx_queued_mgmt+0x3f4/0x7f0 [mac80211] [<d91091c6>] ieee80211_iface_work+0x208/0x318 [mac80211] [<ac5fcae4>] process_one_work+0x22c/0x564 [<f5e6d3b6>] worker_thread+0x44/0x5d8 [<82c7b073>] kthread+0x150/0x154 [<b43e1b7d>] ret_from_fork+0x14/0x2c [<794dff30>] 0x0 It is because 8192cu doesn't implement usb_cmd_send_packet(), and this patch just frees the skb within the function to resolve memleak problem by now. Since 8192cu doesn't turn on fwctrl_lps that needs to download command packet for firmware via the function, applying this patch doesn't affect driver behavior. Reported-by: Stefan Wahren <wahrenst@gmx.net> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-11-06rtlwifi: rtl8225se: remove some unused const variablesYueHaibing1-42/+0
drivers/net/wireless//realtek/rtl818x/rtl8180/rtl8225se.c:83:17: warning: 'rtl8225sez2_tx_power_cck' defined but not used [-Wunused-const-variable=] drivers/net/wireless//realtek/rtl818x/rtl8180/rtl8225se.c:79:17: warning: 'rtl8225sez2_tx_power_cck_A' defined but not used [-Wunused-const-variable=] drivers/net/wireless//realtek/rtl818x/rtl8180/rtl8225se.c:75:17: warning: 'rtl8225sez2_tx_power_cck_B' defined but not used [-Wunused-const-variable=] drivers/net/wireless//realtek/rtl818x/rtl8180/rtl8225se.c:71:17: warning: 'rtl8225sez2_tx_power_cck_ch14' defined but not used [-Wunused-const-variable=] drivers/net/wireless//realtek/rtl818x/rtl8180/rtl8225se.c:62:17: warning: 'rtl8225se_tx_power_ofdm' defined but not used [-Wunused-const-variable=] drivers/net/wireless//realtek/rtl818x/rtl8180/rtl8225se.c:53:17: warning: 'rtl8225se_tx_power_cck_ch14' defined but not used [-Wunused-const-variable=] drivers/net/wireless//realtek/rtl818x/rtl8180/rtl8225se.c:44:17: warning: 'rtl8225se_tx_power_cck' defined but not used [-Wunused-const-variable=] drivers/net/wireless//realtek/rtl818x/rtl8180/rtl8225se.c:40:17: warning: 'rtl8225se_tx_gain_cck_ofdm' defined but not used [-Wunused-const-variable=] They are never used, so can be removed. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-11-06rtw88: raise LPS threshold to 50, for less power consumptionYan-Hsuan Chuang1-1/+1
The LPS threshold was set to 2, means driver will leave LPS mode if there is more than 2 frames TX/RX for every 2 seconds. This makes driver enter/leave LPS frequently even if we just "ping -i1" to the others. Apparently we do not want to leave LPS mode if there is only some background traffics or web surfing. By experiment, set this to 50 is a more reasonable value to lower the over all power consumption. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-11-06Merge tag 'wireless-drivers-next-2019-11-05' of ↵David S. Miller58-1098/+5064
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 5.5 First set of patches for 5.5. The most active driver here clearly is rtw88, lots of patches for it. More quiet on other drivers, smaller fixes and cleanups all over. This pull request also has a trivial conflict, the report and example resolution here: https://lkml.kernel.org/r/20191031111242.50ab1eca@canb.auug.org.au Major changes: rtw88 * add deep power save support * add mac80211 software tx queue (wake_tx_queue) support * enable hardware rate control * add TX-AMSDU support * add NL80211_EXT_FEATURE_CAN_REPLACE_PTK0 support * add power tracking support * add 802.11ac beamformee support * add set_bitrate_mask support * add phy_info debugfs to show Tx/Rx physical status * add RFE type 3 support for 8822b ath10k * add support for hardware rfkill on devices where firmware supports it rtl8xxxu * add bluetooth co-existence support for single antenna iwlwifi * Revamp the debugging infrastructure ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-02Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller2-1/+8
The only slightly tricky merge conflict was the netdevsim because the mutex locking fix overlapped a lot of driver reload reorganization. The rest were (relatively) trivial in nature. Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-31rtlwifi: rtl8821ae: Drop condition with no effectSaurav Girepunje1-2/+0
As the "else if" and "else" branch body are identical the condition has no effect. So drop the "else if" condition. Signed-off-by: Saurav Girepunje <saurav.girepunje@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-31rtlwifi: rtl8192c: Drop condition with no effectSaurav Girepunje1-2/+0
As the "else if" and "else" branch body are identical the condition has no effect. So drop the "else if" condition. Signed-off-by: Saurav Girepunje <saurav.girepunje@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-31rtw88: remove redundant null pointer check on arraysColin Ian King1-1/+1
The checks to see if swing_table->n or swing_table->p are null are redundant since n and p are arrays and can never be null if swing_table is non-null. I believe these are redundant checks and can be safely removed, especially the checks implies that these are not arrays which can lead to confusion. Addresses-Coverity: ("Array compared against 0") Fixes: c97ee3e0bea2 ("rtw88: add power tracking support") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-31rtw88: avoid FW info floodYan-Hsuan Chuang2-17/+10
The FW info was printed everytime driver is powered on, such as leaving IDLE state. It will flood the kernel log. Move the FW info printing to callback when FW is loaded, so that will only be printed once when device is probed. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-31rtw88: fix potential read outside array boundaryTzu-En Huang3-11/+19
The level of cckpd is from 0 to 4, and it is the index of array pd_lvl[] and cs_lvl[]. However, the length of both arrays are 4, which is smaller than the possible maximum input index. Enumerate cck level to make sure the max level will not be wrong if new level is added in future. Fixes: 479c4ee931a6 ("rtw88: add dynamic cck pd mechanism") 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>
2019-10-31rtw88: rearrange if..else statements for rx rate indexesYan-Hsuan Chuang1-8/+6
Driver just memset() rx_status to 0 before assigning rate indexes. And driver could never hit the 'else' because the driver checks if 'pkt_stat->rate >= DESC_RATEMCS0', so the 'else' statement can be removed. Also rearrange the if..else statements because DESC_RATEMCS0 is actually larger than DESC_RATE1M ~ DESC_RATE54M, move the check of 'pkt_stat->rate >= DESC_RATEMCS0' to the last to keep an increasing order. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-31rtw88: use rtw_phy_pg_cfg_pair struct, not arraysYan-Hsuan Chuang4-202/+199
Use proper struct for BB PG tables. TODO: we need to find a way to store the tables that have condition values. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-31rtw88: 8822b: add RFE type 3 supportYan-Hsuan Chuang3-1/+647
Some of the modules use RFE type 3, add corresponding tables for them. Tested-by: G.schlmm <g.schlmm@googlemail.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-31rtw88: fix sparse warnings for power trackingYan-Hsuan Chuang2-2/+2
sparse warnings: drivers/net/wireless/realtek/rtw88/rtw8822b.c:1440:6: sparse: sparse: symbol 'rtw8822b_pwr_track' was not declared. Should it be static? drivers/net/wireless/realtek/rtw88/rtw8822c.c:1008:6: sparse: sparse: symbol 'rtw8822c_pwrtrack_init' was not declared. Should it be static? Fixes: c97ee3e0bea2 ("rtw88: add power tracking support") 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>
2019-10-31rtw88: fix sparse warnings for DPKYan-Hsuan Chuang1-2/+2
sparse warnings: drivers/net/wireless/realtek/rtw88/rtw8822c.c:2871:6: sparse: sparse: symbol 'rtw8822c_dpk_cal_coef1' was not declared. Should it be static? drivers/net/wireless/realtek/rtw88/rtw8822c.c:3112:6: sparse: sparse: symbol 'rtw8822c_dpk_track' was not declared. Should it be static? Fixes: 5227c2ee453d ("rtw88: 8822c: add SW DPK support") 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>
2019-10-28net: Fix various misspellings of "connect"Geert Uytterhoeven1-2/+2
Fix misspellings of "disconnect", "disconnecting", "connections", and "disconnected". Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Kalle Valo <kvalo@codeaurora.org> Acked-by: Simon Horman <horms@verge.net.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-25rtw88: fix GENMASK_ULL for u64Yan-Hsuan Chuang1-1/+1
This fixes compile warning: In file included from include/linux/bitops.h:5:0, from include/linux/kernel.h:12, from include/asm-generic/bug.h:19, from arch/mips/include/asm/bug.h:42, from include/linux/bug.h:5, from include/net/mac80211.h:16, from drivers/net/wireless/realtek/rtw88/main.h:8, from drivers/net/wireless/realtek/rtw88/main.c:5: drivers/net/wireless/realtek/rtw88/main.c: In function 'rtw_update_rate_mask': include/linux/bits.h:23:11: warning: right shift count is negative [-Wshift-count-negative] (~UL(0) >> (BITS_PER_LONG - 1 - (h)))) ^ drivers/net/wireless/realtek/rtw88/main.c:622:17: note: in expansion of macro 'GENMASK' u64 cfg_mask = GENMASK(63, 0); ^~~~~~~ Reported-by: kbuild test robot <lkp@intel.com> Fixes: f39e9bd49a3d ("rtw88: add set_bitrate_mask support") Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-24rtl8xxxu: fix warnings for symbol not declaredChris Chiu1-0/+4
Fix the following sparse warnings. sparse: symbol 'rtl8723bu_set_coex_with_type' was not declared. Should it be static? sparse: symbol 'rtl8723bu_update_bt_link_info' was not declared. Should it be static? sparse: symbol 'rtl8723bu_handle_bt_inquiry' was not declared. Should it be static? sparse: symbol 'rtl8723bu_handle_bt_info' was not declared. Should it be static? Signed-off-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-24rtl8xxxu: remove set but not used variable 'rate_mask'YueHaibing1-5/+0
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:4484:6: warning: variable rate_mask set but not used [-Wunused-but-set-variable] It is never used since commit a9bb0b515778 ("rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-24rtlwifi: Remove unnecessary NULL check in rtl_regd_initNathan Chancellor1-1/+1
When building with Clang + -Wtautological-pointer-compare: drivers/net/wireless/realtek/rtlwifi/regd.c:389:33: warning: comparison of address of 'rtlpriv->regd' equal to a null pointer is always false [-Wtautological-pointer-compare] if (wiphy == NULL || &rtlpriv->regd == NULL) ~~~~~~~~~^~~~ ~~~~ 1 warning generated. The address of an array member is never NULL unless it is the first struct member so remove the unnecessary check. This was addressed in the staging version of the driver in commit f986978b32b3 ("Staging: rtlwifi: remove unnecessary NULL check"). While we are here, fix the following checkpatch warning: CHECK: Comparison to NULL could be written "!wiphy" 35: FILE: drivers/net/wireless/realtek/rtlwifi/regd.c:389: + if (wiphy == NULL) Fixes: 0c8173385e54 ("rtl8192ce: Add new driver") Link:https://github.com/ClangBuiltLinux/linux/issues/750 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-24rtw88: add phy_info debugfs to show Tx/Rx physical statusTsang-Shian Lin9-33/+431
This commit adds several Tx/Rx physical information to phy_info debugfs for 8822B/8822C. By this debugfs, we can know physical information, such as Tx/Rx rate, RSSI, EVM,SNR, etc. The information is gotten from the packets of Tx/Rx path. It has no impact for the performance of 8822B/8822C. In the fields, we may meet different kinds of problems, but we may have no professional instrument to check them. At this moment, this debugfs is a good tool, and it may provide useful information for debug. Signed-off-by: Tsang-Shian Lin <thlin@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-24rtw88: add set_bitrate_mask supportTzu-En Huang3-16/+118
Support setting bit rate from upper layer. After configuring the original rate control result in the driver, the result is then masked by the bit rate mask received from the ops set_bitrate_mask. Lastly, the masked result will be sent to firmware. Signed-off-by: Tzu-En Huang <tehuang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-24rtw88: Enable 802.11ac beamformee supportTzu-En Huang10-0/+692
Enable MU-MIMO transmit beamformee support for chipset 8822b and 8822c. If the driver is in station mode and associated with an AP, and the capabilities of both meet the requirement of beamforming, driver will run as a beamformee and the corresponding chip settings will be set. In addition, module parameter support_bf is added to enable or disable beamforming. Sometimes driver will need to disable for inter-operate issues, and it would be easier for driver to debug. 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>
2019-10-24rtw88: add power tracking supportTzu-En Huang6-1/+745
The temperature of the chip can affect the output power of the RF components. Hence driver requires to compensate the power by adjusting the power index recorded in the power swing table. And if the difference of current thermal value to the default thermal value exceeds a threshold, the RF IQK should be triggered to re-calibrate the characteristics of the RF components, to keep the output IQ vectors of the RF components orthogonal enough. Signed-off-by: Tzu-En Huang <tehuang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-24rtw88: use macro to check the current bandYan-Hsuan Chuang5-32/+41
Add macros to see which band we are, based on the current channel. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-23rtlwifi: rtl_pci: Fix problem of too small skb->lenLarry Finger1-1/+2
In commit 8020919a9b99 ("mac80211: Properly handle SKB with radiotap only"), buffers whose length is too short cause a WARN_ON(1) to be executed. This change exposed a fault in rtlwifi drivers, which is fixed by regarding packets with skb->len <= FCS_LEN as though they are in error and dropping them. The test is now annotated as likely. Cc: Stable <stable@vger.kernel.org> # v5.0+ Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-23rtlwifi: Fix potential overflow on P2P codeLaura Abbott1-0/+6
Nicolas Waisman noticed that even though noa_len is checked for a compatible length it's still possible to overrun the buffers of p2pinfo since there's no check on the upper bound of noa_num. Bound noa_num against P2P_MAX_NOA_NUM. Reported-by: Nicolas Waisman <nico@semmle.com> Signed-off-by: Laura Abbott <labbott@redhat.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-22rtl8xxxu: fix RTL8723BU connection failure issue after warm rebootChris Chiu3-0/+5
The RTL8723BU has problems connecting to AP after each warm reboot. Sometimes it returns no scan result, and in most cases, it fails the authentication for unknown reason. However, it works totally fine after cold reboot. Compare the value of register SYS_CR and SYS_CLK_MAC_CLK_ENABLE for cold reboot and warm reboot, the registers imply that the MAC is already powered and thus some procedures are skipped during driver initialization. Double checked the vendor driver, it reads the SYS_CR and SYS_CLK_MAC_CLK_ENABLE also but doesn't skip any during initialization based on them. This commit only tells the RTL8723BU to do full initialization without checking MAC status. Signed-off-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-16rtw88: mark rtw_fw_hdr __packedBrian Norris1-1/+1
The use of u8 and __le16 in this struct assumes that it's going to be packed to byte alignment. C doesn't guarantee that, so we should mark this __packed. Fixes: cc20a7139836 ("rtw88: use struct rtw_fw_hdr to access firmware header") Cc: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-14rtw88: include interrupt.h for tasklet_structBrian Norris1-0/+1
Depending on implicit header includes, we might see this compilation error: .../main.h:1391:24: error: field has incomplete type 'struct tasklet_struct' struct tasklet_struct tx_tasklet; ^ Fixes: 3745d3e550d1 ("rtw88: add driver TX queue support") Signed-off-by: Brian Norris <briannorris@chromium.org> Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-14rtw88: use a for loop in rtw_power_mode_change(), not gotoBrian Norris1-32/+29
No change in logic. Signed-off-by: Brian Norris <briannorris@chromium.org> Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-14rtw88: coex: Set 4 slot mode for A2DPPing-Ke Shih1-9/+15
With shallow buffer size, certain BT devices have active A2DP flow control to fill buffer frequently. If the slot is not at BT side, data can't be sent successfully to BT devices, and will cause audio glitch. To resolve this issue, this commit splits TUs into 4-slots instead of 2-slot for all of the A2DP related coexistence strategies. That makes BT have higher opportunity to fill the A2DP buffer in time, and the audio quality could be more stable and smooth. 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>
2019-10-14rtw88: pci: config phy after chip info is setupYan-Hsuan Chuang1-2/+2
Chip info such as cut_version is required to configure PCI phy. Move rtw_pci_phy_config after rtw_chip_info_setup. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-14rtw88: Use rtw_write8_set to set SYS_FUNCYan-Hsuan Chuang1-1/+1
rtw_write8 could modify the values that we do not want to change, use rtw_write8_set instead to only enable the bits of sys_func_en Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-14rtw88: add NL80211_EXT_FEATURE_CAN_REPLACE_PTK0 supportTzu-En Huang3-0/+8
Add support for NL80211_EXT_FEATURE_CAN_REPLACE_PTK0 feature. According to the "Hardware crypto acceleration" documentation section, when set_key() is called with %DISABLE_KEY command, for outgoing frames, we flush out frames in the queues with the old key; for incoming frames, no frames will be passed to mac80211 decrypted with the old key due to rtw_sec_clear_cam(). 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>
2019-10-14rtw88: config 8822c multicast address in MAC init flowTzu-En Huang2-0/+4
Multicast address should be congiured in the initialization flow. The value is created by a hashed calculation that is also implemented by the hardware for multicast address filtering. 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>
2019-10-11rtlwifi: rtl8192se: Convert inline routines to little-endian wordsLarry Finger2-118/+122
In this step, the read/write routines for the descriptors are converted to use __le32 quantities, thus a lot of casts can be removed. Callback routines still use the 8-bit arrays, but these are changed within the specified routine. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-11rtlwifi: rtl8192se: Convert macros that set descriptorLarry Finger2-194/+341
As a first step in the conversion, the macros that set the RX and TX descriptors are converted to static inline routines, and the names are changed from upper to lower case. To minimize the changes in a given step, the input descriptor information is left as as a byte array (u8 *), even though it should be a little-endian word array (__le32 *). That will be changed in the next patch. Several places where checkpatch.pl complains about a space after a cast and other warnings are fixed. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>