1. 17 Nov, 2021 7 commits
    • Wen Gong's avatar
      ath11k: add string type to search board data in board-2.bin for WCN6855 · fc95d10a
      Wen Gong authored
      Currently ath11k only support string type with bus, chip id and board id
      such as "bus=ahb,qmi-chip-id=1,qmi-board-id=4" for ahb bus chip and
      "bus=pci,qmi-chip-id=0,qmi-board-id=255" for PCIe bus chip in
      board-2.bin. For WCN6855, it is not enough to distinguish all different
      chips.
      
      This is to add a new string type which include bus, chip id, board id,
      vendor, device, subsystem-vendor and subsystem-device for WCN6855.
      
      ath11k will first load board-2.bin and search in it for the board data
      with the above parameters, if matched one board data, then download it
      to firmware, if not matched any one, then ath11k will download the file
      board.bin to firmware.
      
      Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
      Signed-off-by: default avatarWen Gong <quic_wgong@quicinc.com>
      Signed-off-by: default avatarJouni Malinen <quic_jouni@quicinc.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20211111065340.20187-1-quic_wgong@quicinc.com
      fc95d10a
    • Baochen Qiang's avatar
      ath11k: Fix crash caused by uninitialized TX ring · 273703eb
      Baochen Qiang authored
      Commit 31582373 ("ath11k: Change number of TCL rings to one for
      QCA6390") avoids initializing the other entries of dp->tx_ring cause
      the corresponding TX rings on QCA6390/WCN6855 are not used, but leaves
      those ring masks in ath11k_hw_ring_mask_qca6390.tx unchanged. Normally
      this is OK because we will only get interrupts from the first TX ring
      on these chips and thus only the first entry of dp->tx_ring is involved.
      
      In case of one MSI vector, all DP rings share the same IRQ. For each
      interrupt, all rings have to be checked, which means the other entries
      of dp->tx_ring are involved. However since they are not initialized,
      system crashes.
      
      Fix this issue by simply removing those ring masks.
      
      crash stack:
      [  102.907438] BUG: kernel NULL pointer dereference, address: 0000000000000028
      [  102.907447] #PF: supervisor read access in kernel mode
      [  102.907451] #PF: error_code(0x0000) - not-present page
      [  102.907453] PGD 1081f0067 P4D 1081f0067 PUD 1081f1067 PMD 0
      [  102.907460] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI
      [  102.907465] CPU: 0 PID: 3511 Comm: apt-check Kdump: loaded Tainted: G            E     5.15.0-rc4-wt-ath+ #20
      [  102.907470] Hardware name: AMD Celadon-RN/Celadon-RN, BIOS RCD1005E 10/08/2020
      [  102.907472] RIP: 0010:ath11k_dp_tx_completion_handler+0x201/0x830 [ath11k]
      [  102.907497] Code: 3c 24 4e 8d ac 37 10 04 00 00 4a 8d bc 37 68 04 00 00 48 89 3c 24 48 63 c8 89 83 84 18 00 00 48 c1 e1 05 48 03 8b 78 18 00 00 <8b> 51 08 89 d6 83 e6 07 89 74 24 24 83 fe 03 74 04 85 f6 75 63 41
      [  102.907501] RSP: 0000:ffff9b7340003e08 EFLAGS: 00010202
      [  102.907505] RAX: 0000000000000001 RBX: ffff8e21530c0100 RCX: 0000000000000020
      [  102.907508] RDX: 0000000000000000 RSI: 00000000fffffe00 RDI: ffff8e21530c1938
      [  102.907511] RBP: ffff8e21530c0000 R08: 0000000000000001 R09: 0000000000000000
      [  102.907513] R10: ffff8e2145534c10 R11: 0000000000000001 R12: ffff8e21530c2938
      [  102.907515] R13: ffff8e21530c18e0 R14: 0000000000000100 R15: ffff8e21530c2978
      [  102.907518] FS:  00007f5d4297e740(0000) GS:ffff8e243d600000(0000) knlGS:0000000000000000
      [  102.907521] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  102.907524] CR2: 0000000000000028 CR3: 00000001034ea000 CR4: 0000000000350ef0
      [  102.907527] Call Trace:
      [  102.907531]  <IRQ>
      [  102.907537]  ath11k_dp_service_srng+0x5c/0x2f0 [ath11k]
      [  102.907556]  ath11k_pci_ext_grp_napi_poll+0x21/0x70 [ath11k_pci]
      [  102.907562]  __napi_poll+0x2c/0x160
      [  102.907570]  net_rx_action+0x251/0x310
      [  102.907576]  __do_softirq+0x107/0x2fc
      [  102.907585]  irq_exit_rcu+0x74/0x90
      [  102.907593]  common_interrupt+0x83/0xa0
      [  102.907600]  </IRQ>
      [  102.907601]  asm_common_interrupt+0x1e/0x40
      
      Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
      Signed-off-by: default avatarBaochen Qiang <bqiang@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20211026011605.58615-1-quic_bqiang@quicinc.com
      273703eb
    • Venkateswara Naralasetty's avatar
      ath11k: add trace log support · fb12305a
      Venkateswara Naralasetty authored
      This change is to add trace log support for,
              * WMI events
              * WMI commands
              * ath11k_dbg messages
              * ath11k_dbg_dump messages
              * ath11k_log_info messages
              * ath11k_log_warn messages
              * ath11k_log_err messages
      
      Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-00652-QCAHKSWPL_SILICONZ-1
      Signed-off-by: default avatarVenkateswara Naralasetty <quic_vnaralas@quicinc.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/1636439755-30419-1-git-send-email-quic_vnaralas@quicinc.com
      fb12305a
    • Anilkumar Kolli's avatar
      ath11k: Add missing qmi_txn_cancel() · 1ad6e4b0
      Anilkumar Kolli authored
      Currently many functions do not follow this guidance when
      qmi_send_request() fails, therefore add missing
      qmi_txn_cancel() in the qmi_send_request() error path.
      
      Also remove initialization on 'struct qmi_txn'
      since qmi_tx_init() performs all necessary initialization.
      
      Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01838-QCAHKSWPL_SILICONZ-1
      Signed-off-by: default avatarAnilkumar Kolli <akolli@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/1635857558-21733-1-git-send-email-akolli@codeaurora.org
      1ad6e4b0
    • Rameshkumar Sundaram's avatar
      ath11k: use cache line aligned buffers for dbring · bd77f6b1
      Rameshkumar Sundaram authored
      The DMA buffers of dbring which is used for spectral/cfr
      starts at certain offset from original kmalloc() returned buffer.
      This is not cache line aligned.
      And also driver tries to access the data that is immediately before
      this offset address (i.e. buff->paddr) after doing dma map.
      This will cause cache line sharing issues and data corruption,
      if CPU happen to write back cache after HW has dma'ed the data.
      
      Fix this by mapping a cache line aligned buffer to dma.
      
      Tested on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1
      Signed-off-by: default avatarRameshkumar Sundaram <quic_ramess@quicinc.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/1635831693-15962-1-git-send-email-quic_ramess@quicinc.com
      bd77f6b1
    • P Praneesh's avatar
      ath11k: Disabling credit flow for WMI path · f951380a
      P Praneesh authored
      Firmware credit flow control is enabled for WMI control services,
      which expects available tokens should be acquired before sending a
      command to the target. Also the token gets released when firmware
      receives the command.
      
      This credit-based flow limits driver to send WMI command only
      when the token available which is causing WMI commands to timeout and
      return -EAGAIN, whereas firmware has enough capability to process the
      WMI command. To fix this Tx starvation issue, introduce the ability to
      disable the credit flow for the WMI path.
      
      The driver sends WMI configuration for disabling credit flow to firmware
      by two ways.
      	1. By using a global flag
      		(HTC_MSG_SETUP_COMPLETE_EX_ID msg type flags)
      	2. By using a local flag
      		(ATH11K_HTC_CONN_FLAGS_DISABLE_CREDIT_FLOW_CTRL = 1 << 3)
      
      Ath11k uses both these configurations to disable credit flow for the
      WMI path completely.
      
      Also added a hw_param member for credit flow control by which we can
      enable or disable it based on per-target basis. Currently we are disabling
      credit flow for IPQ8074, IPQ6018, and QCN9074 as recommended by firmware.
      
      Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01492-QCAHKSWPL_SILICONZ-1
      Tested-on: IPQ6018 hw1.0 AHB WLAN.HK.2.4.0.1-00330-QCAHKSWPL_SILICONZ-1
      Co-developed-by: default avatarPravas Kumar Panda <kumarpan@codeaurora.org>
      Signed-off-by: default avatarPravas Kumar Panda <kumarpan@codeaurora.org>
      Signed-off-by: default avatarP Praneesh <quic_ppranees@quicinc.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/1635156494-20059-1-git-send-email-quic_ppranees@quicinc.com
      f951380a
    • Sven Eckelmann's avatar
      ath11k: Fix ETSI regd with weather radar overlap · 086c921a
      Sven Eckelmann authored
      Some ETSI countries have a small overlap in the wireless-regdb with an ETSI
      channel (5590-5650). A good example is Australia:
      
        country AU: DFS-ETSI
        	(2400 - 2483.5 @ 40), (36)
        	(5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
        	(5250 - 5350 @ 80), (20), NO-OUTDOOR, AUTO-BW, DFS
        	(5470 - 5600 @ 80), (27), DFS
        	(5650 - 5730 @ 80), (27), DFS
        	(5730 - 5850 @ 80), (36)
        	(57000 - 66000 @ 2160), (43), NO-OUTDOOR
      
      If the firmware (or the BDF) is shipped with these rules then there is only
      a 10 MHz overlap with the weather radar:
      
      * below: 5470 - 5590
      * weather radar: 5590 - 5600
      * above: (none for the rule "5470 - 5600 @ 80")
      
      There are several wrong assumption in the ath11k code:
      
      * there is always a valid range below the weather radar
        (actually: there could be no range below the weather radar range OR range
         could be smaller than 20 MHz)
      * intersected range in the weather radar range is valid
        (actually: the range could be smaller than 20 MHz)
      * range above weather radar is either empty or valid
        (actually: the range could be smaller than 20 MHz)
      
      These wrong assumption will lead in this example to a rule
      
        (5590 - 5600 @ 20), (N/A, 27), (600000 ms), DFS, AUTO-BW
      
      which is invalid according to is_valid_reg_rule() because the freq_diff is
      only 10 MHz but the max_bandwidth is set to 20 MHz. Which results in a
      rejection like:
      
        WARNING: at backports-20210222_001-4.4.60-b157d2276/net/wireless/reg.c:3984
        [...]
        Call trace:
        [<ffffffbffc3d2e50>] reg_get_max_bandwidth+0x300/0x3a8 [cfg80211]
        [<ffffffbffc3d3d0c>] regulatory_set_wiphy_regd_sync+0x3c/0x98 [cfg80211]
        [<ffffffbffc651598>] ath11k_regd_update+0x1a8/0x210 [ath11k]
        [<ffffffbffc652108>] ath11k_regd_update_work+0x18/0x20 [ath11k]
        [<ffffffc0000a93e0>] process_one_work+0x1f8/0x340
        [<ffffffc0000a9784>] worker_thread+0x25c/0x448
        [<ffffffc0000aedc8>] kthread+0xd0/0xd8
        [<ffffffc000085550>] ret_from_fork+0x10/0x40
        ath11k c000000.wifi: failed to perform regd update : -22
        Invalid regulatory domain detected
      
      To avoid this, the algorithm has to be changed slightly. Instead of
      splitting a rule which overlaps with the weather radar range into 3 pieces
      and accepting the first two parts blindly, it must actually be checked for
      each piece whether it is a valid range. And only if it is valid, add it to
      the output array.
      
      When these checks are in place, the processed rules for AU would end up as
      
        country AU: DFS-ETSI
                (2400 - 2483 @ 40), (N/A, 36), (N/A)
                (5150 - 5250 @ 80), (6, 23), (N/A), NO-OUTDOOR, AUTO-BW
                (5250 - 5350 @ 80), (6, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
                (5470 - 5590 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
                (5650 - 5730 @ 80), (6, 27), (0 ms), DFS, AUTO-BW
                (5730 - 5850 @ 80), (6, 36), (N/A), AUTO-BW
      
      and will be accepted by the wireless regulatory code.
      
      Fixes: d5c65159 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20211112153116.1214421-1-sven@narfation.org
      086c921a
  2. 15 Nov, 2021 25 commits
  3. 12 Nov, 2021 3 commits
  4. 10 Nov, 2021 2 commits
  5. 08 Nov, 2021 3 commits