1. 17 Nov, 2021 2 commits
    • 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 5 commits
  6. 01 Nov, 2021 3 commits