summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek
AgeCommit message (Collapse)Author
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-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>
2020-02-12rtw88: 8822c: modify rf protection settingChien-Hsun Liao
According to some experiments, the original RF register protection setting of 8822c cannot perfectly make sure that there is no hardware PI write (direct) during direct write. Modify the setting so that the hardware block of PI would be turned off via rtw8822c_rstb_3wire() during the direct write, to avoid RF register racing. Note that 8822b uses SIPI write (indirect), so 8822b does not have such problem. Signed-off-by: Chien-Hsun Liao <ben.liao@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: Use secondary channel offset enumerationPing-Ke Shih
The hardware value of secondary channel offset isn't very intuitive. This commit adds enumeration, so we can easier to check the logic with the suffix of enumeration name, likes _UPPER or _LOWER. Signed-off-by: Ping-Ke Shih <pkshih@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: Use kfree_skb() instead of kfree()Dan Carpenter
sk_buff structs need to be freed with kfree_skb(), not kfree(). Fixes: b6c12908a33e ("rtw88: Add wowlan net-detect support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-02-12rtw88: 8822c: update power sequence to v16Tzu-En Huang
Fix switching xtal mode leads to BT USB error issue. 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>
2020-02-12rtw88: add ciphers to suppress error messagePing-Ke Shih
Though hardware isn't implement CCMP-256, GCMP and GCMP-256, it's possible to fallback to use software de-/en-cryption implemented by mac80211. Without adding these chipers, kernel log will show something if we connect to a WPA3 enterprise AP, likes wlan0: failed to set key (1, ff:ff:ff:ff:ff:ff) to hardware (-524) 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>
2020-02-12rtw88: avoid holding mutex for cancel_delayed_work_sync()Yan-Hsuan Chuang
Driver could possibly be dead-locked while canceling works with *_sync() with mutex lock held. Those cancel_delayed_work_sync() functions will wait until the work is done, but if we hold the lock, they will never acquire the lock. To prevent this, simply release the lock and acquire again after the works have been canceled. And to avoid the works being queued again, check if the device is at RTW_FLAG_RUNNING state, otherwise just return and do nothing. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-02-12rtw88: move rtw_enter_ips() to the last when configPing-Ke Shih
When driver is coming up, mac80211 will set changed as ~0 (0xffffffff), and driver could enter IDLE state (power off) before switching channel or other config event. So move rtw_enter_ips() to the last, to make sure the driver completed the config events before going to IDLE state. So, moves leave/enter IPS config to be first/last one according to flag IEEE80211_CONF_IDLE. If there're more configureations we want to add in the future, they must locate between leave/enter IPS. Signed-off-by: Ping-Ke Shih <pkshih@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: pci: 8822c should set clock delay to zeroYan-Hsuan Chuang
Since RTL8822CE has enabled reference clock auto calibration, there is no need to add any clock delay for covering the timing gap of the reference clock. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-02-12rtw88: add rtw_read8_mask and rtw_read16_maskYan-Hsuan Chuang
Both are missing but could be used sometimes. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-02-12rtw88: remove unused parameter vif in rtw_lps_pg_info_get()Yan-Hsuan Chuang
vif is not used, remove it 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-03rtw88: Fix return value of rtw_wow_check_fw_statusChin-Yen Lee
Clang warns that ret is used uninitialzed. And we found that actually the return type should be "int" instead of "bool". Fixes: 44bc17f7f5b3 ("rtw88: support wowlan feature for 8822c") Link: https://github.com/ClangBuiltLinux/linux/issues/850 Reported-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> # build Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-01-26rtlwifi: btcoex: fix spelling mistake "initilized" -> "initialized"Colin Ian King
There is a spelling mistake in one of the fields in the btc_coexist struct, fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-01-26rtlwifi: rtl8723ae: remove unused variablesYueHaibing
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c:16:18: warning: ofdmswing_table defined but not used [-Wunused-const-variable=] drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c:56:17: warning: cckswing_table_ch1ch13 defined but not used [-Wunused-const-variable=] drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c:92:17: warning: cckswing_table_ch14 defined but not used [-Wunused-const-variable=] These variable is never used, so remove them. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-01-26rtlwifi: rtl8192ee: remove unused variablesYueHaibing
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c:15:18: warning: ofdmswing_table defined but not used [-Wunused-const-variable=] drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c:61:17: warning: cckswing_table_ch1ch13 defined but not used [-Wunused-const-variable=] drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c:97:17: warning: cckswing_table_ch14 defined but not used [-Wunused-const-variable=] These variable is never used, so remove them. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-01-26rtlwifi: rtl8821ae: remove unused variablesYueHaibing
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c:142:17: warning: cckswing_table_ch1ch13 defined but not used [-Wunused-const-variable=] drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c:178:17: warning: cckswing_table_ch14 defined but not used [-Wunused-const-variable=] drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c:96:18: warning: ofdmswing_table defined but not used [-Wunused-const-variable=] These variable is never used, so remove them. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-07 20:52:05 +0000