summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/ath
AgeCommit message (Collapse)AuthorFilesLines
2022-01-13Merge tag 'irq-msi-2022-01-13' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull MSI irq updates from Thomas Gleixner: "Rework of the MSI interrupt infrastructure. This is a treewide cleanup and consolidation of MSI interrupt handling in preparation for further changes in this area which are necessary to: - address existing shortcomings in the VFIO area - support the upcoming Interrupt Message Store functionality which decouples the message store from the PCI config/MMIO space" * tag 'irq-msi-2022-01-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (94 commits) genirq/msi: Populate sysfs entry only once PCI/MSI: Unbreak pci_irq_get_affinity() genirq/msi: Convert storage to xarray genirq/msi: Simplify sysfs handling genirq/msi: Add abuse prevention comment to msi header genirq/msi: Mop up old interfaces genirq/msi: Convert to new functions genirq/msi: Make interrupt allocation less convoluted platform-msi: Simplify platform device MSI code platform-msi: Let core code handle MSI descriptors bus: fsl-mc-msi: Simplify MSI descriptor handling soc: ti: ti_sci_inta_msi: Remove ti_sci_inta_msi_domain_free_irqs() soc: ti: ti_sci_inta_msi: Rework MSI descriptor allocation NTB/msi: Convert to msi_on_each_desc() PCI: hv: Rework MSI handling powerpc/mpic_u3msi: Use msi_for_each-desc() powerpc/fsl_msi: Use msi_for_each_desc() powerpc/pasemi/msi: Convert to msi_on_each_dec() powerpc/cell/axon_msi: Convert to msi_on_each_desc() powerpc/4xx/hsta: Rework MSI handling ...
2021-12-23Merge tag 'wireless-drivers-next-2021-12-23' of ↵Jakub Kicinski27-195/+1055
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for v5.17 Third set of patches for v5.17, and the final one if all goes well. We have Specific Absorption Rate (SAR) support for both mt76 and rtw88. Also iwlwifi should be now W=1 warning free. But otherwise nothing really special this time, business as usual. Major changes: mt76 * Specific Absorption Rate (SAR) support * mt7921: new PCI ids * mt7921: 160 MHz channel support iwlwifi * fix W=1 and sparse warnings * BNJ hardware support * add new killer device ids * support for Time-Aware-SAR (TAS) from the BIOS * Optimized Connectivity Experience (OCE) scan support rtw88 * hardware scan * Specific Absorption Rate (SAR) support ath11k * qca6390/wcn6855: report signal and tx bitrate * qca6390: rfkill support * qca6390/wcn6855: regdb.bin support ath5k * switch to rate table based lookup wilc1000 * spi: reset/enable GPIO support * tag 'wireless-drivers-next-2021-12-23' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next: (148 commits) mt76: mt7921: fix a possible race enabling/disabling runtime-pm wilc1000: Document enable-gpios and reset-gpios properties wilc1000: Add reset/enable GPIO support to SPI driver wilc1000: Convert static "chipid" variable to device-local variable rtw89: 8852a: correct bit definition of dfs_en rtw88: don't consider deep PS mode when transmitting packet ath11k: Fix unexpected return buffer manager error for QCA6390 ath11k: add support of firmware logging for WCN6855 ath11k: Fix napi related hang ath10k: replace strlcpy with strscpy rtw88: support SAR via kernel common API rtw88: 8822c: add ieee80211_ops::hw_scan iwlwifi: mei: wait before mapping the shared area iwlwifi: mei: clear the ownership when the driver goes down iwlwifi: yoyo: fix issue with new DBGI_SRAM region read. iwlwifi: fw: fix some scan kernel-doc iwlwifi: pcie: make sure prph_info is set when treating wakeup IRQ iwlwifi: mvm: remove card state notification code iwlwifi: mvm: drop too short packets silently iwlwifi: mvm: fix AUX ROC removal ... ==================== Link: https://lore.kernel.org/r/20211223141108.78808C36AE9@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-23codel: remove unnecessary pkt_sched.h includeJakub Kicinski1-0/+2
Commit d068ca2ae2e6 ("codel: split into multiple files") moved all Qdisc-related code to codel_qdisc.h, move the include of pkt_sched.h as well. This is similar to the previous commit, although we don't care as much about incremental builds after pkt_sched.h was touched itself it is included by net/sch_generic.h which is modified ~20 times a year. This decreases the incremental build size after touching pkt_sched.h from 1592 to 617 objects. Fix unmasked missing includes in WiFi drivers. Acked-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211221193941.3805147-2-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-23codel: remove unnecessary sock.h includeJakub Kicinski1-0/+2
Since sock.h is modified relatively often (60 times in the last 12 months) it seems worthwhile to decrease the incremental build work. CoDel's header includes net/inet_ecn.h which in turn includes net/sock.h. codel.h is itself included by mac80211 which is included by much of the WiFi stack and drivers. Removing the net/inet_ecn.h include from CoDel breaks the dependecy between WiFi and sock.h. Commit d068ca2ae2e6 ("codel: split into multiple files") moved all the code which actually needs ECN helpers out to net/codel_impl.h, the include can be moved there as well. This decreases the incremental build size after touching sock.h from 4999 objects to 4051 objects. Fix unmasked missing includes in WiFi drivers. Acked-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211221193941.3805147-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-22ath11k: Fix unexpected return buffer manager error for QCA6390Baochen Qiang2-2/+2
We are seeing below error on QCA6390: ... [70211.671189] ath11k_pci 0000:72:00.0: failed to parse rx error in wbm_rel ring desc -22 [70212.696154] ath11k_pci 0000:72:00.0: failed to parse rx error in wbm_rel ring desc -22 [70213.092941] ath11k_pci 0000:72:00.0: failed to parse rx error in wbm_rel ring desc -22 ... The reason is that, with commit 734223d78428 ("ath11k: change return buffer manager for QCA6390"), ath11k expects the return buffer manager (RBM) field of descriptor configured as HAL_RX_BUF_RBM_SW1_BM when parsing error frames from WBM2SW3_RELEASE ring. This is a wrong change cause the RBM field is set as HAL_RX_BUF_RBM_SW3_BM. The same issue also applies to REO2TCL ring though we have not got any error reported. Fix it by changing RBM from HAL_RX_BUF_RBM_SW1_BM to HAL_RX_BUF_RBM_SW3_BM for these two rings. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Fixes: 734223d78428 ("ath11k: change return buffer manager for QCA6390") Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211222013536.582527-1-quic_bqiang@quicinc.com
2021-12-22ath11k: add support of firmware logging for WCN6855Cheng Wang6-0/+151
Host enables WMI firmware logging feature via QMI message. Host receives firmware logging messages on WMI_DIAG_EVENTID, then sends logging messages to user space via event tracing infrastructure. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Cheng Wang <quic_chengwan@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211220121053.357087-1-quic_chengwan@quicinc.com
2021-12-22ath11k: Fix napi related hangBen Greear3-7/+19
Similar to the same bug in ath10k, a napi disable w/out it being enabled will hang forever. I believe I saw this while trying rmmod after driver had some failure on startup. Fix it by keeping state on whether napi is enabled or not. And, remove un-used napi pointer in ath11k driver base struct. Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20200903195254.29379-1-greearb@candelatech.com
2021-12-22ath10k: replace strlcpy with strscpyJason Wang1-3/+3
The strlcpy should not be used because it doesn't limit the source length. So that it will lead some potential bugs. But the strscpy doesn't require reading memory from the src string beyond the specified "count" bytes, and since the return value is easier to error-check than strlcpy()'s. In addition, the implementation is robust to the string changing out from underneath it, unlike the current strlcpy() implementation. Thus, replace strlcpy with strscpy. Signed-off-by: Jason Wang <wangborong@cdjrlc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211221070931.725720-1-wangborong@cdjrlc.com
2021-12-21Merge tag 'mac80211-next-for-net-next-2021-12-21' of ↵Jakub Kicinski2-7/+13
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== This time we have: * ndo_fill_forward_path support in mac80211, to let drivers use it * association comeback notification for userspace, to be able to react more sensibly to long delays * support for background radar detection hardware in some chipsets * SA Query Procedures offload on the AP side * more logging if we find problems with HT/VHT/HE * various cleanups and minor fixes Conflicts: net/wireless/reg.c: e08ebd6d7b90 ("cfg80211: Acquire wiphy mutex on regulatory work") 701fdfe348f7 ("cfg80211: Enable regulatory enforcement checks for drivers supporting mesh iface") https://lore.kernel.org/r/20211221111950.57ecc6a7@canb.auug.org.au drivers/net/wireless/ath/ath10k/wmi.c: 7f599aeccbd2 ("cfg80211: Use the HE operation IE to determine a 6GHz BSS channel") 3bf2537ec2e3 ("ath10k: drop beacon and probe response which leak from other channel") https://lore.kernel.org/r/20211221115004.1cd6b262@canb.auug.org.au * tag 'mac80211-next-for-net-next-2021-12-21' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next: (32 commits) cfg80211: Enable regulatory enforcement checks for drivers supporting mesh iface rfkill: allow to get the software rfkill state cfg80211: refactor cfg80211_get_ies_channel_number() nl82011: clarify interface combinations wrt. channels nl80211: Add support to offload SA Query procedures for AP SME device nl80211: Add support to set AP settings flags with single attribute mac80211: add more HT/VHT/HE state logging cfg80211: Use the HE operation IE to determine a 6GHz BSS channel cfg80211: rename offchannel_chain structs to background_chain to avoid confusion with ETSI standard mac80211: Notify cfg80211 about association comeback cfg80211: Add support for notifying association comeback mac80211: introduce channel switch disconnect function cfg80211: Fix order of enum nl80211_band_iftype_attr documentation cfg80211: simplify cfg80211_chandef_valid() mac80211: Remove a couple of obsolete TODO mac80211: fix FEC flag in radio tap header mac80211: use coarse boottime for airtime fairness code ieee80211: change HE nominal packet padding value defines cfg80211: use ieee80211_bss_get_elem() instead of _get_ie() mac80211: Use memset_after() to clear tx status ... ==================== Link: https://lore.kernel.org/r/20211221112532.28708-1-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-21ath11k: add regdb.bin download for regdb offloadWen Gong5-13/+52
The regdomain is self-managed type for ath11k, the regdomain info is reported from firmware, it is not from wireless regdb. Firmware fetch the regdomain info from board data file before. Currently most of the regdomain info has moved to another file regdb.bin from board data file for some chips such as QCA6390 and WCN6855, so the regdomain info left in board data file is not enough to support the feature which need more regdomain info. After download regdb.bin, firmware will fetch the regdomain info from regdb.bin instead of board data file and report to ath11k. If it does not have the file regdb.bin, it also can initialize wlan success and firmware then fetch regdomain info from board data file. Add download the regdb.bin before download board data for some specific chip which support supports_regdb in hardware parameters. download regdb.bin log: [430082.334162] ath11k_pci 0000:05:00.0: chip_id 0x2 chip_family 0xb board_id 0x106 soc_id 0x400c0200 [430082.334169] ath11k_pci 0000:05:00.0: fw_version 0x110c8b4c fw_build_timestamp 2021-10-25 07:41 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HSP.1.1-02892-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3 [430082.334414] ath11k_pci 0000:05:00.0: boot firmware request ath11k/WCN6855/hw2.0/regdb.bin size 24310 output of "iw reg get" global country US: DFS-FCC (2402 - 2472 @ 40), (N/A, 30), (N/A) (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS (5735 - 5835 @ 80), (N/A, 30), (N/A) (57240 - 63720 @ 2160), (N/A, 40), (N/A) phy#0 (self-managed) country US: DFS-FCC (2402 - 2472 @ 40), (6, 30), (N/A) (5170 - 5250 @ 80), (N/A, 24), (N/A), AUTO-BW (5250 - 5330 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW (5490 - 5730 @ 160), (N/A, 24), (0 ms), DFS, AUTO-BW (5735 - 5895 @ 160), (N/A, 30), (N/A), AUTO-BW (5945 - 7125 @ 160), (N/A, 24), (N/A), NO-OUTDOOR, AUTO-BW Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211220062355.17021-1-quic_wgong@quicinc.com
2021-12-20ath11k: add support for hardware rfkill for QCA6390Wen Gong7-0/+203
When hardware rfkill is enabled in the firmware it will report the capability via using WMI_SYS_CAP_INFO_RFKILL bit in the WMI_SERVICE_READY event to the host. ath11k will check the capability, and if it is enabled then ath11k will set the GPIO information to firmware using WMI_PDEV_SET_PARAM. When the firmware detects hardware rfkill is enabled by the user, it will report it via WMI_RFKILL_STATE_CHANGE_EVENTID. Once ath11k receives the event it will send wmi command WMI_PDEV_SET_PARAM to the firmware and also notifies cfg80211. This only enable rfkill feature for QCA6390, rfkill_pin is all initialized to 0 for other chips in ath11k_hw_params. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211217102334.14907-1-quic_wgong@quicinc.com
2021-12-20ath11k: report tx bitrate for iw wlan station dumpWen Gong10-133/+210
HTT_T2H_MSG_TYPE_PPDU_STATS_IND is a message which include the ppdu info, currently it is not report from firmware for ath11k, then the tx bitrate of "iw wlan0 station dump" always show an invalid value "tx bitrate: 6.0 MBit/s". To address the issue, this is to parse the info of tx complete report from firmware and indicate the tx rate to mac80211. After that, "iw wlan0 station dump" show the correct tx bit rate such as: tx bitrate: 78.0 MBit/s MCS 12 tx bitrate: 144.4 MBit/s VHT-MCS 7 short GI VHT-NSS 2 tx bitrate: 286.7 MBit/s HE-MCS 11 HE-NSS 2 HE-GI 0 HE-DCM 0 tx bitrate: 1921.5 MBit/s 160MHz HE-MCS 9 HE-NSS 2 HE-GI 0 HE-DCM 0 Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211217093722.5739-1-quic_wgong@quicinc.com
2021-12-20ath9k: Fix out-of-bound memcpy in ath9k_hif_usb_rx_streamZekun Shen1-0/+7
Large pkt_len can lead to out-out-bound memcpy. Current ath9k_hif_usb_rx_stream allows combining the content of two urb inputs to one pkt. The first input can indicate the size of the pkt. Any remaining size is saved in hif_dev->rx_remain_len. While processing the next input, memcpy is used with rx_remain_len. 4-byte pkt_len can go up to 0xffff, while a single input is 0x4000 maximum in size (MAX_RX_BUF_SIZE). Thus, the patch adds a check for pkt_len which must not exceed 2 * MAX_RX_BUG_SIZE. BUG: KASAN: slab-out-of-bounds in ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc] Read of size 46393 at addr ffff888018798000 by task kworker/0:1/23 CPU: 0 PID: 23 Comm: kworker/0:1 Not tainted 5.6.0 #63 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014 Workqueue: events request_firmware_work_func Call Trace: <IRQ> dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc] ? ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc] __kasan_report.cold+0x37/0x7c ? ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc] kasan_report+0xe/0x20 check_memory_region+0x15a/0x1d0 memcpy+0x20/0x50 ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc] ? hif_usb_mgmt_cb+0x2d9/0x2d9 [ath9k_htc] ? _raw_spin_lock_irqsave+0x7b/0xd0 ? _raw_spin_trylock_bh+0x120/0x120 ? __usb_unanchor_urb+0x12f/0x210 __usb_hcd_giveback_urb+0x1e4/0x380 usb_giveback_urb_bh+0x241/0x4f0 ? __hrtimer_run_queues+0x316/0x740 ? __usb_hcd_giveback_urb+0x380/0x380 tasklet_action_common.isra.0+0x135/0x330 __do_softirq+0x18c/0x634 irq_exit+0x114/0x140 smp_apic_timer_interrupt+0xde/0x380 apic_timer_interrupt+0xf/0x20 I found the bug using a custome USBFuzz port. It's a research work to fuzz USB stack/drivers. I modified it to fuzz ath9k driver only, providing hand-crafted usb descriptors to QEMU. After fixing the value of pkt_tag to ATH_USB_RX_STREAM_MODE_TAG in QEMU emulation, I found the KASAN report. The bug is triggerable whenever pkt_len is above two MAX_RX_BUG_SIZE. I used the same input that crashes to test the driver works when applying the patch. Signed-off-by: Zekun Shen <bruceshenzk@gmail.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/YXsidrRuK6zBJicZ@10-18-43-117.dynapool.wireless.nyu.edu
2021-12-20ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet()Tetsuo Handa3-0/+10
syzbot is reporting lockdep warning at ath9k_wmi_event_tasklet() followed by kernel panic at get_htc_epid_queue() from ath9k_htc_tx_get_packet() from ath9k_htc_txstatus() [1], for ath9k_wmi_event_tasklet(WMI_TXSTATUS_EVENTID) depends on spin_lock_init() from ath9k_init_priv() being already completed. Since ath9k_wmi_event_tasklet() is set by ath9k_init_wmi() from ath9k_htc_probe_device(), it is possible that ath9k_wmi_event_tasklet() is called via tasklet interrupt before spin_lock_init() from ath9k_init_priv() from ath9k_init_device() from ath9k_htc_probe_device() is called. Let's hold ath9k_wmi_event_tasklet(WMI_TXSTATUS_EVENTID) no-op until ath9k_tx_init() completes. Link: https://syzkaller.appspot.com/bug?extid=31d54c60c5b254d6f75b [1] Reported-by: syzbot <syzbot+31d54c60c5b254d6f75b@syzkaller.appspotmail.com> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Tested-by: syzbot <syzbot+31d54c60c5b254d6f75b@syzkaller.appspotmail.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/77b76ac8-2bee-6444-d26c-8c30858b8daa@i-love.sakura.ne.jp
2021-12-20ath9k_htc: fix NULL pointer dereference at ath9k_htc_rxep()Tetsuo Handa2-0/+9
syzbot is reporting lockdep warning followed by kernel panic at ath9k_htc_rxep() [1], for ath9k_htc_rxep() depends on ath9k_rx_init() being already completed. Since ath9k_htc_rxep() is set by ath9k_htc_connect_svc(WMI_BEACON_SVC) from ath9k_init_htc_services(), it is possible that ath9k_htc_rxep() is called via timer interrupt before ath9k_rx_init() from ath9k_init_device() is called. Since we can't call ath9k_init_device() before ath9k_init_htc_services(), let's hold ath9k_htc_rxep() no-op until ath9k_rx_init() completes. Link: https://syzkaller.appspot.com/bug?extid=4d2d56175b934b9a7bf9 [1] Reported-by: syzbot <syzbot+4d2d56175b934b9a7bf9@syzkaller.appspotmail.com> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Tested-by: syzbot <syzbot+4d2d56175b934b9a7bf9@syzkaller.appspotmail.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/2b88f416-b2cb-7a18-d688-951e6dc3fe92@i-love.sakura.ne.jp
2021-12-20ath11k: fix warning of RCU usage for ath11k_mac_get_arvif_by_vdev_id()Wen Gong1-0/+6
When enable more debug config, it happen below warning. It is because the caller does not add rcu_read_lock()/rcu_read_unlock() to wrap the rcu_dereference(). Add rcu_read_lock()/rcu_read_unlock() to wrap rcu_dereference(), then fixed it. [ 180.716604] ============================= [ 180.716670] WARNING: suspicious RCU usage [ 180.716734] 5.16.0-rc4-wt-ath+ #542 Not tainted [ 180.716895] ----------------------------- [ 180.716957] drivers/net/wireless/ath/ath11k/mac.c:506 suspicious rcu_dereference_check() usage! [ 180.717023] other info that might help us debug this: [ 180.717087] rcu_scheduler_active = 2, debug_locks = 1 [ 180.717151] no locks held by swapper/0/0. [ 180.717215] stack backtrace: [ 180.717279] CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 5.16.0-rc4-wt-ath+ #542 [ 180.717346] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021 [ 180.717411] Call Trace: [ 180.717475] <IRQ> [ 180.717541] dump_stack_lvl+0x57/0x7d [ 180.717610] ath11k_mac_get_arvif_by_vdev_id+0x1ab/0x2d0 [ath11k] [ 180.717694] ? ath11k_mac_get_arvif+0x140/0x140 [ath11k] [ 180.717798] ? ath11k_wmi_tlv_op_rx+0xc1b/0x2520 [ath11k] [ 180.717888] ? kfree+0xe8/0x2c0 [ 180.717959] ath11k_wmi_tlv_op_rx+0xc27/0x2520 [ath11k] [ 180.718038] ? ath11k_mgmt_rx_event+0xda0/0xda0 [ath11k] [ 180.718113] ? __lock_acquire+0xb72/0x1870 [ 180.718182] ? lockdep_hardirqs_on_prepare.part.0+0x18c/0x370 [ 180.718250] ? sched_clock_cpu+0x15/0x1b0 [ 180.718314] ? find_held_lock+0x33/0x110 [ 180.718381] ? __lock_release+0x4bd/0x9f0 [ 180.718447] ? lock_downgrade+0x130/0x130 [ 180.718517] ath11k_htc_rx_completion_handler+0x38f/0x5b0 [ath11k] [ 180.718596] ? __local_bh_enable_ip+0xa0/0x110 [ 180.718662] ath11k_ce_recv_process_cb+0x5ac/0x920 [ath11k] [ 180.718783] ? __lock_acquired+0x205/0x890 [ 180.718864] ? ath11k_ce_rx_post_pipe+0x970/0x970 [ath11k] [ 180.718949] ? __wake_up_bit+0x100/0x100 [ 180.719020] ath11k_pci_ce_tasklet+0x5f/0xf0 [ath11k_pci] [ 180.719085] ? tasklet_clear_sched+0x42/0xe0 [ 180.719148] tasklet_action_common.constprop.0+0x204/0x2f0 [ 180.719217] __do_softirq+0x276/0x86a [ 180.719281] ? __common_interrupt+0x92/0x1d0 [ 180.719350] __irq_exit_rcu+0x11c/0x180 [ 180.719418] irq_exit_rcu+0x5/0x20 [ 180.719482] common_interrupt+0xa4/0xc0 [ 180.719547] </IRQ> [ 180.719609] <TASK> [ 180.719671] asm_common_interrupt+0x1e/0x40 [ 180.719772] RIP: 0010:cpuidle_enter_state+0x1f3/0x8d0 [ 180.719838] Code: 00 41 8b 77 04 bf ff ff ff ff e8 78 f1 ff ff 31 ff e8 81 fa 52 fe 80 7c 24 08 00 0f 85 9e 01 00 00 e8 11 13 78 fe fb 45 85 e4 <0f> 88 8c 02 00 00 49 63 ec 48 8d 44 6d 00 48 8d 44 85 00 48 8d 7c [ 180.719909] RSP: 0018:ffffffffa4607dd0 EFLAGS: 00000202 [ 180.719982] RAX: 00000000002aea91 RBX: ffffffffa4a5fec0 RCX: 1ffffffff49ca501 [ 180.720047] RDX: 0000000000000000 RSI: ffffffffa3c6e4e0 RDI: ffffffffa3dcf2a0 [ 180.720110] RBP: 0000000000000002 R08: 0000000000000001 R09: ffffffffa4e54d17 [ 180.720173] R10: fffffbfff49ca9a2 R11: 0000000000000001 R12: 0000000000000002 [ 180.720236] R13: ffff8881169ccc04 R14: 0000002a13899598 R15: ffff8881169ccc00 [ 180.720321] cpuidle_enter+0x45/0xa0 [ 180.720413] cpuidle_idle_call+0x274/0x3f0 [ 180.720503] ? arch_cpu_idle_exit+0x30/0x30 [ 180.720869] ? tsc_verify_tsc_adjust+0x97/0x2e0 [ 180.720935] ? lockdep_hardirqs_off+0x90/0xd0 [ 180.721002] do_idle+0xe0/0x150 [ 180.721069] cpu_startup_entry+0x14/0x20 [ 180.721134] start_kernel+0x3a2/0x3c2 [ 180.721200] secondary_startup_64_no_verify+0xb0/0xbb [ 180.721274] </TASK> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-02892.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211217064132.30911-1-quic_wgong@quicinc.com
2021-12-20ath11k: add signal report to mac80211 for QCA6390 and WCN6855Wen Gong3-11/+61
IEEE80211_HW_USES_RSS is set in ath11k, then the device uses RSS and thus requires parallel RX which implies using per-CPU station statistics in sta_get_last_rx_stats() of mac80211. Currently signal is only set in ath11k_mgmt_rx_event(), and not set for RX data packet, then it show signal as 0 for iw command easily. Change to get signal from firmware and report to mac80211. For QCA6390 and WCN6855, the rssi value is already in dbm unit, so don't need to convert it again. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211216070535.31732-1-quic_wgong@quicinc.com
2021-12-20ath11k: report rssi of each chain to mac80211 for QCA6390/WCN6855Wen Gong11-34/+284
Command "iw wls1 station dump" does not show each chain's rssi currently. If the rssi of each chain from mon status which parsed in function ath11k_hal_rx_parse_mon_status_tlv() is invalid, then ath11k send wmi cmd WMI_REQUEST_STATS_CMDID with flag WMI_REQUEST_RSSI_PER_CHAIN_STAT to firmware, and parse the rssi of chain in wmi WMI_UPDATE_STATS_EVENTID, then report them to mac80211. WMI_REQUEST_STATS_CMDID is only sent when CONFIG_ATH11K_DEBUGFS is set, it is only called by ath11k_mac_op_sta_statistics(). It does not effect performance and power consumption. Because after STATION connected to AP, it is only called every 6 seconds by NetworkManager in below stack. [ 797.005587] CPU: 0 PID: 701 Comm: NetworkManager Tainted: G W OE 5.13.0-rc6-wt-ath+ #2 [ 797.005596] Hardware name: LENOVO 418065C/418065C, BIOS 83ET63WW (1.33 ) 07/29/2011 [ 797.005600] RIP: 0010:ath11k_mac_op_sta_statistics+0x2f/0x1b0 [ath11k] [ 797.005644] Code: 41 56 41 55 4c 8d aa 58 01 00 00 41 54 55 48 89 d5 53 48 8b 82 58 01 00 00 48 89 cb 4c 8b 70 20 49 8b 06 4c 8b a0 90 08 00 00 <0f> 0b 48 8b 82 b8 01 00 00 48 ba 00 00 00 00 01 00 00 00 48 89 81 [ 797.005651] RSP: 0018:ffffb1fc80a4b890 EFLAGS: 00010282 [ 797.005658] RAX: ffff8a5726200000 RBX: ffffb1fc80a4b958 RCX: ffffb1fc80a4b958 [ 797.005664] RDX: ffff8a5726a609f0 RSI: ffff8a581247f598 RDI: ffff8a5702878800 [ 797.005668] RBP: ffff8a5726a609f0 R08: 0000000000000000 R09: 0000000000000000 [ 797.005672] R10: 0000000000000000 R11: 0000000000000007 R12: 02dd68024f75f480 [ 797.005676] R13: ffff8a5726a60b48 R14: ffff8a5702879f40 R15: ffff8a5726a60000 [ 797.005681] FS: 00007f632c52a380(0000) GS:ffff8a583a200000(0000) knlGS:0000000000000000 [ 797.005687] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 797.005692] CR2: 00007fb025d69000 CR3: 00000001124f6005 CR4: 00000000000606f0 [ 797.005698] Call Trace: [ 797.005710] sta_set_sinfo+0xa7/0xb80 [mac80211] [ 797.005820] ieee80211_get_station+0x50/0x70 [mac80211] [ 797.005925] nl80211_get_station+0xd1/0x200 [cfg80211] [ 797.006045] genl_family_rcv_msg_doit.isra.15+0x111/0x140 [ 797.006059] genl_rcv_msg+0xe6/0x1e0 [ 797.006065] ? nl80211_dump_station+0x220/0x220 [cfg80211] [ 797.006223] ? nl80211_send_station.isra.72+0xf50/0xf50 [cfg80211] [ 797.006348] ? genl_family_rcv_msg_doit.isra.15+0x140/0x140 [ 797.006355] netlink_rcv_skb+0xb9/0xf0 [ 797.006363] genl_rcv+0x24/0x40 [ 797.006369] netlink_unicast+0x18e/0x290 [ 797.006375] netlink_sendmsg+0x30f/0x450 [ 797.006382] sock_sendmsg+0x5b/0x60 [ 797.006393] ____sys_sendmsg+0x219/0x240 [ 797.006403] ? copy_msghdr_from_user+0x5c/0x90 [ 797.006413] ? ____sys_recvmsg+0xf5/0x190 [ 797.006422] ___sys_sendmsg+0x88/0xd0 [ 797.006432] ? copy_msghdr_from_user+0x5c/0x90 [ 797.006443] ? ___sys_recvmsg+0x9e/0xd0 [ 797.006454] ? __fget_files+0x58/0x90 [ 797.006461] ? __fget_light+0x2d/0x70 [ 797.006466] ? do_epoll_wait+0xce/0x720 [ 797.006476] ? __sys_sendmsg+0x63/0xa0 [ 797.006485] __sys_sendmsg+0x63/0xa0 [ 797.006497] do_syscall_64+0x3c/0xb0 [ 797.006509] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 797.006519] RIP: 0033:0x7f632d99912d [ 797.006526] Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 ca ee ff ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 2f 44 89 c7 48 89 44 24 08 e8 fe ee ff ff 48 [ 797.006533] RSP: 002b:00007ffd80808c00 EFLAGS: 00000293 ORIG_RAX: 000000000000002e [ 797.006540] RAX: ffffffffffffffda RBX: 0000563dab99d840 RCX: 00007f632d99912d [ 797.006545] RDX: 0000000000000000 RSI: 00007ffd80808c50 RDI: 000000000000000b [ 797.006549] RBP: 00007ffd80808c50 R08: 0000000000000000 R09: 0000000000001000 [ 797.006552] R10: 0000563dab96f010 R11: 0000000000000293 R12: 0000563dab99d840 [ 797.006556] R13: 0000563dabbb28c0 R14: 00007f632dad4280 R15: 0000563dabab11c0 [ 797.006563] ---[ end trace c9dcf08920c9945c ]--- Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01230-QCAHSTSWPLZ_V2_TO_X86-1 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-02892.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211215090944.19729-1-quic_wgong@quicinc.com
2021-12-20ath5k: switch to rate table based lookupJonas Jelonek1-2/+48
Switching from legacy usage of ieee80211_get_tx_rates() lookup to direct rate table lookup in struct ieee80211_sta->rates. The current rate control API allows drivers to directly get rates from ieee80211_sta->rates. ath5k is currently one of the legacy drivers that perform translation/merge with the internal rate table via ieee80211_get_tx_rates provided by rate control API. For our upcoming changes to rate control API and the implementation of transmit power control, this patch changes the behaviour. The call to ieee80211_get_tx_rates and subsequent calls are also avoided. ath5k now directly reads rates from sta->rates into its internal rate table. Cause ath5k does not rely on the rate array in SKB->CB, this is not considered anymore except for the first entry (used for probing). Tested this on a PCEngines ALIX with CMP9-GP miniPCI wifi card (Atheros AR5213A). Generated traffic between AP and multiple STAs before and after applying the patch and simultaneously measured throughput and captured rc_stats. Comparison resulted in same rate selection and no performance loss between both runs. Co-developed-by: Thomas Huehn <thomas.huehn@hs-nordhausen.de> Signed-off-by: Thomas Huehn <thomas.huehn@hs-nordhausen.de> Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211215215042.637-1-jelonek.jonas@gmail.com
2021-12-17Merge tag 'wireless-drivers-next-2021-12-17' of ↵Jakub Kicinski46-326/+2074
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for v5.17 Second set of patches for v5.17, planning to do at least one more. Smaller new features, nothing special this time. Major changes: rtw88 * debugfs file to fix tx rate iwlwifi * support SAR GEO Offset Mapping (SGOM) via BIOS * support firmware API version 68 * add some new device IDs ath11k * support PCI devices with 1 MSI vector * WCN6855 hw2.1 support * 11d scan offload support * full monitor mode, only supported on QCN9074 * scan MAC address randomization support * reserved host DDR addresses from DT for PCI devices support ath9k * switch to rate table based lookup ath * extend South Korea regulatory domain support wcn36xx * beacon filter support * tag 'wireless-drivers-next-2021-12-17' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next: (129 commits) wcn36xx: Implement beacon filtering wcn36xx: Fix physical location of beacon filter comment wcn36xx: Fix beacon filter structure definitions ath11k: Use reserved host DDR addresses from DT for PCI devices dt: bindings: add new DT entry for ath11k PCI device support wilc1000: Improve WILC TX performance when power_save is off wl1251: specify max. IE length rsi: fix array out of bound wilc1000: Rename workqueue from "WILC_wq" to "NETDEV-wq" wilc1000: Rename tx task from "K_TXQ_TASK" to NETDEV-tx wilc1000: Rename irq handler from "WILC_IRQ" to netdev name wilc1000: Rename SPI driver from "WILC_SPI" to "wilc1000_spi" wilc1000: Fix spurious "FW not responding" error wilc1000: Remove misleading USE_SPI_DMA macro wilc1000: Fix missing newline in error message wilc1000: Fix copy-and-paste typo in wilc_set_mac_address rtw89: coex: Update COEX to 5.5.8 rtw89: coex: Cancel PS leaving while C2H comes rtw89: coex: Update BT counters while receiving report rtw89: coex: Define LPS state for BTC using ... ==================== Link: https://lore.kernel.org/r/20211217130952.34887C36AE9@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-17Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski1-1/+5
No conflicts. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-16wcn36xx: Implement beacon filteringBryan O'Donoghue4-0/+107
The prima driver facilitates the direct programming of beacon filter tables via SMD commands. The purpose of beacon filters is quote: /* When beacon filtering is enabled, firmware will * analyze the selected beacons received during BMPS, * and monitor any changes in the IEs as listed below. * The format of the table is: * - EID * - Check for IE presence * - Byte offset * - Byte value * - Bit Mask * - Byte reference */ The default filter table looks something like this: tBeaconFilterIe gaBcnFilterTable[12] = { { WLAN_EID_DS_PARAMS, 0u, { 0u, 0u, 0u, 0u } }, { WLAN_EID_ERP_INFO, 0u, { 0u, 0u, 248u, 0u } }, { WLAN_EID_EDCA_PARAM_SET, 0u, { 0u, 0u, 240u, 0u } }, { WLAN_EID_QOS_CAPA, 0u, { 0u, 0u, 240u, 0u } }, { WLAN_EID_CHANNEL_SWITCH, 1u, { 0u, 0u, 0u, 0u } }, { WLAN_EID_QUIET, 1u, { 0u, 0u, 0u, 0u } }, { WLAN_EID_HT_OPERATION, 0u, { 0u, 0u, 0u, 0u } }, { WLAN_EID_HT_OPERATION, 0u, { 1u, 0u, 248u, 0u } }, { WLAN_EID_HT_OPERATION, 0u, { 2u, 0u, 235u, 0u } }, { WLAN_EID_HT_OPERATION, 0u, { 5u, 0u, 253u, 0u } }, { WLAN_EID_PWR_CONSTRAINT, 0u, { 0u, 0u, 0u, 0u } }, { WLAN_EID_OPMODE_NOTIF, 0u, { 0u, 0u, 0u, 0u } } }; Add in an equivalent filter set as present in the prima Linux driver. For now omit the beacon filter "rem" command as the driver does not have an explicit call to that SMD command. The filter mask should only count when we are inside BMPS anyway. Replicating the ability to program the filter table gives us scope to add and remove elements in future. For now though this patch makes the rote-copy of the downstream Linux beacon filter table, which we can tweak as desired from now on. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211214134630.2214840-4-bryan.odonoghue@linaro.org
2021-12-16wcn36xx: Fix physical location of beacon filter commentBryan O'Donoghue1-3/+4
The comment in the header with respect to beacon filtering makes a reference to "the structure above" and "the structure below" which would be informative if the comment appeared in the right place but, it does not. Fix the comment location so that it a least makes sense w/r/t the physical location statements. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211214134630.2214840-3-bryan.odonoghue@linaro.org
2021-12-16wcn36xx: Fix beacon filter structure definitionsBryan O'Donoghue1-3/+3
The beacon filter structures need to be packed. Right now its fine because we don't yet use these structures so just pack them without marking it for backporting. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211214134630.2214840-2-bryan.odonoghue@linaro.org
2021-12-16ath11k: Use reserved host DDR addresses from DT for PCI devicesAnilkumar Kolli5-13/+101
Host DDR memory (contiguous 45 MB in mode-0 or 15 MB in mode-2) is reserved through DT entries for firmware usage. Send the base address from DT entries. If DT entry is available, PCI device will work with fixed_mem_region else host allocates multiple segments. IPQ8074 on HK10 board supports multiple PCI devices. IPQ8074 + QCN9074 is tested with this patch. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01838-QCAHKSWPL_SILICONZ-1 Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/1638789319-2950-2-git-send-email-akolli@codeaurora.org
2021-12-14ath11k: Change qcn9074 fw to operate in mode-2Seevalamuthu Mariappan4-5/+25
In mode-2 QCN9074 firmware uses 15MB of host memory and firmware request 1MB size segements in QMI, whereas in mode-0 firmware uses 45MB of host memory and each segment is of 2MB size. In mode-2 firmware operates with reduced number of vdevs and peers. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01838-QCAHKSWPL_SILICONZ-1 Signed-off-by: Seevalamuthu Mariappan <seevalam@codeaurora.org> Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211209104351.9811-3-kvalo@kernel.org
2021-12-14ath11k: add ab to TARGET_NUM_VDEVS & coKalle Valo4-22/+22
The next patch changes TARGET_NUM_VDEVS to be dynamic and need access to ab. Add ab separately to keep the next patch simple. Compile tested only. Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211209104351.9811-2-kvalo@kernel.org
2021-12-14ath11k: Fix a NULL pointer dereference in ath11k_mac_op_hw_scan()Zhou Qingyang1-2/+5
In ath11k_mac_op_hw_scan(), the return value of kzalloc() is directly used in memcpy(), which may lead to a NULL pointer dereference on failure of kzalloc(). Fix this bug by adding a check of arg.extraie.ptr. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_ATH11K=m show no new warnings, and our static analyzer no longer warns about this code. Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Zhou Qingyang <zhou1615@umn.edu> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211202155348.71315-1-zhou1615@umn.edu
2021-12-14Merge branch 'irq/urgent' into irq/msiThomas Gleixner1-1/+5
to pick up the PCI/MSI-x fixes. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2021-12-13ath11k: Fix deleting uninitialized kernel timer during fragment cache flushRameshkumar Sundaram1-1/+1
frag_timer will be created & initialized for stations when they associate and will be deleted during every key installation while flushing old fragments. For AP interface self peer will be created and Group keys will be installed for this peer, but there will be no real Station entry & hence frag_timer won't be created and initialized, deleting such uninitialized kernel timers causes below warnings and backtraces printed with CONFIG_DEBUG_OBJECTS_TIMERS enabled. [ 177.828008] ODEBUG: assert_init not available (active state 0) object type: timer_list hint: 0x0 [ 177.836833] WARNING: CPU: 3 PID: 188 at lib/debugobjects.c:508 debug_print_object+0xb0/0xf0 [ 177.845185] Modules linked in: ath11k_pci ath11k qmi_helpers qrtr_mhi qrtr ns mhi [ 177.852679] CPU: 3 PID: 188 Comm: hostapd Not tainted 5.14.0-rc3-32919-g4034139e1838-dirty #14 [ 177.865805] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [ 177.871804] pc : debug_print_object+0xb0/0xf0 [ 177.876155] lr : debug_print_object+0xb0/0xf0 [ 177.880505] sp : ffffffc01169b5a0 [ 177.883810] x29: ffffffc01169b5a0 x28: ffffff80081c2320 x27: ffffff80081c4078 [ 177.890942] x26: ffffff8003fe8f28 x25: ffffff8003de9890 x24: ffffffc01134d738 [ 177.898075] x23: ffffffc010948f20 x22: ffffffc010b2d2e0 x21: ffffffc01169b628 [ 177.905206] x20: ffffffc01134d700 x19: ffffffc010c80d98 x18: 00000000000003f6 [ 177.912339] x17: 203a657079742074 x16: 63656a626f202930 x15: 0000000000000152 [ 177.919471] x14: 0000000000000152 x13: 00000000ffffffea x12: ffffffc010d732e0 [ 177.926603] x11: 0000000000000003 x10: ffffffc010d432a0 x9 : ffffffc010d432f8 [ 177.933735] x8 : 000000000002ffe8 x7 : c0000000ffffdfff x6 : 0000000000000001 [ 177.940866] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000ffffffff [ 177.947997] x2 : ffffffc010c93240 x1 : ffffff80023624c0 x0 : 0000000000000054 [ 177.955130] Call trace: [ 177.957567] debug_print_object+0xb0/0xf0 [ 177.961570] debug_object_assert_init+0x124/0x178 [ 177.966269] try_to_del_timer_sync+0x1c/0x70 [ 177.970536] del_timer_sync+0x30/0x50 [ 177.974192] ath11k_peer_frags_flush+0x34/0x68 [ath11k] [ 177.979439] ath11k_mac_op_set_key+0x1e4/0x338 [ath11k] [ 177.984673] ieee80211_key_enable_hw_accel+0xc8/0x3d0 [ 177.989722] ieee80211_key_replace+0x360/0x740 [ 177.994160] ieee80211_key_link+0x16c/0x210 [ 177.998337] ieee80211_add_key+0x138/0x338 [ 178.002426] nl80211_new_key+0xfc/0x258 [ 178.006257] genl_family_rcv_msg_doit.isra.17+0xd8/0x120 [ 178.011565] genl_rcv_msg+0xd8/0x1c8 [ 178.015134] netlink_rcv_skb+0x38/0xf8 [ 178.018877] genl_rcv+0x34/0x48 [ 178.022012] netlink_unicast+0x174/0x230 [ 178.025928] netlink_sendmsg+0x188/0x388 [ 178.029845] ____sys_sendmsg+0x218/0x250 [ 178.033763] ___sys_sendmsg+0x68/0x90 [ 178.037418] __sys_sendmsg+0x44/0x88 [ 178.040988] __arm64_sys_sendmsg+0x20/0x28 [ 178.045077] invoke_syscall.constprop.5+0x54/0xe0 [ 178.049776] do_el0_svc+0x74/0xc0 [ 178.053084] el0_svc+0x10/0x18 [ 178.056133] el0t_64_sync_handler+0x88/0xb0 [ 178.060310] el0t_64_sync+0x148/0x14c [ 178.063966] ---[ end trace 8a5cf0bf9d34a058 ]--- Add changes to not to delete frag timer for peers during group key installation. Tested on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01092-QCAHKSWPL_SILICONZ-1 Fixes: c3944a562102 ("ath11k: Clear the fragment cache during key install") Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/1639071421-25078-1-git-send-email-quic_ramess@quicinc.com
2021-12-13ath11k: Avoid false DEADLOCK warning reported by lockdepBaochen Qiang2-0/+24
With CONFIG_LOCKDEP=y and CONFIG_DEBUG_SPINLOCK=y, lockdep reports below warning: [ 166.059415] ============================================ [ 166.059416] WARNING: possible recursive locking detected [ 166.059418] 5.15.0-wt-ath+ #10 Tainted: G W O [ 166.059420] -------------------------------------------- [ 166.059421] kworker/0:2/116 is trying to acquire lock: [ 166.059423] ffff9905f2083160 (&srng->lock){+.-.}-{2:2}, at: ath11k_hal_reo_cmd_send+0x20/0x490 [ath11k] [ 166.059440] but task is already holding lock: [ 166.059442] ffff9905f2083230 (&srng->lock){+.-.}-{2:2}, at: ath11k_dp_process_reo_status+0x95/0x2d0 [ath11k] [ 166.059491] other info that might help us debug this: [ 166.059492] Possible unsafe locking scenario: [ 166.059493] CPU0 [ 166.059494] ---- [ 166.059495] lock(&srng->lock); [ 166.059498] lock(&srng->lock); [ 166.059500] *** DEADLOCK *** [ 166.059501] May be due to missing lock nesting notation [ 166.059502] 3 locks held by kworker/0:2/116: [ 166.059504] #0: ffff9905c0081548 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1f6/0x660 [ 166.059511] #1: ffff9d2400a5fe68 ((debug_obj_work).work){+.+.}-{0:0}, at: process_one_work+0x1f6/0x660 [ 166.059517] #2: ffff9905f2083230 (&srng->lock){+.-.}-{2:2}, at: ath11k_dp_process_reo_status+0x95/0x2d0 [ath11k] [ 166.059532] stack backtrace: [ 166.059534] CPU: 0 PID: 116 Comm: kworker/0:2 Kdump: loaded Tainted: G W O 5.15.0-wt-ath+ #10 [ 166.059537] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0059.2019.1112.1124 11/12/2019 [ 166.059539] Workqueue: events free_obj_work [ 166.059543] Call Trace: [ 166.059545] <IRQ> [ 166.059547] dump_stack_lvl+0x56/0x7b [ 166.059552] __lock_acquire+0xb9a/0x1a50 [ 166.059556] lock_acquire+0x1e2/0x330 [ 166.059560] ? ath11k_hal_reo_cmd_send+0x20/0x490 [ath11k] [ 166.059571] _raw_spin_lock_bh+0x33/0x70 [ 166.059574] ? ath11k_hal_reo_cmd_send+0x20/0x490 [ath11k] [ 166.059584] ath11k_hal_reo_cmd_send+0x20/0x490 [ath11k] [ 166.059594] ath11k_dp_tx_send_reo_cmd+0x3f/0x130 [ath11k] [ 166.059605] ath11k_dp_rx_tid_del_func+0x221/0x370 [ath11k] [ 166.059618] ath11k_dp_process_reo_status+0x22f/0x2d0 [ath11k] [ 166.059632] ? ath11k_dp_service_srng+0x2ea/0x2f0 [ath11k] [ 166.059643] ath11k_dp_service_srng+0x2ea/0x2f0 [ath11k] [ 166.059655] ath11k_pci_ext_grp_napi_poll+0x1c/0x70 [ath11k_pci] [ 166.059659] __napi_poll+0x28/0x230 [ 166.059664] net_rx_action+0x285/0x310 [ 166.059668] __do_softirq+0xe6/0x4d2 [ 166.059672] irq_exit_rcu+0xd2/0xf0 [ 166.059675] common_interrupt+0xa5/0xc0 [ 166.059678] </IRQ> [ 166.059679] <TASK> [ 166.059680] asm_common_interrupt+0x1e/0x40 [ 166.059683] RIP: 0010:_raw_spin_unlock_irqrestore+0x38/0x70 [ 166.059686] Code: 83 c7 18 e8 2a 95 43 ff 48 89 ef e8 22 d2 43 ff 81 e3 00 02 00 00 75 25 9c 58 f6 c4 02 75 2d 48 85 db 74 01 fb bf 01 00 00 00 <e8> 63 2e 40 ff 65 8b 05 8c 59 97 5c 85 c0 74 0a 5b 5d c3 e8 00 6a [ 166.059689] RSP: 0018:ffff9d2400a5fca0 EFLAGS: 00000206 [ 166.059692] RAX: 0000000000000002 RBX: 0000000000000200 RCX: 0000000000000006 [ 166.059694] RDX: 0000000000000000 RSI: ffffffffa404879b RDI: 0000000000000001 [ 166.059696] RBP: ffff9905c0053000 R08: 0000000000000001 R09: 0000000000000001 [ 166.059698] R10: ffff9d2400a5fc50 R11: 0000000000000001 R12: ffffe186c41e2840 [ 166.059700] R13: 0000000000000001 R14: ffff9905c78a1c68 R15: 0000000000000001 [ 166.059704] free_debug_processing+0x257/0x3d0 [ 166.059708] ? free_obj_work+0x1f5/0x250 [ 166.059712] __slab_free+0x374/0x5a0 [ 166.059718] ? kmem_cache_free+0x2e1/0x370 [ 166.059721] ? free_obj_work+0x1f5/0x250 [ 166.059724] kmem_cache_free+0x2e1/0x370 [ 166.059727] free_obj_work+0x1f5/0x250 [ 166.059731] process_one_work+0x28b/0x660 [ 166.059735] ? process_one_work+0x660/0x660 [ 166.059738] worker_thread+0x37/0x390 [ 166.059741] ? process_one_work+0x660/0x660 [ 166.059743] kthread+0x176/0x1a0 [ 166.059746] ? set_kthread_struct+0x40/0x40 [ 166.059749] ret_from_fork+0x22/0x30 [ 166.059754] </TASK> Since these two lockes are both initialized in ath11k_hal_srng_setup, they are assigned with the same key. As a result lockdep suspects that the task is trying to acquire the same lock (due to same key) while already holding it, and thus reports the DEADLOCK warning. However as they are different spinlock instances, the warning is false positive. On the other hand, even no dead lock indeed, this is a major issue for upstream regression testing as it disables lockdep functionality. Fix it by assigning separate lock class key for each srng->lock. 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/20211209011949.151472-1-quic_bqiang@quicinc.com
2021-12-13ath11k: set DTIM policy to stick mode for station interfaceCarl Huang2-0/+14
Set DTIM policy to DTIM stick mode, so station follows AP DTIM interval rather than listen interval which is set in peer assoc cmd. DTIM stick mode is more preferred per firmware team request. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Carl Huang <quic_cjhuang@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/1638948694-15582-1-git-send-email-quic_cjhuang@quicinc.com
2021-12-13ath11k: support MAC address randomization in scanCarl Huang3-1/+58
The driver reports NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR capability to upper layer based on the service bit firmware reported. Driver sets the spoofed flag in scan_ctrl_flag to firmware if upper layer has enabled this feature in scan request. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Carl Huang <quic_cjhuang@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/1638948007-9609-1-git-send-email-quic_cjhuang@quicinc.com
2021-12-13ath10k: wmi: remove array of flexible structuresKalle Valo1-1/+3
I updated to sparse v0.6.4 and it warns: drivers/net/wireless/ath/ath10k/wmi.c: note: in included file (through drivers/net/wireless/ath/ath10k/core.h): drivers/net/wireless/ath/ath10k/wmi.h:3481:34: warning: array of flexible structures Fix it by changing the type to u8 array, in struct wmi_phyerr_hdr_arg it's stored as a void pointer anyway. Compile tested only. Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211209091545.6098-2-kvalo@kernel.org
2021-12-13ath10k: htt: remove array of flexible structuresKalle Valo1-110/+0
I updated to sparse v0.6.4 and it warns: drivers/net/wireless/ath/ath10k/hw.c: note: in included file (through drivers/net/wireless/ath/ath10k/core.h): drivers/net/wireless/ath/ath10k/htt.h:1503:41: warning: array of flexible structures drivers/net/wireless/ath/ath10k/htt_rx.c: note: in included file (through drivers/net/wireless/ath/ath10k/core.h): drivers/net/wireless/ath/ath10k/htt.h:1503:41: warning: array of flexible structures The structure is unused in ath10k so let's just remove it. Compile tested only. Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211209091545.6098-1-kvalo@kernel.org
2021-12-09bus: mhi: core: Add support for forced PM resumeLoic Poulain1-1/+5
For whatever reason, some devices like QCA6390, WCN6855 using ath11k are not in M3 state during PM resume, but still functional. The mhi_pm_resume should then not fail in those cases, and let the higher level device specific stack continue resuming process. Add an API mhi_pm_resume_force(), to force resuming irrespective of the current MHI state. This fixes a regression with non functional ath11k WiFi after suspend/resume cycle on some machines. Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=214179 Link: https://lore.kernel.org/regressions/871r5p0x2u.fsf@codeaurora.org/ Fixes: 020d3b26c07a ("bus: mhi: Early MHI resume failure in non M3 state") Cc: stable@vger.kernel.org #5.13 Reported-by: Kalle Valo <kvalo@codeaurora.org> Reported-by: Pengyu Ma <mapengyu@gmail.com> Tested-by: Kalle Valo <kvalo@kernel.org> Acked-by: Kalle Valo <kvalo@kernel.org> Signed-off-by: Loic Poulain <loic.poulain@linaro.org> [mani: Switched to API, added bug report, reported-by tags and CCed stable] Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20211209131633.4168-1-manivannan.sadhasivam@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-09genirq/msi, treewide: Use a named struct for PCI/MSI attributesThomas Gleixner1-1/+1
The unnamed struct sucks and is in the way of further cleanups. Stick the PCI related MSI data into a real data structure and cleanup all users. No functional change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211206210224.374863119@linutronix.de
2021-12-09ath10k: drop beacon and probe response which leak from other channelWen Gong1-1/+26
When scan request on channel 1, it also receive beacon from other channels, and the beacon also indicate to mac80211 and wpa_supplicant, and then the bss info appears in radio measurement report of radio measurement sent from wpa_supplicant, thus lead RRM case fail. This is to drop the beacon and probe response which is not the same channel of scanning. Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00049 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211208061752.16564-1-quic_wgong@quicinc.com
2021-12-09ath11k: add spectral/CFR buffer validation supportVenkateswara Naralasetty3-0/+46
Currently there is no validation on the spectral/CFR report over the db ring buffers from the hardware. Improper/incomplete DMA by the target can result in invalid data received by host. Due to this we may populate incorrect data to user space. This buffer validation support fix this issues by filling some magic value in the buffer during buffer replenish and check for the magic value in the buffer received by the target. If host detect magic value in the received buffer it will drop the buffer. Tested-on: IPQ8074 WLAN.HK.2.4.0.1-01467-QCAHKSWPL_SILICONZ-1 Signed-off-by: Venkateswara Naralasetty <quic_vnaralas@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/1637312901-10279-2-git-send-email-quic_vnaralas@quicinc.com
2021-12-09ath11k: Process full monitor mode rx supportAnilkumar Kolli3-3/+433
In full monitor mode, monitor destination ring is read before monitor status ring. mon_dst_ring has ppdu id, reap till the end of PPDU. Add all the MPDUs to list. Start processing the status ring, if PPDU id in status ring is lagging behind, reap the status ring, once the PPDU ID matches, deliver the MSDU to upper layer. If status PPDU id leading, reap the mon_dst_ring. The advantage with full monitor mode is hardware has status buffers available for all the MPDUs in mon_dst_ring, which makes it possible to deliver more frames to be seen on sniffer. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01734-QCAHKSWPL_SILICONZ-1 Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/1638881695-22155-4-git-send-email-akolli@codeaurora.org
2021-12-09ath11k: add software monitor ring descriptor for full monitorAnilkumar Kolli3-0/+80
In full monitor mode, monitor destination ring is read in software monitor ring descriptor format instead of reo_entrance_ring format. Add new sw_mon_ring descriptor. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01734-QCAHKSWPL_SILICONZ-1 Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/1638881695-22155-3-git-send-email-akolli@codeaurora.org
2021-12-09ath11k: Add htt cmd to enable full monitor modeAnilkumar Kolli5-0/+84
A new hw_param full_monitor_mode is added to enable full monitor support for QCN9074. HTT_H2T_MSG_TYPE_RX_FULL_MONITOR_MODE cmd is sent to FW to enable the full monitor mode. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01734-QCAHKSWPL_SILICONZ-1 Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/1638881695-22155-2-git-send-email-akolli@codeaurora.org
2021-12-09ath6kl: Use struct_group() to avoid size-mismatched castingKees Cook2-15/+19
In builds with -Warray-bounds, casts from smaller objects to larger objects will produce warnings. These can be overly conservative, but since -Warray-bounds has been finding legitimate bugs, it is desirable to turn it on globally. Instead of casting a u32 to a larger object, redefine the u32 portion of the header to a separate struct that can be used for both u32 operations and the distinct header fields. Silences this warning: drivers/net/wireless/ath/ath6kl/htc_mbox.c: In function 'htc_wait_for_ctrl_msg': drivers/net/wireless/ath/ath6kl/htc_mbox.c:2275:20: error: array subscript 'struct htc_frame_hdr[0]' is partly outside array bounds of 'u32[1]' {aka 'unsigned int[1]'} [-Werror=array-bounds] 2275 | if (htc_hdr->eid != ENDPOINT_0) | ^~ drivers/net/wireless/ath/ath6kl/htc_mbox.c:2264:13: note: while referencing 'look_ahead' 2264 | u32 look_ahead; | ^~~~~~~~~~ This change results in no executable instruction differences. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211207063538.2767954-1-keescook@chromium.org
2021-12-09ath11k: enable IEEE80211_HW_SINGLE_SCAN_ON_ALL_BANDS for WCN6855Wen Gong1-0/+3
Currently mac80211 will send 3 scan request for each scan of WCN6855, they are 2.4 GHz/5 GHz/6 GHz band scan. Firmware of WCN6855 will cache the RNR IE(Reduced Neighbor Report element) which exist in the beacon of 2.4 GHz/5 GHz of the AP which is co-located with 6 GHz, and then use the cache to scan in 6 GHz band scan if the 6 GHz scan is in the same scan with the 2.4 GHz/5 GHz band, this will helpful to search more AP of 6 GHz. Also it will decrease the time cost of scan because firmware will use dual-band scan for the 2.4 GHz/5 GHz, it means the 2.4 GHz and 5 GHz scans are doing simultaneously. Set the flag IEEE80211_HW_SINGLE_SCAN_ON_ALL_BANDS for WCN6855 since it supports 2.4 GHz/5 GHz/6 GHz and it is single pdev which means all the 2.4 GHz/5 GHz/6 GHz exist in the same wiphy/ieee80211_hw. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Tested-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211129101309.2931-1-quic_wgong@quicinc.com
2021-12-09ath11k: Fix buffer overflow when scanning with extraieSven Eckelmann1-3/+3
If cfg80211 is providing extraie's for a scanning process then ath11k will copy that over to the firmware. The extraie.len is a 32 bit value in struct element_info and describes the amount of bytes for the vendor information elements. The WMI_TLV packet is having a special WMI_TAG_ARRAY_BYTE section. This section can have a (payload) length up to 65535 bytes because the WMI_TLV_LEN can store up to 16 bits. The code was missing such a check and could have created a scan request which cannot be parsed correctly by the firmware. But the bigger problem was the allocation of the buffer. It has to align the TLV sections by 4 bytes. But the code was using an u8 to store the newly calculated length of this section (with alignment). And the new calculated length was then used to allocate the skbuff. But the actual code to copy in the data is using the extraie.len and not the calculated "aligned" length. The length of extraie with IEEE80211_HW_SINGLE_SCAN_ON_ALL_BANDS enabled was 264 bytes during tests with a QCA Milan card. But it only allocated 8 bytes (264 bytes % 256) for it. As consequence, the code to memcpy the extraie into the skb was then just overwriting data after skb->end. Things like shinfo were therefore corrupted. This could usually be seen by a crash in skb_zcopy_clear which tried to call a ubuf_info callback (using a bogus address). Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-02892.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Cc: stable@vger.kernel.org Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211207142913.1734635-1-sven@narfation.org
2021-12-08ath10k: fix scan abort when duration is set for hw scanWen Gong1-4/+5
When request scan with duration 120ms on channel 1, it failed with scan abort easily. Because scan_timeout is set to 130ms for the scan in ath10k_hw_scan(), and timed out before scan complete, so lead scan abort. failed log of ath10k: 2021-04-14T14:43:29.936058Z DEBUG kernel: [67384.594846] ath10k_sdio mmc1:0001:1: wmi tlv start scan 2021-04-14T14:43:29.937896Z DEBUG kernel: [67384.595820] ath10k_sdio mmc1:0001:1: scan event started type 1 reason 7 freq 2437 req_id 40961 scan_id 40960 vdev_id 0 state starting (1) 2021-04-14T14:43:29.938357Z DEBUG kernel: [67384.596761] ath10k_sdio mmc1:0001:1: scan event bss channel type 4 reason 7 freq 2437 req_id 40961 scan_id 40960 vdev_id 0 state running (2) 2021-04-14T14:43:29.992497Z DEBUG kernel: [67384.651013] ath10k_sdio mmc1:0001:1: scan event foreign channel type 8 reason 7 freq 2412 req_id 40961 scan_id 40960 vdev_id 0 state running (2) 2021-04-14T14:43:30.063530Z DEBUG kernel: [67384.722139] ath10k_sdio mmc1:0001:1: wmi tlv stop scan 2021-04-14T14:43:30.066592Z DEBUG kernel: [67384.724403] ath10k_sdio mmc1:0001:1: scan event completed [cancelled] type 2 reason 1 freq 2412 req_id 40961 scan_id 40960 vdev_id 0 state aborting (3) failed log of wpa_supplicant: 2021-04-14T14:43:29.981842Z DEBUG wpa_supplicant[887]: wlan0: nl80211: scan request 2021-04-14T14:43:29.981988Z DEBUG wpa_supplicant[887]: nl80211: Passive scan requested 2021-04-14T14:43:29.982202Z DEBUG wpa_supplicant[887]: nl80211: Add NL80211_SCAN_FLAG_FLUSH 2021-04-14T14:43:29.982339Z DEBUG wpa_supplicant[887]: Scan requested (ret=0) - scan timeout 30 seconds 2021-04-14T14:43:29.982491Z DEBUG wpa_supplicant[887]: nl80211: Drv Event 33 (NL80211_CMD_TRIGGER_SCAN) received for wlan0 2021-04-14T14:43:29.982629Z DEBUG wpa_supplicant[887]: wlan0: nl80211: Scan trigger 2021-04-14T14:43:29.982779Z DEBUG wpa_supplicant[887]: wlan0: Event SCAN_STARTED (47) received 2021-04-14T14:43:29.982920Z DEBUG wpa_supplicant[887]: wlan0: Own scan request started a scan in 0.000175 seconds 2021-04-14T14:43:30.082401Z DEBUG wpa_supplicant[887]: nl80211: Drv Event 35 (NL80211_CMD_SCAN_ABORTED) received for wlan0 2021-04-14T14:43:30.082704Z DEBUG wpa_supplicant[887]: wlan0: nl80211: Scan aborted 2021-04-14T14:43:30.082905Z DEBUG wpa_supplicant[887]: nl80211: Scan included frequencies: 2412 2021-04-14T14:43:30.083123Z DEBUG wpa_supplicant[887]: wlan0: Event SCAN_RESULTS (3) received 2021-04-14T14:43:30.083310Z DEBUG wpa_supplicant[887]: wlan0: Scan completed in 0.128655 seconds This is to increase the scan_timeout with 200ms for this situation, then scan will not timed out for this situation. Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00049 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211026025902.26621-1-quic_wgong@quicinc.com
2021-12-08ath10k: Fix tx hangingSebastian Gottschall2-2/+3
While running stress tests in roaming scenarios (switching ap's every 5 seconds, we discovered a issue which leads to tx hangings of exactly 5 seconds while or after scanning for new accesspoints. We found out that this hanging is triggered by ath10k_mac_wait_tx_complete since the empty_tx_wq was not wake when the num_tx_pending counter reaches zero. To fix this, we simply move the wake_up call to htt_tx_dec_pending, since this call was missed on several locations within the ath10k code. Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20210505085806.11474-1-s.gottschall@dd-wrt.com
2021-12-08ath: regdom: extend South Korea regulatory domain supportPeter Oh2-0/+4
South Korea manufacturer, Samsung, has extended South Korea regulatory domain pair with 0x5F and has used it for their devices such as Samsung Galaxy book. Hence add support 0x5F as a regulatory domain pair along with extended country code, 413. Signed-off-by: Peter Oh <ebmajor.dev@gmail.com> Signed-off-by: Andreas Tepe <andreas.tepe@debitel.net> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20210915185611.6195-1-ebmajor.dev@gmail.com
2021-12-08ath11k: add wait operation for tx management packets for flush from mac80211Wen Gong4-10/+55
In ath11k, tx of management packet is doing in a work queue. Sometimes the workqueue does not finish tx immediately, then it lead after the next step of vdev delete finished, it start to send the management packet to firmware and lead firmware crash. ieee80211_set_disassoc() have logic of ieee80211_flush_queues() after it send_deauth_disassoc() to ath11k, its purpose is make sure the deauth was actually sent, so it need to change ath11k to match the purpose of mac80211. To address these issue wait for tx mgmt as well as tx data packets. dmesg log of connect/disconnect to AP: [ 307.522226] wls1: authenticate with 62:66:e4:e9:6a:a9 [ 307.586565] wls1: send auth to 62:66:e4:e9:6a:a9 (try 1/3) [ 307.586581] ath11k_pci 0000:05:00.0: mac tx mgmt frame, buf id 0 [ 307.586922] ath11k_pci 0000:05:00.0: mac tx mgmt frame, vdev_id 0 [ 307.590179] ath11k_pci 0000:05:00.0: wmi mgmt tx comp pending 0 desc id 0 [ 307.590181] ath11k_pci 0000:05:00.0: mgmt tx compl ev pdev_id 2, desc_id 0, status 0 [ 307.598699] wls1: authenticated [ 307.599483] wls1: associate with 62:66:e4:e9:6a:a9 (try 1/3) [ 307.599506] ath11k_pci 0000:05:00.0: mac tx mgmt frame, buf id 0 [ 307.599519] ath11k_pci 0000:05:00.0: mac tx mgmt frame, vdev_id 0 [ 307.603059] ath11k_pci 0000:05:00.0: wmi mgmt tx comp pending 0 desc id 0 [ 307.603063] ath11k_pci 0000:05:00.0: mgmt tx compl ev pdev_id 2, desc_id 0, status 0 [ 307.637105] wls1: associated [ 317.365239] wls1: deauthenticating from 62:66:e4:e9:6a:a9 by local choice (Reason: 3=DEAUTH_LEAVING) [ 317.368104] ath11k_pci 0000:05:00.0: mac tx mgmt frame, buf id 0 [ 317.372622] ath11k_pci 0000:05:00.0: mac tx mgmt frame, vdev_id 0 [ 317.378320] ath11k_pci 0000:05:00.0: wmi mgmt tx comp pending 0 desc id 0 [ 317.378330] ath11k_pci 0000:05:00.0: mgmt tx compl ev pdev_id 2, desc_id 0, status 0 [ 317.378359] ath11k_pci 0000:05:00.0: mac mgmt tx flush mgmt pending 0 [ 317.421066] ath11k_pci 0000:05:00.0: mac mgmt tx flush mgmt pending 0 [ 317.421427] ath11k_pci 0000:05:00.0: mac remove interface (vdev 0) Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01230-QCAHSTSWPLZ_V2_TO_X86-1 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211202063705.14321-1-quic_wgong@quicinc.com
2021-12-08carl9170: Use the bitmap API when applicableChristophe JAILLET1-6/+3
Use 'bitmap_zalloc()' to simplify code, improve the semantic and avoid some open-coded arithmetic in allocator arguments. Note, that this 'bitmap_zalloc()' divides by BITS_PER_LONG the amount of memory allocated. The 'roundup()' used to computed the number of needed long should have been a DIV_ROUND_UP. Also change the corresponding 'kfree()' into 'bitmap_free()' to keep consistency. Use 'bitmap_zero()' to avoid hand writing it. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/1fe18fb73f71d855043c40c83865ad539f326478.1638396221.git.christophe.jaillet@wanadoo.fr