summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek
AgeCommit message (Collapse)Author
2020-04-24mac80211: populate debugfs only after cfg80211 initJohannes Berg
When fixing the initialization race, we neglected to account for the fact that debugfs is initialized in wiphy_register(), and some debugfs things went missing (or rather were rerooted to the global debugfs root). Fix this by adding debugfs entries only after wiphy_register(). This requires some changes in the rate control code since it currently adds debugfs at alloc time, which can no longer be done after the reordering. Reported-by: Jouni Malinen <j@w1.fi> Reported-by: kernel test robot <rong.a.chen@intel.com> Reported-by: Hauke Mehrtens <hauke@hauke-m.de> Reported-by: Felix Fietkau <nbd@nbd.name> Cc: stable@vger.kernel.org Fixes: 52e04b4ce5d0 ("mac80211: fix race in ieee80211_register_hw()") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Acked-by: Sumit Garg <sumit.garg@linaro.org> Link: https://lore.kernel.org/r/20200423111344.0e00d3346f12.Iadc76a03a55093d94391fc672e996a458702875d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-04-23rtw88: 8723d: initialize mac/bb/rf basic functionsPing-Ke Shih
Implement rtw_chip_ops::phy_set_param and ::mac_init to initialize mac/bb/rf, and they are used during interface up. The procedure contains power on sequence registers, download firmware, load predefined parameters, mac/bb/rf specific register and etc. 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/20200422034607.28747-9-yhchuang@realtek.com
2020-04-23rtw88: 8723d: Organize chip TX/RX FIFOPing-Ke Shih
TX FIFO size is 32k and it was divided into 256 pages with 128 bytes. A boundary is used to split pages into two parts, head part is used to store TX packets coming from host, and tail part is reserved for special purposes, such as beacon packet, null data packet and so on. The TX packets coming from host have many categories, such as VO, VI, BE, BK, MG and etc. When going into head part of TX FIFO, they are classified to four priority queue named low, normal, high and extra priority queues. Each priority queue occupies predefined number of page, if a certain priority queue is full, TX packet will store into PUB priority queue. Similarly, RX FIFO is 16k and split into two parts, head part is used to store RX packets, and tail part is 128 bytes and used to store report. Thus, we fill this boundary to register as well. 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/20200422034607.28747-8-yhchuang@realtek.com
2020-04-23rtw88: 8723d: implement set_tx_power_index opsPing-Ke Shih
The txagc table is used to map rate_id and txagc register address and mask, and ops set_tx_power_index uses this table to write TX power to corresponding registers. Since 8723D is a 1x1 2.4G 11n chip, only CCK, OFDM and HT_MCS 0-7 are listed in the table. 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/20200422034607.28747-7-yhchuang@realtek.com
2020-04-23rtw88: 8723d: 11N chips don't support H2C queuePing-Ke Shih
H2C queue is used to send command to firmware. Since 8723D doesn't support this queue, this commit check wlan_cpu flag to avoid to set H2C related registers. 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/20200422034607.28747-6-yhchuang@realtek.com
2020-04-23rtw88: decompose while(1) loop of power sequence polling commandPing-Ke Shih
The power polling command is one kind of power sequence commands. It's used to check hardware situation, and subsequent comamnds will be executed if hardware is ready. A special case is PCIE must toggle BIT_PFM_WOWL and try again if first try is failed. In order to reduce indentation to understand the code easier, move polling part to a separate function. Then, the 'while (1)...loop' is replaced by two statements to do first try and retry. 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/20200422034607.28747-5-yhchuang@realtek.com
2020-04-23rtw88: 8723d: Add mac power-on/-off functionPing-Ke Shih
The mac power-on flow consists of three steps: 1. pre_sys_cfg (Before switching power state) 2. power_switch (Switching power state) 3. init_sys_cfg (Settings after swtiching power state) When switching power state, driver will load and parse the power sequence tables. For 8723D devices, the logics for parsing are most same except for the polling function. 8723D devices need to toggle BIT_PFM_WOWL twice. The settings after power state is switched for 8723D devices are quite different with other devices, extract a legacy function for them. For power-off flow, 8723D devices have the same logic with existing chips. But warning printed if we run power-off sequence in power-off state: rtw_pci 0000:03:00.0: failed to poll offset=0x5f8 mask=0xff value=0x0 The scenario is user do 'ifconfig up' that will run power-on sequence to bring up and then run power-off sequence to enter idle (IEEE80211_CONF_IDLE). Then, user do 'ifconfig down' that will run power-off sequence again, and the warning is shown. Original code check power-on state to avoid to run power-on sequence twice, and this commit extends to check both power-on and power-off states. 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/20200422034607.28747-4-yhchuang@realtek.com
2020-04-23rtw88: no need to send additional information to legacy firmwarePing-Ke Shih
The firmware of 11AC devices need more information to support more offload functions, such as IQK. And 11N devices such as 8723D does not support offload these function in firmware, there is no need to send these additional information to firmware when it comes to 11N devices. 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/20200422034607.28747-3-yhchuang@realtek.com
2020-04-23rtw88: add legacy firmware download for 8723D devicesPing-Ke Shih
The WLAN CPU of 8723D device is different from others, add legacy firmware download function for it. A new variable wlan_cpu is used to decide which firmware download function we should use. Legacy firmware file contains 32 bytes header including version and subversion. When downloading to wlan cpu, header is excluded. Firmware is downloaded via beacon queue to reserved page that is a part of TX buffer. Since 11N WLAN CPU uses different control registers, this patch introduces related control registers. 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/20200422034607.28747-2-yhchuang@realtek.com
2020-04-21rtw88: set power trim according to efuse PG valuesTzu-En Huang
8822C devices have power trim, thermal and PA bias values programmed in efuse. Driver should configure the RF components according to the values. If the power trim is not configured, then the devices might have distortion on the output tx power. 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/20200420105207.31899-1-yhchuang@realtek.com
2020-04-21rtw88: 8723d: Add read_efuse to recognize efuse info from mapPing-Ke Shih
The logical efuse map is decoded from physical map by parsing the header format of the physical map. And each different type of chips has different logical efuse layout. So add the logical map's layout for parsing the efuse contents. 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/20200420055054.14592-9-yhchuang@realtek.com
2020-04-21rtw88: 8723d: Add new chip op efuse_grant() to control efuse accessPing-Ke Shih
8723D devices need to grant efuse access before dumping physical efuse map, other chips don't need it, so keep this ops as blank. 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/20200420055054.14592-8-yhchuang@realtek.com
2020-04-21rtw88: 8723d: Add cfg_ldo25 to control LDO25Ping-Ke Shih
Implement rtw_chip_ops::cfg_ldo25 to enable/disable LDO25 with proper voltage. 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/20200420055054.14592-7-yhchuang@realtek.com
2020-04-21rtw88: 8723d: Add mac/bb/rf/agc/power_limit tablesPing-Ke Shih
Add corresponding parameter tables for 8723D devices. Since 8723D devices currently have only one RFE type, there is only one entry in rtw8723d_rfe_defs. 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/20200420055054.14592-6-yhchuang@realtek.com
2020-04-21rtw88: 8723d: Add RF read/write opsPing-Ke Shih
8723D use SIPI to indirectly read RF register instead of directly read, so introduce a new struct rtw_rf_sipi_addr and new function rtw_phy_read_rf_sipi(). Since other chips don't use the new function, only 8723D needs to fill struct rtw_rf_sipi_addr in rtw_chip_info. Because there are two kinds of functions for reading RF registers now, change rtw_phy_read_rf() to chip->ops->read_rf() in rtw_phy_write_rf_reg_sipi() so that we can switch tp proper RF read functions depends on the type of the chip. Though 8723D is an 1x1 chip, it has two RF PHY and we can switch to one of them, and that should be configured properly. Hence, add a fix_rf_phy_num to struct rtw_chip_info to allow driver to set one of the PHY's registers for 8723D, even it is only 1x1. Another variable rf_phy_num is introduced to keep the constraint number of RF path we can access, and its value is: rf_phy_num = (fix_rf_phy_num ? fix_rf_phy_num : rf_path_num) Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> 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/20200420055054.14592-5-yhchuang@realtek.com
2020-04-21rtw88: 8723d: Add power sequencePing-Ke Shih
Add corresponding power sequence for 8723D devices 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/20200420055054.14592-4-yhchuang@realtek.com
2020-04-21rtw88: 8723d: add beamform wrapper functionsPing-Ke Shih
8723D doesn't support beamform because rtw88 only supports VHT beamform but 8723d doesn't have VHT capability. Though 8723d doesn't support beamform, BSS_CHANGED_MU_GROUPS is still marked as changed when doing disassociation. So, add wrapper functions for all beamform ops to make sure they aren't NULL before calling. 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/20200420055054.14592-3-yhchuang@realtek.com
2020-04-21rtw88: 8723d: Add basic chip capabilitiesPing-Ke Shih
RTL8723DE is an 11n 1x1 2.4G single band chip with the following capabilities: - TX/RX BD size: 16/8 - TX/RX desc size: 40/24 - physical/logical/protected efuse size: 512/512/96 - TX gain index factor: 1 - max TX power index: 0x3F - band: 2G - HT: support - VHT: Not support 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/20200420055054.14592-2-yhchuang@realtek.com
2020-04-21rtlwifi: rtl8723ae: fix warning comparison to boolJason Yan
Fix the following coccicheck warning: drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c:617:14-20: WARNING: Comparison to bool drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c:622:13-19: WARNING: Comparison to bool drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c:627:14-20: WARNING: Comparison to bool drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c:632:13-19: WARNING: Comparison to bool drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c:937:5-13: WARNING: Comparison to bool Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200420042658.18733-1-yanaijie@huawei.com
2020-04-21rtlwifi: rtl8821ae: use true,false for bool variablesJason Yan
Fix the following coccicheck warning: drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c:79:1-34: WARNING: Assignment of 0/1 to bool variable drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c:81:1-34: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200418070236.9620-6-yanaijie@huawei.com
2020-04-21rtlwifi: rtl8723be: use true,false for bool variablesJason Yan
Fix the following coccicheck warning: drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c:77:1-34: WARNING: Assignment of 0/1 to bool variable drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c:79:1-34: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200418070236.9620-5-yanaijie@huawei.com
2020-04-21rtlwifi: rtl8192ee: use true,false for bool variablesJason Yan
Fix the following coccicheck warning: drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c:78:1-34: WARNING: Assignment of 0/1 to bool variable drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c:80:1-34: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200418070236.9620-4-yanaijie@huawei.com
2020-04-21rtlwifi: rtl8723ae: use true,false for bool variablesJason Yan
Fix the following coccicheck warning: drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c:81:1-34: WARNING: Assignment of 0/1 to bool variable drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c:83:1-34: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200418070236.9620-3-yanaijie@huawei.com
2020-04-21rtlwifi: rtl8188ee: use true,false for bool variablesJason Yan
Fix the following coccicheck warning: drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c:70:1-34: WARNING: Assignment of 0/1 to bool variable drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c:72:1-34: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200418070236.9620-2-yanaijie@huawei.com
2020-04-15rtw88: add support for set/get antennasYan-Hsuan Chuang
User space program such as iw can set antenna mask for the device. So add set antenna support by configure the trx mode. This is useful for some tests want to see the output of different antenna configuration (e.g. path A v.s. path B). Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200410100950.3199-3-yhchuang@realtek.com
2020-04-15rtw88: make rtw_chip_ops::set_antenna return intYan-Hsuan Chuang
To support ieee80211_ops::set_antenna, the driver can decide if the antenna mask is accepted, otherwise it can return an error code. Because each chip could have different limitations, let the chip check the mask and return. Also the antenna mask for TRX from upper space is 32-bit long. Change the antenna mask for rtw_chip_ops::set_antenna from u8 to u32. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200410100950.3199-2-yhchuang@realtek.com
2020-04-14rtw88: Add delay on polling h2c command status bitKai-Heng Feng
On some systems we can constanly see rtw88 complains: [39584.721375] rtw_pci 0000:03:00.0: failed to send h2c command Increase interval of each check to wait the status bit really changed. Use read_poll_timeout() macro which fits anything we need here. Suggested-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200407073331.397-1-kai.heng.feng@canonical.com
2020-04-14rtlwifi: rtl8723ae: fix spelling mistake "chang" -> "change"Qiujun Huang
There is a spelling mistake in a trace message. Fix it. Signed-off-by: Qiujun Huang <hqjagain@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1585815557-20212-1-git-send-email-hqjagain@gmail.com
2020-04-14rtw88: Make two functions staticYueHaibing
Fix sparse warnings: drivers/net/wireless/realtek/rtw88/fw.c:633:4: warning: symbol 'rtw_get_rsvd_page_probe_req_location' was not declared. Should it be static? drivers/net/wireless/realtek/rtw88/fw.c:650:5: warning: symbol 'rtw_get_rsvd_page_probe_req_size' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200328030524.16032-1-yuehaibing@huawei.com
2020-04-14rtw88: avoid unused function warningsArnd Bergmann
The rtw88 driver defines emtpy functions with multiple indirections but gets one of these wrong: drivers/net/wireless/realtek/rtw88/pci.c:1347:12: error: 'rtw_pci_resume' defined but not used [-Werror=unused-function] 1347 | static int rtw_pci_resume(struct device *dev) | ^~~~~~~~~~~~~~ drivers/net/wireless/realtek/rtw88/pci.c:1342:12: error: 'rtw_pci_suspend' defined but not used [-Werror=unused-function] 1342 | static int rtw_pci_suspend(struct device *dev) Better simplify it to rely on the conditional reference in SIMPLE_DEV_PM_OPS(), and mark the functions as __maybe_unused to avoid warning about it. I'm not sure if these are needed at all given that the functions don't do anything, but they were only recently added. Fixes: 44bc17f7f5b3 ("rtw88: support wowlan feature for 8822c") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200408185413.218643-1-arnd@arndb.de
2020-03-27Merge tag 'wireless-drivers-next-2020-03-27' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for v5.7 Third set of patches for v5.7. Nothing really special this time, business as usual. When pulling this to net-next there's again a conflict in: drivers/net/wireless/intel/iwlwifi/pcie/drv.c To solve this drop these three lines from the conflict (the first hunk from "HEAD") as the whole AX200 block was moved above in the same file: IWL_DEV_INFO(0x2723, 0x1653, iwl_ax200_cfg_cc, iwl_ax200_killer_1650w_name), IWL_DEV_INFO(0x2723, 0x1654, iwl_ax200_cfg_cc, iwl_ax200_killer_1650x_name), IWL_DEV_INFO(0x2723, IWL_CFG_ANY, iwl_ax200_cfg_cc, iwl_ax200_name), And keep all the __IWL_DEV_INFO() entries (the second hunk). In other words, take everything from wireless-drivers-next. When running 'git diff' after the resolution the output should be empty. Major changes: brcmfmac * add USB autosuspend support ath11k * handle RX fragments * enable PN offload * add support for HE BSS color iwlwifi * support new FW API version * support for EDCA measurements * new scan API features * enable new firmware debugging code ==================== Kalle gave me directions on how to resolve the iwlwifi conflict as follows: ==================== When pulling this to net-next there's again a conflict in: drivers/net/wireless/intel/iwlwifi/pcie/drv.c To solve this drop these three lines from the conflict (the first hunk from "HEAD") as the whole AX200 block was moved above in the same file: IWL_DEV_INFO(0x2723, 0x1653, iwl_ax200_cfg_cc, iwl_ax200_killer_1650w_name), IWL_DEV_INFO(0x2723, 0x1654, iwl_ax200_cfg_cc, iwl_ax200_killer_1650x_name), IWL_DEV_INFO(0x2723, IWL_CFG_ANY, iwl_ax200_cfg_cc, iwl_ax200_name), And keep all the __IWL_DEV_INFO() entries (the second hunk). In other words, take everything from wireless-drivers-next. When running 'git diff' after the resolution the output should be empty. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-26rtw88: fix non-increase management packet sequence numberTzu-En Huang
In previous setting, management packets' sequence numbers will not increase and always stay at 0. Add hw sequence number support for mgmt packets. The table below shows different sequence number setting in the tx descriptor. seq num ctrl | EN_HWSEQ | DISQSELSEL | HW_SSN_SEL ------------------------------------------------------ sw ctrl | 0 | N/A | N/A hw ctrl per MACID | 1 | 0 | N/A hw ctrl per HWREG | 1 | 1 |HWREG(0/1/2/3) Signed-off-by: Tzu-En Huang <tehuang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200326020408.25218-1-yhchuang@realtek.com
2020-03-26rtl8xxxu: Feed current txrate information for mac80211Chris Chiu
The nl80211 commands such as 'iw link' can't get current txrate information from the driver. This commit fills in the tx rate information from the C2H RA report in the sta_statistics function. Signed-off-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200320063833.1058-3-chiu@endlessm.com
2020-03-26rtl8xxxu: add enumeration for channel bandwidthChris Chiu
There's a data field in H2C and C2H commands which is used to carry channel bandwidth information. Add enumeration to make it more descriptive in code. Signed-off-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200320063833.1058-2-chiu@endlessm.com
2020-03-26rtw88: add a debugfs entry to enable/disable coex mechanismYan-Hsuan Chuang
Sometimes we need to stop the coex mechanism to debug, so that we can manually control the device through various outer commands. Hence, add a new debugfs coex_enable to allow us to enable/disable the coex mechanism when driver is running. To disable coex echo 0 > /sys/kernel/debug/ieee80211/phyX/rtw88/coex_enable To enable coex echo 1 > /sys/kernel/debug/ieee80211/phyX/rtw88/coex_enable To check coex dm is enabled or not cat /sys/kernel/debug/ieee80211/phyX/rtw88/coex_enable Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200313033008.20070-3-yhchuang@realtek.com
2020-03-26rtw88: add a debugfs entry to dump coex's infoYan-Hsuan Chuang
Add a new entry "coex_info" in debugfs to dump coex's states for us to debug on coex's issues. The basic concept for co-existence (coex, usually for WiFi + BT) is to decide a strategy based on the current status of WiFi and BT. So, it means the WiFi driver requires to gather information from BT side and choose a strategy (TDMA/table/HW settings). Althrough we can easily check the current status of WiFi, e.g., from kernel log or just dump the hardware registers, it is still very difficult for us to gather so many different types of WiFi states (such as RFE config, antenna, channel/band, TRX, Power save). Also we will need BT's information that is stored in "struct rtw_coex". So it is necessary for us to have a debugfs that can dump all of the WiFi/BT information required. Note that to debug on coex related issues, we usually need a longer period of time of coex_info dump every 2 seconds (for example, 30 secs, so we should have 15 times of coex_info's dump). Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200313033008.20070-2-yhchuang@realtek.com
2020-03-25Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller
Overlapping header include additions in macsec.c A bug fix in 'net' overlapping with the removal of 'version' string in ena_netdev.c Overlapping test additions in selftests Makefile Overlapping PCI ID table adjustments in iwlwifi driver. Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-23rtl8xxxu: Fix sparse warning: cast from restricted __le16Chris Chiu
Fix the warning reported by sparse as: drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:4819:17: sparse: sparse: cast from restricted __le16 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:4892:17: sparse: sparse: cast from restricted __le16 Signed-off-by: Chris Chiu <chiu@endlessm.com> Reported-by: kbuild test robot <lkp@intel.com> Acked-by: Jes Sorensen <jes@trained-monkey.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200319064341.49500-1-chiu@endlessm.com
2020-03-23rtw88: 8822c: config RF table path B before path AYan-Hsuan Chuang
After MAC switched power, the hardware's RF registers will have its default value, but the default value for path B is incorrect. So, load RF path B first, to decrease the period between MAC on and RF path B config. By test, if we load path A first, then there's ~300ms that the path B is incorrect, it could lead to BT coex's A2DP glitch. But if we configure path B first, there will only have ~3ms, significantly lower possibility to have A2DP sound glitch. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200318095224.12940-1-yhchuang@realtek.com
2020-03-23rtw88: kick off TX packets once for higher efficiencyYan-Hsuan Chuang
Driver used to kick off every TX packets, that will waste some time while we can do better to kick off the TX packets once after they are all prepared to be transmitted. For PCI, it uses DMA engine to transfer the SKBs to the device, and the transition of the state of the DMA engine could be a cost. Driver can save some time to kick off multiple SKBs once so that the DMA engine will have only one transition. So, split rtw_hci_ops::tx() to rtw_hci_ops::tx_write() and rtw_hci_ops::tx_kick_off() to explicitly kick the SKBs off after they are written to the prepared buffer. For packets come from ieee80211_ops::tx(), write one and then kick it off immediately. For packets queued in TX queue, which come from ieee80211_ops::wake_tx_queue(), we can dequeue them, write them to the buffer, and then kick them off together. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200312080852.16684-6-yhchuang@realtek.com
2020-03-23rtw88: pci: define a mask for TX/RX BD indexesYan-Hsuan Chuang
Add a macro TRX_BD_IDX_MASK for access the TX/RX BD indexes. The hardware has only 12 bits for TX/RX BD indexes, we should not initialize a TX/RX ring or access the TX/RX BD index with a length that is larger than TRX_BD_IDX_MASK. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200312080852.16684-5-yhchuang@realtek.com
2020-03-23rtw88: associate reserved pages with each vifYan-Hsuan Chuang
Each device has only one reserved page shared with all of the vifs, so it seems not reasonable to pass vif as one of the arguments to rtw_fw_download_rsvd_page(). If driver is going to run more than one vif, the content of reserved page could not be built for all of the vifs. To fix it, let each vif maintain its own reserved page list, and build the final reserved page to download to the firmware from all of the vifs. Hence driver should add reserved pages to each vif according to the vif->type when adding the vif. For station mode, add reserved page with rtw_add_rsvd_page_sta(). If the station mode is going to suspend in PNO (net-detect) mode, remove the reserved pages used for normal mode, and add new one for wowlan mode with rtw_add_rsvd_page_pno(). For beacon mode, only beacon is required to be added using rtw_add_rsvd_page_bcn(). This would make the code flow simpler as we don't need to add reserved pages when vif is running, just add/remove them when ieee80211_ops::[add|remove]_interface. When driver is going to download the reserved page, it will collect pages from all of the vifs, this list is maintained by rtwdev, with build_list as the pages' member. That way, we can still build a list of reserved pages to be downloaded. Also we can get the location of the pages from the list that is maintained by rtwdev. The biggest problem is that the first page should always be beacon, if other type of reserved page is put in the first page, the tx descriptor and offset could be wrong. But station mode vif does not add beacon into its list, so we need to add a dummy page in front of the list, to make sure other pages will not be put in the first page. As the dummy page is allocated when building the list, we must free it before building a new list of reserved pages to firmware. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200312080852.16684-4-yhchuang@realtek.com
2020-03-23rtw88: extract alloc rsvd_page and h2c skb routinesYan-Hsuan Chuang
Extract skb allocation routines for rsvd_page and h2c. These routines should also be used by USB and SDIO. This should not change the logic at all. memset() for pkt_info is unnecessary, just declare as {0}. Also skb_put()/memcpy() can be replaced by skb_put_data(). Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200312080852.16684-3-yhchuang@realtek.com
2020-03-23rtw88: don't hold all IRQs disabled for PS operationsBrian Norris
This driver generally only needs to ensure that (a) it doesn't try to process TX interrupts at the same time as power-save operations (and similar) (b) the device interrupt gets disabled while we're still handling the last set of interrupts For (a), all the operations (e.g., PS transitions, packet handling) happens in non-atomic contexts (e.g., threaded IRQ). For (b), we only need mutual exclusion for brief sections (i.e., while we're actually manipulating the interrupt mask/status). So, we can introduce a separate lock for handling (b), disabling IRQs while we do it. For (a), we can demote the locking to BH only, now that (b) (the only steps done in atomic context) and that has its own lock. This helps reduce the amount of time this driver spends with IRQs off. Notably, transitioning out of power-save modes can take >3 milliseconds, and this transition is done under the protection of 'irq_lock'. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200312080852.16684-2-yhchuang@realtek.com
2020-03-23wireless: realtek: Replace zero-length array with flexible-array memberGustavo A. R. Silva
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200225002746.GA26789@embeddedor
2020-03-12rtw88: remove unused member of struct rtw_halKevin Lo
Remove unused fab_version member from struct rtw_hal. Some of the checks being made were nonsense. Signed-off-by: Kevin Lo <kevlo@kevlo.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-03-12rtlwifi: rtl8188ee: Fix regression due to commit d1d1a96bdb44Larry Finger
For some unexplained reason, commit d1d1a96bdb44 ("rtlwifi: rtl8188ee: Remove local configuration variable") broke at least one system. As the only net effect of the change was to remove 2 bytes from the start of struct phy_status_rpt, this patch adds 2 bytes of padding at the beginning of the struct. Fixes: d1d1a96bdb44 ("rtlwifi: rtl8188ee: Remove local configuration variable") Cc: Stable <stable@vger.kernel.org> # V5.4+ Reported-by: Ashish <ashishkumar.yadav@students.iiserpune.ac.in> Tested-by: Ashish <ashishkumar.yadav@students.iiserpune.ac.in> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-02-13rtw88: Fix incorrect beamformee role settingTzu-En Huang
In associating and configuring beamformee, bfee->role is not correctly set before rtw_chip_ops::config_bfee(). Fix it by setting it correctly. 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>
2020-02-12rtw88: 8822[bc]: Make tables const, reduce data object sizeJoe Perches
Reduce the data size 2kb or 3kb by making tables const. Add const to pointer declarations to make compilation work too. (x86-64 defconfig) $ size drivers/net/wireless/realtek/rtw88/rtw8822?.o* text data bss dec hex filename 25054 672 8 25734 6486 drivers/net/wireless/realtek/rtw88/rtw8822b.o.new 23870 1872 8 25750 6496 drivers/net/wireless/realtek/rtw88/rtw8822b.o.old 53646 828 0 54474 d4ca drivers/net/wireless/realtek/rtw88/rtw8822c.o.new 52846 1652 0 54498 d4e2 drivers/net/wireless/realtek/rtw88/rtw8822c.o.old (x86-64 allyesconfig) $ size drivers/net/wireless/realtek/rtw88/rtw8822?.o* text data bss dec hex filename 45811 6280 128 52219 cbfb drivers/net/wireless/realtek/rtw88/rtw8822b.o.new 44211 7880 128 52219 cbfb drivers/net/wireless/realtek/rtw88/rtw8822b.o.old 100195 8128 0 108323 1a723 drivers/net/wireless/realtek/rtw88/rtw8822c.o.new 98947 9376 0 108323 1a723 drivers/net/wireless/realtek/rtw88/rtw8822c.o.old Signed-off-by: Joe Perches <joe@perches.com> Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-02-12rtw88: disable TX-AMSDU on 2.4G bandYan-Hsuan Chuang
Some tests shows that using AMSDU to aggregate TCP ACKs to specific APs will degrade the throughput on 2.4G band in 20MHz bandwidth (< 10 Mbps, should be ~100 Mbps for 2x2). Also found that there's barely no negative impact if we disable TX AMSDU on 2.4G to connect to other APs. So it seems like we can just tell mac80211 to not to aggregate MSDUs when transmitting on 2.4G band. Note that we still can TX AMSDU on 5G band and benefit from it by having 50 ~ 70 Mbps throughput improvement. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-04 00:33:09 +0000