summaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)Author
2022-10-04brcmfmac: Add dump_survey cfg80211 ops for HostApd AutoChannelSelectionWright Feng
To enable ACS feature in Hostap daemon, dump_survey cfg80211 ops and dump obss survey command in firmware side are needed. This patch is for adding dump_survey feature and adding DUMP_OBSS feature flag to check if firmware supports dump_obss iovar. Signed-off-by: Wright Feng <wright.feng@cypress.com> Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Ian Lin <ian.lin@infineon.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220929012527.4152-2-ian.lin@infineon.com
2022-10-04wifi: rtl8xxxu: gen2: Turn on the rate controlBitterblue Smith
Re-enable the function rtl8xxxu_gen2_report_connect. It informs the firmware when connecting to a network. This makes the firmware enable the rate control, which makes the upload faster. It also informs the firmware when disconnecting from a network. In the past this made reconnecting impossible because it was sending the auth on queue 0x7 (TXDESC_QUEUE_VO) instead of queue 0x12 (TXDESC_QUEUE_MGNT): wlp0s20f0u3: send auth to 90:55:de:__:__:__ (try 1/3) wlp0s20f0u3: send auth to 90:55:de:__:__:__ (try 2/3) wlp0s20f0u3: send auth to 90:55:de:__:__:__ (try 3/3) wlp0s20f0u3: authentication with 90:55:de:__:__:__ timed out Probably the firmware disables the unnecessary TX queues when it knows it's disconnected. However, this was fixed in commit edd5747aa12e ("wifi: rtl8xxxu: Fix skb misuse in TX queue selection"). Fixes: c59f13bbead4 ("rtl8xxxu: Work around issue with 8192eu and 8723bu devices not reconnecting") Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/43200afc-0c65-ee72-48f8-231edd1df493@gmail.com
2022-10-04wifi: rtl8xxxu: Support new chip RTL8188FUBitterblue Smith
This chip is found in the cheapest USB adapters, e.g. 1.17 USD with VAT and shipping from China included. It's a gen 2 chip, similar to the RTL8723BU, but without Bluetooth. Features: 2.4 GHz, b/g/n mode, 1T1R, 150 Mbps. The vendor driver rtl8188fu version 4.3.23.6_20964.20170110 [0] was used as reference. The CD shipped with the device includes a newer driver, version 5.11.5-1-g12f7cde4b.20201102, but that one couldn't complete the WPA2 key exchange thing for whatever reason. [0] https://github.com/kelebek333/rtl8188fu Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/b14f299d-3248-98fe-eee1-ba50d2e76c74@gmail.com
2022-10-04wifi: rtw89: 8852be: add 8852BE PCI entryPing-Ke Shih
8852BE has two variants with different ID. One is 10ec:b852 that is a main model with 2x2 antenna, and the other is 10ec:b85b that is a 1x1 model. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220928084336.34981-10-pkshih@realtek.com
2022-10-04wifi: rtw89: 8852b: add chip_ops to read phy capPing-Ke Shih
This efuse region is to store PHY calibration, and it is a separated region from the region that stores MAC address. Then, use these data to configure via chip_ops::power_trim that is a calibration mechanism of TX power. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220928084336.34981-9-pkshih@realtek.com
2022-10-04wifi: rtw89: 8852b: add chip_ops to read efusePing-Ke Shih
efuse stores individual data about a chip itself, such as MAC address, country code, RF and crystal calibration data, and so on. Define a struct to help access efuse content, and copy them into a common struct. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220928084336.34981-8-pkshih@realtek.com
2022-10-04wifi: rtw89: 8852b: add chip_ops::set_txpwrPing-Ke Shih
This chip_ops is to set TX power according to country, channel, rate and so on. Since shared code is used to configure TX power, we only implement specific part in this patch. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220928084336.34981-7-pkshih@realtek.com
2022-10-04wifi: rtw89: debug: txpwr_table considers signZong-Zhe Yang
Previously, value of each field is just shown as unsigned. Now, we start to show them with sign to make things more intuitive during debugging. 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@kernel.org> Link: https://lore.kernel.org/r/20220928084336.34981-6-pkshih@realtek.com
2022-10-04wifi: rtw89: phy: make generic txpwr setting functionsZong-Zhe Yang
Previously, we thought control registers or setting things for TX power series may change according to chip. So, setting functions are implemented chip by chip. However, until now, the functions keep the same among chips, at least 8852A, 8852C, and 8852B. There is a sufficient number of chips to share generic setting functions. So, we now remake them including TX power by rate, TX power offset, TX power limit, and TX power limit RU as generic ones in phy.c. Besides, there are some code refinements in the generic ones, but almost all of the logic doesn't change. 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@kernel.org> Link: https://lore.kernel.org/r/20220928084336.34981-5-pkshih@realtek.com
2022-10-04wifi: rtw89: 8852b: add tables for RFKPing-Ke Shih
These tables are used by RFK to assist to configure PHY and RF registers. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220928084336.34981-4-pkshih@realtek.com
2022-10-04wifi: rtw89: 8852b: add BB and RF tables (2 of 2)Ping-Ke Shih
These tables contain BB and RF parameters that driver will load them into registers. It also contains TX power according to country, band, rate and so on. Increasing thermal can cause TX power degraded, so power tracking tables are defined to compensate TX power. Internal version of these tables: - HALRF_029_00_014 (R32) - HALBB_027_046_05 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220928084336.34981-3-pkshih@realtek.com
2022-10-04wifi: rtw89: 8852b: add BB and RF tables (1 of 2)Ping-Ke Shih
These tables contain BB and RF parameters that driver will load them into registers. It also contains TX power according to country, band, rate and so on. Increasing thermal can cause TX power degraded, so power tracking tables are defined to compensate TX power. Internal version of these tables: - HALRF_029_00_014 (R32) - HALBB_027_046_05 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220928084336.34981-2-pkshih@realtek.com
2022-09-30Merge tag 'wireless-next-2022-09-30' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.1 Few stack changes and lots of driver changes in this round. brcmfmac has more activity as usual and it gets new hardware support. ath11k improves WCN6750 support and also other smaller features. And of course changes all over. Note: in early September wireless tree was merged to wireless-next to avoid some conflicts with mac80211 patches, this shouldn't cause any problems but wanted to mention anyway. Major changes: mac80211 - refactoring and preparation for Wi-Fi 7 Multi-Link Operation (MLO) feature continues brcmfmac - support CYW43439 SDIO chipset - support BCM4378 on Apple platforms - support CYW89459 PCIe chipset rtw89 - more work to get rtw8852c supported - P2P support - support for enabling and disabling MSDU aggregation via nl80211 mt76 - tx status reporting improvements ath11k - cold boot calibration support on WCN6750 - Target Wake Time (TWT) debugfs support for STA interface - support to connect to a non-transmit MBSSID AP profile - enable remain-on-channel support on WCN6750 - implement SRAM dump debugfs interface - enable threaded NAPI on all hardware - WoW support for WCN6750 - support to provide transmit power from firmware via nl80211 - support to get power save duration for each client - spectral scan support for 160 MHz wcn36xx - add SNR from a received frame as a source of system entropy * tag 'wireless-next-2022-09-30' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (231 commits) wifi: rtl8xxxu: Improve rtl8xxxu_queue_select wifi: rtl8xxxu: Fix AIFS written to REG_EDCA_*_PARAM wifi: rtl8xxxu: gen2: Enable 40 MHz channel width wifi: rtw89: 8852b: configure DLE mem wifi: rtw89: check DLE FIFO size with reserved size wifi: rtw89: mac: correct register of report IMR wifi: rtw89: pci: set power cut closed for 8852be wifi: rtw89: pci: add to do PCI auto calibration wifi: rtw89: 8852b: implement chip_ops::{enable,disable}_bb_rf wifi: rtw89: add DMA busy checking bits to chip info wifi: rtw89: mac: define DMA channel mask to avoid unsupported channels wifi: rtw89: pci: mask out unsupported TX channels iwlegacy: Replace zero-length arrays with DECLARE_FLEX_ARRAY() helper ipw2x00: Replace zero-length array with DECLARE_FLEX_ARRAY() helper wifi: iwlwifi: Track scan_cmd allocation size explicitly brcmfmac: Remove the call to "dtim_assoc" IOVAR brcmfmac: increase dcmd maximum buffer size brcmfmac: Support 89459 pcie brcmfmac: increase default max WOWL patterns to 16 cw1200: fix incorrect check to determine if no element is found in list ... ==================== Link: https://lore.kernel.org/r/20220930150413.A7984C433D6@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-30wifi: ath11k: fix warning in dma_free_coherent() of memory chunks while recoveryWen Gong
Commit 26f3a021b37c ("ath11k: allocate smaller chunks of memory for firmware") and commit f6f92968e1e5 ("ath11k: qmi: try to allocate a big block of DMA memory first") change ath11k to allocate the memory chunks for target twice while wlan load. It fails for the 1st time because of large memory and then changed to allocate many small chunks for the 2nd time sometimes as below log. 1st time failed: [10411.640620] ath11k_pci 0000:05:00.0: qmi firmware request memory request [10411.640625] ath11k_pci 0000:05:00.0: qmi mem seg type 1 size 6881280 [10411.640630] ath11k_pci 0000:05:00.0: qmi mem seg type 4 size 3784704 [10411.640658] ath11k_pci 0000:05:00.0: qmi dma allocation failed (6881280 B type 1), will try later with small size [10411.640671] ath11k_pci 0000:05:00.0: qmi delays mem_request 2 [10411.640677] ath11k_pci 0000:05:00.0: qmi respond memory request delayed 1 2nd time success: [10411.642004] ath11k_pci 0000:05:00.0: qmi firmware request memory request [10411.642008] ath11k_pci 0000:05:00.0: qmi mem seg type 1 size 524288 [10411.642012] ath11k_pci 0000:05:00.0: qmi mem seg type 1 size 524288 [10411.642014] ath11k_pci 0000:05:00.0: qmi mem seg type 1 size 524288 [10411.642016] ath11k_pci 0000:05:00.0: qmi mem seg type 1 size 524288 [10411.642018] ath11k_pci 0000:05:00.0: qmi mem seg type 1 size 524288 [10411.642020] ath11k_pci 0000:05:00.0: qmi mem seg type 1 size 524288 [10411.642022] ath11k_pci 0000:05:00.0: qmi mem seg type 1 size 524288 [10411.642024] ath11k_pci 0000:05:00.0: qmi mem seg type 1 size 524288 [10411.642027] ath11k_pci 0000:05:00.0: qmi mem seg type 1 size 524288 [10411.642029] ath11k_pci 0000:05:00.0: qmi mem seg type 1 size 524288 [10411.642031] ath11k_pci 0000:05:00.0: qmi mem seg type 1 size 458752 [10411.642033] ath11k_pci 0000:05:00.0: qmi mem seg type 1 size 131072 [10411.642035] ath11k_pci 0000:05:00.0: qmi mem seg type 4 size 524288 [10411.642037] ath11k_pci 0000:05:00.0: qmi mem seg type 4 size 524288 [10411.642039] ath11k_pci 0000:05:00.0: qmi mem seg type 4 size 524288 [10411.642041] ath11k_pci 0000:05:00.0: qmi mem seg type 4 size 524288 [10411.642043] ath11k_pci 0000:05:00.0: qmi mem seg type 4 size 524288 [10411.642045] ath11k_pci 0000:05:00.0: qmi mem seg type 4 size 524288 [10411.642047] ath11k_pci 0000:05:00.0: qmi mem seg type 4 size 491520 [10411.642049] ath11k_pci 0000:05:00.0: qmi mem seg type 1 size 524288 And then commit 5962f370ce41 ("ath11k: Reuse the available memory after firmware reload") skip the ath11k_qmi_free_resource() which frees the memory chunks while recovery, after that, when run recovery test on WCN6855, a warning happened every time as below and finally leads fail for recovery. [ 159.570318] BUG: Bad page state in process kworker/u16:5 pfn:33300 [ 159.570320] page:0000000096ffdbb9 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x33300 [ 159.570324] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) [ 159.570329] raw: 000fffffc0000000 0000000000000000 dead000000000122 0000000000000000 [ 159.570332] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 [ 159.570334] page dumped because: nonzero _refcount [ 159.570440] firewire_ohci syscopyarea sysfillrect psmouse sdhci_pci ahci sysimgblt firewire_core fb_sys_fops libahci crc_itu_t cqhci drm sdhci e1000e wmi video [ 159.570460] CPU: 2 PID: 217 Comm: kworker/u16:5 Kdump: loaded Tainted: G B 5.19.0-rc1-wt-ath+ #3 [ 159.570465] Hardware name: LENOVO 418065C/418065C, BIOS 83ET63WW (1.33 ) 07/29/2011 [ 159.570467] Workqueue: qmi_msg_handler qmi_data_ready_work [qmi_helpers] [ 159.570475] Call Trace: [ 159.570476] <TASK> [ 159.570478] dump_stack_lvl+0x49/0x5f [ 159.570486] dump_stack+0x10/0x12 [ 159.570493] bad_page+0xab/0xf0 [ 159.570502] check_free_page_bad+0x66/0x70 [ 159.570511] __free_pages_ok+0x530/0x9a0 [ 159.570517] ? __dev_printk+0x58/0x6b [ 159.570525] ? _dev_printk+0x56/0x72 [ 159.570534] ? qmi_decode+0x119/0x470 [qmi_helpers] [ 159.570543] __free_pages+0x91/0xd0 [ 159.570548] dma_free_contiguous+0x50/0x60 [ 159.570556] dma_direct_free+0xe5/0x140 [ 159.570564] dma_free_attrs+0x35/0x50 [ 159.570570] ath11k_qmi_msg_mem_request_cb+0x2ae/0x3c0 [ath11k] [ 159.570620] qmi_invoke_handler+0xac/0xe0 [qmi_helpers] [ 159.570630] qmi_handle_message+0x6d/0x180 [qmi_helpers] [ 159.570643] qmi_data_ready_work+0x2ca/0x440 [qmi_helpers] [ 159.570656] process_one_work+0x227/0x440 [ 159.570667] worker_thread+0x31/0x3d0 [ 159.570676] ? process_one_work+0x440/0x440 [ 159.570685] kthread+0xfe/0x130 [ 159.570692] ? kthread_complete_and_exit+0x20/0x20 [ 159.570701] ret_from_fork+0x22/0x30 [ 159.570712] </TASK> The reason is because when wlan start to recovery, the type, size and count is not same for the 1st and 2nd QMI_WLFW_REQUEST_MEM_IND message, Then it leads the parameter size is not correct for the dma_free_coherent(). For the chunk[1], the actual dma size is 524288 which allocate in the 2nd time of the initial wlan load phase, and the size which pass to dma_free_coherent() is 3784704 which is got in the 1st time of recovery phase, then warning above happened. Change to use prev_size of struct target_mem_chunk for the paramter of dma_free_coherent() since prev_size is the real size of last load/recovery. Also change to check both type and size of struct target_mem_chunk to reuse the memory to avoid mismatch buffer size for target. Then the warning disappear and recovery success. When the 1st QMI_WLFW_REQUEST_MEM_IND for recovery arrived, the trunk[0] is freed in ath11k_qmi_alloc_target_mem_chunk() and then dma_alloc_coherent() failed caused by large size, and then trunk[1] is freed in ath11k_qmi_free_target_mem_chunk(), the left 18 trunks will be reuse for the 2nd QMI_WLFW_REQUEST_MEM_IND message. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3 Fixes: 5962f370ce41 ("ath11k: Reuse the available memory after firmware reload") Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220928073832.16251-1-quic_wgong@quicinc.com
2022-09-30wifi: ath11k: Don't exit on wakeup failureBaochen Qiang
Currently, ath11k_pcic_read() returns an error if wakeup() fails, this makes firmware crash debug quite hard because we can get nothing. Change to go ahead on wakeup failure, in that case we still may get something valid to check. There should be no mislead due to incorrect content because we are aware of the failure with the log printed. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220928015140.5431-1-quic_bqiang@quicinc.com
2022-09-30carl9170: Replace zero-length array with DECLARE_FLEX_ARRAY() helperGustavo A. R. Silva
Zero-length arrays are deprecated and we are moving towards adopting C99 flexible-array members, instead. So, replace zero-length arrays declarations in anonymous union with the new DECLARE_FLEX_ARRAY() helper macro. This helper allows for flexible-array members in unions. Link: https://github.com/KSPP/linux/issues/193 Link: https://github.com/KSPP/linux/issues/215 Link: https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/YzIdWc8QSdZFHBYg@work
2022-09-29wifi: rtl8xxxu: Improve rtl8xxxu_queue_selectBitterblue Smith
Remove the unused ieee80211_hw* parameter, and pass ieee80211_hdr* instead of relying on skb->data having the right value at the time the function is called. This doesn't change the functionality at all. Fixes: 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)") Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Jes Sorensen <jes@trained-monkey.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/2af44c28-1c12-46b9-85b9-011560bf7f7e@gmail.com
2022-09-29wifi: rtl8xxxu: Fix AIFS written to REG_EDCA_*_PARAMBitterblue Smith
ieee80211_tx_queue_params.aifs is not supposed to be written directly to the REG_EDCA_*_PARAM registers. Instead process it like the vendor drivers do. It's kinda hacky but it works. This change boosts the download speed and makes it more stable. Tested with RTL8188FU but all the other supported chips should also benefit. Fixes: 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)") Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Jes Sorensen <jes@trained-monkey.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/038cc03f-3567-77ba-a7bd-c4930e3b2fad@gmail.com
2022-09-29wifi: rtl8xxxu: gen2: Enable 40 MHz channel widthBitterblue Smith
The module parameter ht40_2g was supposed to enable 40 MHz operation, but it didn't. Tell the firmware about the channel width when updating the rate mask. This makes it work with my gen 2 chip RTL8188FU. I'm not sure if anything needs to be done for the gen 1 chips, if 40 MHz channel width already works or not. They update the rate mask with a different structure which doesn't have a field for the channel width. Also set the channel width correctly for sta_statistics. Fixes: f653e69009c6 ("rtl8xxxu: Implement basic 8723b specific update_rate_mask() function") Fixes: bd917b3d28c9 ("rtl8xxxu: fill up txrate info for gen1 chips") Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Jes Sorensen <jes@trained-monkey.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/3a950997-7580-8a6b-97a0-e0a81a135456@gmail.com
2022-09-28net: drop the weight argument from netif_napi_addJakub Kicinski
We tell driver developers to always pass NAPI_POLL_WEIGHT as the weight to netif_napi_add(). This may be confusing to newcomers, drop the weight argument, those who really need to tweak the weight can use netif_napi_add_weight(). Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> # for CAN Link: https://lore.kernel.org/r/20220927132753.750069-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-28wifi: ath10k: Replace zero-length arrays with DECLARE_FLEX_ARRAY() helperGustavo A. R. Silva
Zero-length arrays are deprecated and we are moving towards adopting C99 flexible-array members, instead. So, replace zero-length arrays declarations in anonymous union with the new DECLARE_FLEX_ARRAY() helper macro. This helper allows for flexible-array members in unions. Link: https://github.com/KSPP/linux/issues/193 Link: https://github.com/KSPP/linux/issues/212 Link: https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/YzIcoloIQBDqGlgc@work
2022-09-28wifi: wil6210: debugfs: use DEFINE_SHOW_ATTRIBUTE to simplify ↵Liu Shixin
fw_capabilities/fw_version Use DEFINE_SHOW_ATTRIBUTE helper macro to simplify the code. No functional change. Signed-off-by: Liu Shixin <liushixin2@huawei.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220922142858.3250469-1-liushixin2@huawei.com
2022-09-28wifi: ath11k: stop tx queues immediately upon firmware exitAditya Kumar Singh
Currently, recovery flag is set immediately upon firmware exit but tx queues are stopped once firmware arrives back and is ready which is during ath11k_core_restart. Once ieee80211 hw restart is completed, tx queues are resumed. If during the time delta between firmware exit and firmware ready, mac80211 send packets, currently ath11k will drop it since recovery flag will be set. But warning prints will come - "ath11k c000000.wifi: failed to transmit frame -108" If more tx packets are there, this could lead to flooding of above print. However, actually tx queues should be stopped immediately when firmware leaves. This will prevent packets to get dropped when firmware is recovering. Add fix to stop tx queues immediately after firmware exit. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220923170235.18873-1-quic_adisi@quicinc.com
2022-09-28wifi: rtw89: 8852b: configure DLE memPing-Ke Shih
Configure DLE (data link engine) memory size for operating modes. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220927062611.30484-10-pkshih@realtek.com
2022-09-28wifi: rtw89: check DLE FIFO size with reserved sizePing-Ke Shih
For SCC mode, some FIFO are reserved, so compare the quantity after minus the reserved size. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220927062611.30484-9-pkshih@realtek.com
2022-09-28wifi: rtw89: mac: correct register of report IMRPing-Ke Shih
The register of report IMR is chip specific, so add a field to strut to correct them. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220927062611.30484-8-pkshih@realtek.com
2022-09-28wifi: rtw89: pci: set power cut closed for 8852bePing-Ke Shih
Entering LPS with PCIe APHY power cut closed would cause PCIe link issue. To avoid the combinational issue, keep PCIe APHY power cut always on. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220927062611.30484-7-pkshih@realtek.com
2022-09-28wifi: rtw89: pci: add to do PCI auto calibrationPing-Ke Shih
8852be needs this with n times calibration to correct hardware clock. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220927062611.30484-6-pkshih@realtek.com
2022-09-28wifi: rtw89: 8852b: implement chip_ops::{enable,disable}_bb_rfPing-Ke Shih
Implement to power on/off BB and RF via MAC registers. Add return type of chip_ops::disable_bb_rf, because it could fail to disable. Also, correct naming of register 0x0200 used by the ops as well. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220927062611.30484-5-pkshih@realtek.com
2022-09-28wifi: rtw89: add DMA busy checking bits to chip infoPing-Ke Shih
8852B has less DMA channels, so its checking bits are different from other chips. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220927062611.30484-4-pkshih@realtek.com
2022-09-28wifi: rtw89: mac: define DMA channel mask to avoid unsupported channelsPing-Ke Shih
Six channels are unsupported by 8852b, so mask them out to prevent to access undefined registers in this chip. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220927062611.30484-3-pkshih@realtek.com
2022-09-28wifi: rtw89: pci: mask out unsupported TX channelsPing-Ke Shih
8852BE doesn't support some TX channels, so mask them out, or it access undefined registers. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220927062611.30484-2-pkshih@realtek.com
2022-09-28iwlegacy: Replace zero-length arrays with DECLARE_FLEX_ARRAY() helperGustavo A. R. Silva
Zero-length arrays are deprecated and we are moving towards adopting C99 flexible-array members, instead. So, replace zero-length arrays declarations in anonymous union with the new DECLARE_FLEX_ARRAY() helper macro. This helper allows for flexible-array members in unions. Link: https://github.com/KSPP/linux/issues/193 Link: https://github.com/KSPP/linux/issues/223 Link: https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/YzIvzc0jsYLigO8a@work
2022-09-28ipw2x00: Replace zero-length array with DECLARE_FLEX_ARRAY() helperGustavo A. R. Silva
Zero-length arrays are deprecated and we are moving towards adopting C99 flexible-array members, instead. So, replace zero-length arrays declarations in anonymous union with the new DECLARE_FLEX_ARRAY() helper macro. This helper allows for flexible-array members in unions. Link: https://github.com/KSPP/linux/issues/193 Link: https://github.com/KSPP/linux/issues/220 Link: https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/YzIeULWc17XSIglv@work
2022-09-28wifi: iwlwifi: Track scan_cmd allocation size explicitlyKees Cook
In preparation for reducing the use of ksize(), explicitly track the size of scan_cmd allocations. This also allows for noticing if the scan size changes unexpectedly. Note that using ksize() was already incorrect here, in the sense that ksize() would not match the actual allocation size, which would trigger future run-time allocation bounds checking. (In other words, memset() may know how large scan_cmd was allocated for, but ksize() will return the upper bounds of the actually allocated memory, causing a run-time warning about an overflow.) Cc: Gregory Greenman <gregory.greenman@intel.com> Cc: Kalle Valo <kvalo@kernel.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Luca Coelho <luciano.coelho@intel.com> Cc: Johannes Berg <johannes.berg@intel.com> Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Cc: Miri Korenblit <miriam.rachel.korenblit@intel.com> Cc: Ilan Peer <ilan.peer@intel.com> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220923220853.3302056-1-keescook@chromium.org
2022-09-27Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo
ath.git patches for v6.1. Major changes: ath11k * cold boot calibration support on WCN6750 * Target Wake Time (TWT) debugfs support for STA interface * support to connect to a non-transmit MBSSID AP profile * enable remain-on-channel support on WCN6750 * implement SRAM dump debugfs interface * enable threaded NAPI on all hardware * WoW support for WCN6750 * support to provide transmit power from firmware via nl80211 * support to get power save duration for each client * spectral scan support for 160 MHz wcn36xx * add SNR from a received frame as a source of system entropy
2022-09-27brcmfmac: Remove the call to "dtim_assoc" IOVARRamesh Rangavittal
When STA roams from one AP to another, after roam is complete, host driver tries to get TIM information from firmware. This is no longer supported in the firmware & hence, this call will always fail. This failure results in the below message being displayed on the console all the time when roam is done. ieee80211 phy0: brcmf_update_bss_info: wl dtim_assoc failed (-52) Changes ensure that the host driver will no longer try to get TIM information from firmware. Signed-off-by: Ramesh Rangavittal <ramesh.rangavittal@infineon.com> Signed-off-by: Chi-hsien Lin <chi-hsien.lin@infineon.com> Signed-off-by: Ian Lin <ian.lin@infineon.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220922104140.11889-5-ian.lin@infineon.com
2022-09-27brcmfmac: increase dcmd maximum buffer sizeLo(Double)Hsiang Lo
Increase dcmd maximum buffer size to match firmware configuration for new chips. Signed-off-by: Lo(Double)Hsiang Lo <double.lo@cypress.com> Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Ian Lin <ian.lin@infineon.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220922104140.11889-4-ian.lin@infineon.com
2022-09-27brcmfmac: Support 89459 pcieAlexander Prutskov
Adds support of 89459 chip pcie device and save restore support. Signed-off-by: Alexander Prutskov <alep@cypress.com> Signed-off-by: Joseph chuang <jiac@cypress.com> Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Ian Lin <ian.lin@infineon.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220922104140.11889-3-ian.lin@infineon.com
2022-09-27brcmfmac: increase default max WOWL patterns to 16Ryohei Kondo
4373 has support of 16 WOWL patterns thus increasing the default value Signed-off-by: Ryohei Kondo <ryohei.kondo@cypress.com> Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Ian Lin <ian.lin@infineon.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220922104140.11889-2-ian.lin@infineon.com
2022-09-27cw1200: fix incorrect check to determine if no element is found in listXiaomeng Tong
The bug is here: "} else if (item) {". The list iterator value will *always* be set and non-NULL by list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element is found in list. Use a new value 'iter' as the list iterator, while use the old value 'item' as a dedicated pointer to point to the found element, which 1. can fix this bug, due to now 'item' is NULL only if it's not found. 2. do not need to change all the uses of 'item' after the loop. 3. can also limit the scope of the list iterator 'iter' *only inside* the traversal loop by simply declaring 'iter' inside the loop in the future, as usage of the iterator outside of the list_for_each_entry is considered harmful. https://lkml.org/lkml/2022/2/17/1032 Fixes: a910e4a94f692 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets") Signed-off-by: Xiaomeng Tong <xiam0nd.tong@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220413091723.17596-1-xiam0nd.tong@gmail.com
2022-09-26wifi: ath11k: Fix deadlock during WoWLAN suspendBaochen Qiang
We are seeing system hangs during WoWLAN suspend, and get below two stacks: Stack1: [ffffb02cc1557b20] __schedule at ffffffff8bb10860 [ffffb02cc1557ba8] schedule at ffffffff8bb10f24 [ffffb02cc1557bb8] schedule_timeout at ffffffff8bb16d88 [ffffb02cc1557c30] wait_for_completion at ffffffff8bb11778 [ffffb02cc1557c78] __flush_work at ffffffff8b0b30cd [ffffb02cc1557cf0] __cancel_work_timer at ffffffff8b0b33ad [ffffb02cc1557d60] ath11k_mac_drain_tx at ffffffffc0c1f0ca [ath11k] [ffffb02cc1557d70] ath11k_wow_op_suspend at ffffffffc0c5201e [ath11k] [ffffb02cc1557da8] __ieee80211_suspend at ffffffffc11e2bd3 [mac80211] [ffffb02cc1557dd8] wiphy_suspend at ffffffffc0f901ac [cfg80211] [ffffb02cc1557e08] dpm_run_callback at ffffffff8b75118a [ffffb02cc1557e38] __device_suspend at ffffffff8b751630 [ffffb02cc1557e70] async_suspend at ffffffff8b7519ea [ffffb02cc1557e88] async_run_entry_fn at ffffffff8b0bf4ce [ffffb02cc1557ea8] process_one_work at ffffffff8b0b1a24 [ffffb02cc1557ee0] worker_thread at ffffffff8b0b1c4a [ffffb02cc1557f18] kthread at ffffffff8b0b9cb8 [ffffb02cc1557f50] ret_from_fork at ffffffff8b001d32 Stack2: [ffffb02cc00b7d18] __schedule at ffffffff8bb10860 [ffffb02cc00b7da0] schedule at ffffffff8bb10f24 [ffffb02cc00b7db0] schedule_preempt_disabled at ffffffff8bb112b4 [ffffb02cc00b7db8] __mutex_lock at ffffffff8bb127ea [ffffb02cc00b7e38] ath11k_mgmt_over_wmi_tx_work at ffffffffc0c1aa44 [ath11k] [ffffb02cc00b7ea8] process_one_work at ffffffff8b0b1a24 [ffffb02cc00b7ee0] worker_thread at ffffffff8b0b1c4a [ffffb02cc00b7f18] kthread at ffffffff8b0b9cb8 [ffffb02cc00b7f50] ret_from_fork at ffffffff8b001d32 From the first stack, ath11k_mac_drain_tx calls cancel_work_sync(&ar->wmi_mgmt_tx_work) and waits all packets to be sent out or dropped. However, we find from Stack2 that this work item is blocked because ar->conf_mutex is already held by ath11k_wow_op_suspend. Fix this issue by moving ath11k_mac_wait_tx_complete to the start of ath11k_wow_op_suspend where ar->conf_mutex has not been acquired. And this change also makes the logic in ath11k_wow_op_suspend match the logic in ath11k_mac_op_start and ath11k_mac_op_stop. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220919021435.2459-1-quic_bqiang@quicinc.com
2022-09-26wifi: ath11k: Remove redundant ath11k_mac_drain_txBaochen Qiang
ath11k_mac_drain_tx is already called in ath11k_mac_wait_tx_complete, no need to call it again. So remove it. This is found in code review. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220919020259.1746-1-quic_bqiang@quicinc.com
2022-09-26wifi: ath11k: Add spectral scan support for 160 MHzTamizh Chelvam Raja
There are two types of 160 MHz spectral scan support mentioned below 1. Fragmented approach 2. Single event approach In this fragmented approach, single 160 MHz will be split as two 80 MHz buffer. First fft sample buffer will contain spectral scan result of primary 80 MHz and the second fft sample buffer will contain secondary 80 MHz and here cfreq1 and cfreq2 will be mentioned. In case of 160 MHz on 36th channel will contain cfreq1 as 5210 and cfreq2 as 5290. Chipsets which support this approach are IPQ8074/IPQ6018. Replacing freq1 with freq2 in every secondary sepctral scan event to distinguish between two different 80 MHz spectral event data. In the 2nd approach each fft sample buffer will contain spectral scan result for whole 160 MHz by mentioning cfreq1 as 5250 which is center frequency of whole 160 MHz. Chipset which support this approach is QCN9074. Host will receive spectral event from target for every 5 fft samples. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01120-QCAHKSWPL-1 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01120-QCAHKSWP Signed-off-by: Tamizh Chelvam Raja <quic_tamizhr@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220725055001.15194-1-quic_tamizhr@quicinc.com
2022-09-26wifi: ath11k: Add support to get power save duration for each clientVenkateswara Naralasetty
Add support to get the following power save information through debugfs interface, * Current ps state of the peer * Time duration since the peer is in power save * Total duration of the peer spent in power save Above information is helpful in debugging the issues with power save clients. This patch also add trace log support for PS timekeeper to track the PS state change of the peers alongs with the peer MAC address and timestamp. Use the below commands to get the above power save information, To know the time_since_station_in_power_save: cat /sys/kernel/debug/ieee80211/phyX/netdev:wlanX/stations/ XX:XX:XX:XX:XX:XX/current_ps_duration To know power_save_duration: cat /sys/kernel/debug/ieee80211/phyX/netdev:wlanX/stations/ XX:XX:XX:XX:XX:XX/total_ps_duration To reset the power_save_duration of all stations connected to AP: echo 1 > /sys/kernel/debug/ieee80211/phyX/ath11k/reset_ps_duration To enable/disable the ps_timekeeper: echo Y > /sys/kernel/debug/ieee80211/phyX/ath11k/ps_timekeeper_enable Y = 1 to enable and Y = 0 to disable. To record PS timekeeer logs after enabling ps_timekeeper: trace-cmd record -e ath11k_ps_timekeeper Tested-on: Tested-on: IPQ8074 WLAN.HK.2.5.0.1-00991-QCAHKSWPL_SILICONZ-1 Signed-off-by: Venkateswara Naralasetty <quic_vnaralas@quicinc.com> Signed-off-by: Tamizh Chelvam Raja <quic_tamizhr@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220725054601.14719-1-quic_tamizhr@quicinc.com
2022-09-24wifi: ath11k: fix peer addition/deletion error on sta band migrationChristian 'Ansuel' Marangi
This patch try to fix the following error. Wed Jun 1 22:19:30 2022 kern.warn kernel: [ 119.561227] ath11k c000000.wifi: peer already added vdev id 0 req, vdev id 1 present Wed Jun 1 22:19:30 2022 kern.warn kernel: [ 119.561282] ath11k c000000.wifi: Failed to add peer: 28:c2:1f:xx:xx:xx for VDEV: 0 Wed Jun 1 22:19:30 2022 kern.warn kernel: [ 119.568053] ath11k c000000.wifi: Failed to add station: 28:c2:1f:xx:xx:xx for VDEV: 0 Wed Jun 1 22:19:31 2022 daemon.notice hostapd: wlan2: STA 28:c2:1f:xx:xx:xx IEEE 802.11: Could not add STA to kernel driver Wed Jun 1 22:19:31 2022 daemon.notice hostapd: wlan2: STA 28:c2:1f:xx:xx:xx IEEE 802.11: did not acknowledge authentication response Wed Jun 1 22:19:31 2022 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 28:c2:1f:xx:xx:xx Wed Jun 1 22:19:31 2022 daemon.info hostapd: wlan1: STA 28:c2:1f:xx:xx:xx IEEE 802.11: disassociated due to inactivity Wed Jun 1 22:19:32 2022 daemon.info hostapd: wlan1: STA 28:c2:1f:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE) To repro this: - Have 2 Wifi with the same bssid and pass on different band (2.4 and 5GHz) - Enable 802.11r Fast Transaction with same mobility domain - FT Protocol: FT over the Air From a openwrt system issue the command (with the correct mac) ubus call hostapd.wlan1 wnm_disassoc_imminent '{"addr":"28:C2:1F:xx:xx:xx"}' Notice the log printing the errors. The cause of this error has been investigated and we found that this is related to the WiFi Fast Transaction feature. We observed that this is triggered when the router tells the device to change band. In this case the device first auth to the other band and then the disconnect path from the prev band is triggered. This is problematic with the current rhash implementation since the addrs is used as key and the logic of "adding first, delete later" conflicts with the rhash logic. In fact peer addition will fail since the peer is already added and with that fixed a peer deletion will cause unitended effect by removing the peer just added. Current solution to this is to add additional logic to the peer delete, make sure we are deleting the correct peer taken from the rhash table (and fallback to the peer list) and for the peer add logic delete the peer entry for the rhash list before adding the new one (counting as an error only when a peer with the same vlan_id is asked to be added). With this change, a sta can correctly transition from 2.4GHz and 5GHZ with no drop and no error are printed. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1 Fixes: 7b0c70d92a43 ("ath11k: Add peer rhash table support") Signed-off-by: Christian 'Ansuel' Marangi <ansuelsmth@gmail.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220603164559.27769-1-ansuelsmth@gmail.com
2022-09-24wifi: rtw89: support for enable/disable MSDU aggregationKuan-Chung Chen
To enable/disable amsdu in set_tid_config, and currently only support to configure all tids (==0xff) for AMSDU, not individual tid. The command example is: iw wlan0 set tidconf tids 0xff amsdu off iw wlan0 set tidconf peer xx:xx:xx:xx:xx:xx tids 0xff amsdu on Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220922012737.15091-1-pkshih@realtek.com
2022-09-24wifi: rtw89: disable 26-tone RU HE TB PPDU transmissionsKuan-Chung Chen
Align with the spec of 802.11ax, follow the conditions for not responding with an HE TB PPDU. When there are OBSS that cannot interpret 26-tone RU transmissions, we should disable such transmissions. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220922012719.15037-1-pkshih@realtek.com
2022-09-24wifi: rtw89: support for processing P2P power savingDian-Syuan Yang
Support P2P client to process Notice of Absence (NoA) mechanism when it connects with P2P GO applying an NoA schedule. We define some action types including init, update, remove and terminate in h2c function to enable/disable NoA schedule. Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220922010435.12167-6-pkshih@realtek.com
2022-09-24wifi: rtw89: support WMM-PS in P2P GO modeDian-Syuan Yang
To handle a connected client using WMM-PS, the P2P GO also need to enable this power save mechanism. We add WIPHY_FLAG_AP_UAPSD flag to support it and define maximum number of buffered frames the WMM GO may deliver to the WMM client. Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220922010435.12167-5-pkshih@realtek.com