1. 10 Oct, 2022 2 commits
    • Colin Ian King's avatar
      wifi: ath11k: Fix spelling mistake "chnange" -> "change" · a797f479
      Colin Ian King authored
      There is a spelling mistake in an ath11k_dbg debug message. Fix it.
      Signed-off-by: default avatarColin Ian King <colin.i.king@gmail.com>
      Signed-off-by: default avatarKalle Valo <quic_kvalo@quicinc.com>
      Link: https://lore.kernel.org/r/20220928143834.35189-1-colin.i.king@gmail.com
      a797f479
    • Wen Gong's avatar
      wifi: ath11k: avoid deadlock during regulatory update in ath11k_regd_update() · d99884ad
      Wen Gong authored
      Running this test in a loop it is easy to reproduce an rtnl deadlock:
      
      iw reg set FI
      ifconfig wlan0 down
      
      What happens is that thread A (workqueue) tries to update the regulatory:
      
          try to acquire the rtnl_lock of ar->regd_update_work
      
          rtnl_lock+0x17/0x20
          ath11k_regd_update+0x15a/0x260 [ath11k]
          ath11k_regd_update_work+0x15/0x20 [ath11k]
          process_one_work+0x228/0x670
          worker_thread+0x4d/0x440
          kthread+0x16d/0x1b0
          ret_from_fork+0x22/0x30
      
      And thread B (ifconfig) tries to stop the interface:
      
          try to cancel_work_sync(&ar->regd_update_work) in ath11k_mac_op_stop().
          ifconfig  3109 [003]  2414.232506: probe:
      
          ath11k_mac_op_stop: (ffffffffc14187a0)
          drv_stop+0x30 ([mac80211])
          ieee80211_do_stop+0x5d2 ([mac80211])
          ieee80211_stop+0x3e ([mac80211])
          __dev_close_many+0x9e ([kernel.kallsyms])
          __dev_change_flags+0xbe ([kernel.kallsyms])
          dev_change_flags+0x23 ([kernel.kallsyms])
          devinet_ioctl+0x5e3 ([kernel.kallsyms])
          inet_ioctl+0x197 ([kernel.kallsyms])
          sock_do_ioctl+0x4d ([kernel.kallsyms])
          sock_ioctl+0x264 ([kernel.kallsyms])
          __x64_sys_ioctl+0x92 ([kernel.kallsyms])
          do_syscall_64+0x3a ([kernel.kallsyms])
          entry_SYSCALL_64_after_hwframe+0x63 ([kernel.kallsyms])
          __GI___ioctl+0x7 (/lib/x86_64-linux-gnu/libc-2.23.so)
      
      The sequence of deadlock is:
      
      1. Thread B calls rtnl_lock().
      
      2. Thread A starts to run and calls rtnl_lock() from within
         ath11k_regd_update_work(), then enters wait state because the lock is owned by
         thread B.
      
      3. Thread B continues to run and tries to call
         cancel_work_sync(&ar->regd_update_work), but thread A is in
         ath11k_regd_update_work() waiting for rtnl_lock(). So cancel_work_sync()
         forever waits for ath11k_regd_update_work() to finish and we have a deadlock.
      
      Fix this by switching from using regulatory_set_wiphy_regd_sync() to
      regulatory_set_wiphy_regd(). Now cfg80211 will schedule another workqueue which
      handles the locking on it's own. So the ath11k workqueue can simply exit without
      taking any locks, avoiding the deadlock.
      
      Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
      Signed-off-by: default avatarWen Gong <quic_wgong@quicinc.com>
      [kvalo: improve commit log]
      Signed-off-by: default avatarKalle Valo <quic_kvalo@quicinc.com>
      Link: https://lore.kernel.org/r/20221006151747.13757-1-kvalo@kernel.org
      d99884ad
  2. 30 Sep, 2022 3 commits
    • Wen Gong's avatar
      wifi: ath11k: fix warning in dma_free_coherent() of memory chunks while recovery · f7487843
      Wen Gong authored
      Commit 26f3a021 ("ath11k: allocate smaller chunks of memory for
      firmware") and commit f6f92968 ("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 5962f370 ("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: 5962f370 ("ath11k: Reuse the available memory after firmware reload")
      Signed-off-by: default avatarWen Gong <quic_wgong@quicinc.com>
      Signed-off-by: default avatarKalle Valo <quic_kvalo@quicinc.com>
      Link: https://lore.kernel.org/r/20220928073832.16251-1-quic_wgong@quicinc.com
      f7487843
    • Baochen Qiang's avatar
      wifi: ath11k: Don't exit on wakeup failure · 45d2e268
      Baochen Qiang authored
      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: default avatarBaochen Qiang <quic_bqiang@quicinc.com>
      Signed-off-by: default avatarKalle Valo <quic_kvalo@quicinc.com>
      Link: https://lore.kernel.org/r/20220928015140.5431-1-quic_bqiang@quicinc.com
      45d2e268
    • Gustavo A. R. Silva's avatar
      carl9170: Replace zero-length array with DECLARE_FLEX_ARRAY() helper · 9ec6e207
      Gustavo A. R. Silva authored
      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.htmlSigned-off-by: default avatarGustavo A. R. Silva <gustavoars@kernel.org>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarKalle Valo <quic_kvalo@quicinc.com>
      Link: https://lore.kernel.org/r/YzIdWc8QSdZFHBYg@work
      9ec6e207
  3. 28 Sep, 2022 3 commits
  4. 27 Sep, 2022 6 commits
  5. 26 Sep, 2022 4 commits
    • Baochen Qiang's avatar
      wifi: ath11k: Fix deadlock during WoWLAN suspend · d78c8b71
      Baochen Qiang authored
      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: default avatarBaochen Qiang <quic_bqiang@quicinc.com>
      Signed-off-by: default avatarKalle Valo <quic_kvalo@quicinc.com>
      Link: https://lore.kernel.org/r/20220919021435.2459-1-quic_bqiang@quicinc.com
      d78c8b71
    • Baochen Qiang's avatar
      wifi: ath11k: Remove redundant ath11k_mac_drain_tx · d50ebec1
      Baochen Qiang authored
      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: default avatarBaochen Qiang <quic_bqiang@quicinc.com>
      Signed-off-by: default avatarKalle Valo <quic_kvalo@quicinc.com>
      Link: https://lore.kernel.org/r/20220919020259.1746-1-quic_bqiang@quicinc.com
      d50ebec1
    • Tamizh Chelvam Raja's avatar
      wifi: ath11k: Add spectral scan support for 160 MHz · c92f774a
      Tamizh Chelvam Raja authored
      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: default avatarTamizh Chelvam Raja <quic_tamizhr@quicinc.com>
      Signed-off-by: default avatarKalle Valo <quic_kvalo@quicinc.com>
      Link: https://lore.kernel.org/r/20220725055001.15194-1-quic_tamizhr@quicinc.com
      c92f774a
    • Venkateswara Naralasetty's avatar
      wifi: ath11k: Add support to get power save duration for each client · 710a95f9
      Venkateswara Naralasetty authored
      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: default avatarVenkateswara Naralasetty <quic_vnaralas@quicinc.com>
      Signed-off-by: default avatarTamizh Chelvam Raja <quic_tamizhr@quicinc.com>
      Signed-off-by: default avatarKalle Valo <quic_kvalo@quicinc.com>
      Link: https://lore.kernel.org/r/20220725054601.14719-1-quic_tamizhr@quicinc.com
      710a95f9
  6. 24 Sep, 2022 22 commits