wireguard-linux/drivers/net/wireless/realtek, branch jd/unified-crypt-queue

rtw88: avoid unused function warnings

2020-04-14T12:45:36Z

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 Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200408185413.218643-1-arnd@arndb.de

Merge tag 'wireless-drivers-next-2020-03-27' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next

2020-03-27T22:40:24Z

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

rtw88: fix non-increase management packet sequence number

2020-03-26T19:21:43Z

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 Signed-off-by: Yan-Hsuan Chuang Reviewed-by: Brian Norris Tested-by: Brian Norris Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200326020408.25218-1-yhchuang@realtek.com

rtl8xxxu: Feed current txrate information for mac80211

2020-03-26T09:43:00Z

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 Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200320063833.1058-3-chiu@endlessm.com

rtl8xxxu: add enumeration for channel bandwidth

2020-03-26T09:42:52Z

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 Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200320063833.1058-2-chiu@endlessm.com

rtw88: add a debugfs entry to enable/disable coex mechanism

2020-03-26T09:41:57Z

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 Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200313033008.20070-3-yhchuang@realtek.com

rtw88: add a debugfs entry to dump coex's info

2020-03-26T09:41:48Z

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 Reviewed-by: Chris Chiu Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200313033008.20070-2-yhchuang@realtek.com

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2020-03-26T01:58:11Z

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

rtl8xxxu: Fix sparse warning: cast from restricted __le16

2020-03-23T17:35:20Z

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 Reported-by: kbuild test robot Acked-by: Jes Sorensen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200319064341.49500-1-chiu@endlessm.com

rtw88: 8822c: config RF table path B before path A

2020-03-23T17:33:49Z

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 Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200318095224.12940-1-yhchuang@realtek.com