ofdm_index[] is used to indicate how many power compensation is needed to
current thermal value. For internal PA module or 2.4G band, the min_index
is different from other cases.
This issue originally is reported by Dan. He found the size of ofdm_index[]
is 2, but access index 'i' may be equal to 2 if 'rf' is 2 in case of
'is2t'.
In fact, the chunk of code is added to wrong place, so move it back to
proper place, and then power compensation and buffer overflow are fixed.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201207031903.7599-1-pkshih@realtek.com
When 8822CE is associating with AP, driver will poll status bit of
IQ calibration to confirm the IQ calibration is done, and then move on
the association process. Current polling time for IQ calibration is 6
seconds.
But occasionally driver fails in polling the status bit because the status
bit is not set after IQ calibration is done. When it happends, association
process will be serieously delayed up to 6 seconds. To avoid it, we reduce
polling time to 300ms, in which the IQ calibration can be done.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201208014503.12118-1-pkshih@realtek.com
'const struct dev_pm_ops rtw_pm_ops' is declared by pci.c, and it should be
declare as 'extern' in pci.h. Without 'extern' causes every file including
pci.h has an individual instance of rtw_pm_ops but not reference to the one
declared in pci.c
If kernel config, like test robot, doesn't build driver as module, it leads
multiple definition.
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 2e86ef413a ("rtw88: pci: Add prototypes for .probe, .remove and .shutdown")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201208013746.11065-1-pkshih@realtek.com
When driver was developed, FCC regulation didn't enable channel 144
and there was no demand for channel 144 at that time. Although HW
actually supports channel 144, driver didn't announce channel 144.
Therefore, channel 144 (20 MHz), channel 142 (40 MHz) and channel
138 (80 MHz) couldn't be used.
Today, channel 144 has been enabled by regulations and
is gradually being supported. With test requirements,
we declare hw supports channel 144.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201204013823.3729-1-pkshih@realtek.com
Also strip out other duplicates from driver specific headers.
Ensure 'main.h' is explicitly included in 'pci.h' since the latter
uses some defines from the former. It avoids issues like:
from drivers/net/wireless/realtek/rtw88/rtw8822be.c:5:
drivers/net/wireless/realtek/rtw88/pci.h:209:28: error: ‘RTK_MAX_TX_QUEUE_NUM’ undeclared here (not in a function); did you mean ‘RTK_MAX_RX_DESC_NUM’?
209 | DECLARE_BITMAP(tx_queued, RTK_MAX_TX_QUEUE_NUM);
| ^~~~~~~~~~~~~~~~~~~~
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/realtek/rtw88/pci.c:1488:5: warning: no previous prototype for ‘rtw_pci_probe’ [-Wmissing-prototypes]
1488 | int rtw_pci_probe(struct pci_dev *pdev,
| ^~~~~~~~~~~~~
drivers/net/wireless/realtek/rtw88/pci.c:1568:6: warning: no previous prototype for ‘rtw_pci_remove’ [-Wmissing-prototypes]
1568 | void rtw_pci_remove(struct pci_dev *pdev)
| ^~~~~~~~~~~~~~
drivers/net/wireless/realtek/rtw88/pci.c:1590:6: warning: no previous prototype for ‘rtw_pci_shutdown’ [-Wmissing-prototypes]
1590 | void rtw_pci_shutdown(struct pci_dev *pdev)
| ^~~~~~~~~~~~~~~~
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201126133152.3211309-18-lee.jones@linaro.org
Kalle Valo says:
====================
wireless-drivers-next patches for v5.11
First set of patches for v5.11. rtw88 getting improvements to work
better with Bluetooth and other driver also getting some new features.
mhi-ath11k-immutable branch was pulled from mhi tree to avoid
conflicts with mhi tree.
Major changes:
rtw88
* major bluetooth co-existance improvements
wilc1000
* Wi-Fi Multimedia (WMM) support
ath11k
* Fast Initial Link Setup (FILS) discovery and unsolicited broadcast
probe response support
* qcom,ath11k-calibration-variant Device Tree setting
* cold boot calibration support
* new DFS region: JP
wnc36xx
* enable connection monitoring and keepalive in firmware
ath10k
* firmware IRAM recovery feature
mhi
* merge mhi-ath11k-immutable branch to make MHI API change go smoothly
* tag 'wireless-drivers-next-2020-12-03' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next: (180 commits)
wl1251: remove trailing semicolon in macro definition
airo: remove trailing semicolon in macro definition
wilc1000: added queue support for WMM
wilc1000: call complete() for failure in wilc_wlan_txq_add_cfg_pkt()
wilc1000: free resource in wilc_wlan_txq_add_mgmt_pkt() for failure path
wilc1000: free resource in wilc_wlan_txq_add_net_pkt() for failure path
wilc1000: added 'ndo_set_mac_address' callback support
brcmfmac: expose firmware config files through modinfo
wlcore: Switch to using the new API kobj_to_dev()
rtw88: coex: add feature to enhance HID coexistence performance
rtw88: coex: upgrade coexistence A2DP mechanism
rtw88: coex: add action for coexistence in hardware initial
rtw88: coex: add function to avoid cck lock
rtw88: coex: change the coexistence mechanism for WLAN connected
rtw88: coex: change the coexistence mechanism for HID
rtw88: coex: update AFH information while in free-run mode
rtw88: coex: update the mechanism for A2DP + PAN
rtw88: coex: add debug message
rtw88: coex: run coexistence when WLAN entering/leaving LPS
Revert "rtl8xxxu: Add Buffalo WI-U3-866D to list of supported devices"
...
====================
Link: https://lore.kernel.org/r/20201203185732.9CFA5C433ED@smtp.codeaurora.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Some AP will not follow the power save request, or it cannot stop
transmission until its queue is empty. It may bring the decreasing of
data rate.
WLAN firmware will count is the AP still leaked packet after power save
handshake was done or not to enable WLAN slot extend mechanism.
The extend WLAN slot mechanism will extend the WLAN slot after power save
handshake, 5 ms per times, maximum is 5 times to received the leaked packet
to avoid the rate lower down.
And if the transmission was already locked at CCK rate.
The extended WLAN slot can also increase the opportunity that we can
received the CCK's long packet and be released from CCK rate.
While BT multi-link status was finished, there is possible that it still
has some packet remained for seconds. Add a timer to remain the multi-link
mechanism to protect WLAN Rx.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201126021059.11981-8-pkshih@realtek.com
In rtl8723e_tx_fill_cmddesc(), skb->data is mapped to streaming DMA on
line 531:
dma_addr_t mapping = dma_map_single(..., skb->data, ...);
On line 534, skb->data is assigned to hdr after cast:
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)(skb->data);
Then hdr->frame_control is accessed on line 535:
__le16 fc = hdr->frame_control;
This DMA access may cause data inconsistency between CPU and hardwre.
To fix this bug, hdr->frame_control is accessed before the DMA mapping.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201119015218.12220-1-baijiaju1990@gmail.com
In rtl92de_tx_fill_cmddesc(), skb->data is mapped to streaming DMA on
line 667:
dma_addr_t mapping = dma_map_single(..., skb->data, ...);
On line 669, skb->data is assigned to hdr after cast:
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)(skb->data);
Then hdr->frame_control is accessed on line 670:
__le16 fc = hdr->frame_control;
This DMA access may cause data inconsistency between CPU and hardwre.
To fix this bug, hdr->frame_control is accessed before the DMA mapping.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201119015205.12162-1-baijiaju1990@gmail.com
In rtl92ce_tx_fill_cmddesc(), skb->data is mapped to streaming DMA on
line 530:
dma_addr_t mapping = dma_map_single(..., skb->data, ...);
On line 533, skb->data is assigned to hdr after cast:
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)(skb->data);
Then hdr->frame_control is accessed on line 534:
__le16 fc = hdr->frame_control;
This DMA access may cause data inconsistency between CPU and hardwre.
To fix this bug, hdr->frame_control is accessed before the DMA mapping.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201119015151.12110-1-baijiaju1990@gmail.com
In rtl88ee_tx_fill_cmddesc(), skb->data is mapped to streaming DMA on
line 677:
dma_addr_t mapping = dma_map_single(..., skb->data, ...);
On line 680, skb->data is assigned to hdr after cast:
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)(skb->data);
Then hdr->frame_control is accessed on line 681:
__le16 fc = hdr->frame_control;
This DMA access may cause data inconsistency between CPU and hardwre.
To fix this bug, hdr->frame_control is accessed before the DMA mapping.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201119015127.12033-1-baijiaju1990@gmail.com
Remove extend 5 ms related operation at WLAN media status notify.
The mechanism should be enable only while DUT connect to a AP that it
doesn't follow our power save control or its rate is decreasing unusually
sensitive. So we extend a extra slot to save the transmission rate.
The original logic will always extend WLAN slot.
It will lead to BT slot always decrease 5 ms.
Remove write scoreboard action at WLAN media status notify.
It has already done in WLAN info notify.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201112031430.4846-11-pkshih@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 8723d.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201109090123.9254-1-pkshih@realtek.com
Life time related setting is related to WLAN active port number,
not its mode. The original setting may cause poor WLAN performance.
In most case, WLAN TX limitation is helpful for BT in coexistence
scenario, especially for A2DP quality.
So this is necessary to fix the setting and constraint it.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201109085909.9143-12-pkshih@realtek.com
Add counter to count BT info C2H command for debug usage.
It could present the C2H channel situation.
Fix BT IQK state decision condition for counting.
The original condition is wrong, it would cause coexistence mechanism
going to the wrong strategy.
New format supports getting TDMA parameter from WL firmware, since
coexistence needs current TDMA parameter to decide strategy.
Remove unnecessary operations about scoreboard, it is not a must for
current version.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201109085909.9143-8-pkshih@realtek.com
