1. 15 Nov, 2021 2 commits
  2. 12 Nov, 2021 3 commits
  3. 10 Nov, 2021 2 commits
  4. 08 Nov, 2021 5 commits
  5. 01 Nov, 2021 7 commits
  6. 28 Oct, 2021 7 commits
  7. 27 Oct, 2021 10 commits
  8. 25 Oct, 2021 4 commits
    • Loic Poulain's avatar
      wcn36xx: Fix tx_status mechanism · a9e79b11
      Loic Poulain authored
      This change fix the TX ack mechanism in various ways:
      
      - For NO_ACK tagged packets, we don't need to wait for TX_ACK indication
      and so are not subject to the single packet ack limitation. So we don't
      have to stop the tx queue, and can call the tx status callback as soon
      as DMA transfer has completed.
      
      - Fix skb ownership/reference. Only start status indication timeout
      once the DMA transfer has been completed. This avoids the skb to be
      both referenced in the DMA tx ring and by the tx_ack_skb pointer,
      preventing any use-after-free or double-free.
      
      - This adds a sanity (paranoia?) check on the skb tx ack pointer.
      
      - Resume TX queue if TX status tagged packet TX fails.
      
      Cc: stable@vger.kernel.org
      Fixes: fdf21cc3 ("wcn36xx: Add TX ack support")
      Signed-off-by: default avatarLoic Poulain <loic.poulain@linaro.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/1634567281-28997-1-git-send-email-loic.poulain@linaro.org
      a9e79b11
    • Loic Poulain's avatar
      wcn36xx: Fix (QoS) null data frame bitrate/modulation · d3fd2c95
      Loic Poulain authored
      We observe unexpected connection drops with some APs due to
      non-acked mac80211 generated null data frames (keep-alive).
      After debugging and capture, we noticed that null frames are
      submitted at standard data bitrate and that the given APs are
      in trouble with that.
      
      After setting the null frame bitrate to control bitrate, all
      null frames are acked as expected and connection is maintained.
      
      Not sure if it's a requirement of the specification, but it seems
      the right thing to do anyway, null frames are mostly used for control
      purpose (power-saving, keep-alive...), and submitting them with
      a slower/simpler bitrate/modulation is more robust.
      
      Cc: stable@vger.kernel.org
      Fixes: 512b191d ("wcn36xx: Fix TX data path")
      Signed-off-by: default avatarLoic Poulain <loic.poulain@linaro.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/1634560399-15290-1-git-send-email-loic.poulain@linaro.org
      d3fd2c95
    • Abinaya Kalaiselvan's avatar
      ath10k: fix module load regression with iram-recovery feature · 6f8c8bf4
      Abinaya Kalaiselvan authored
      Commit 9af7c32c ("ath10k: add target IRAM recovery feature support")
      introduced a new firmware feature flag ATH10K_FW_FEATURE_IRAM_RECOVERY. But
      this caused ath10k_pci module load to fail if ATH10K_FW_CRASH_DUMP_RAM_DATA bit
      was not enabled in the ath10k coredump_mask module parameter:
      
      [ 2209.328190] ath10k_pci 0000:02:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
      [ 2209.434414] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 1 testmode 1
      [ 2209.547191] ath10k_pci 0000:02:00.0: firmware ver 10.4-3.9.0.2-00099 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps,peer-fixed-rate,iram-recovery crc32 cbade90a
      [ 2210.896485] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id 0:1 crc32 a040efc2
      [ 2213.603339] ath10k_pci 0000:02:00.0: failed to copy target iram contents: -12
      [ 2213.839027] ath10k_pci 0000:02:00.0: could not init core (-12)
      [ 2213.933910] ath10k_pci 0000:02:00.0: could not probe fw (-12)
      
      And by default coredump_mask does not have ATH10K_FW_CRASH_DUMP_RAM_DATA
      enabled so anyone using a firmware with iram-recovery feature would fail. To my
      knowledge only QCA9984 firmwares starting from release 10.4-3.9.0.2-00099
      enabled the feature.
      
      The reason for regression was that ath10k_core_copy_target_iram() used
      ath10k_coredump_get_mem_layout() to get the memory layout, but when
      ATH10K_FW_CRASH_DUMP_RAM_DATA was disabled it would get just NULL and bail out
      with an error.
      
      While looking at all this I noticed another bug: if CONFIG_DEV_COREDUMP is
      disabled but the firmware has iram-recovery enabled the module load fails with
      similar error messages. I fixed that by returning 0 from
      ath10k_core_copy_target_iram() when _ath10k_coredump_get_mem_layout() returns
      NULL.
      
      Tested-on: QCA9984 hw2.0 PCI 10.4-3.9.0.2-00139
      
      Fixes: 9af7c32c ("ath10k: add target IRAM recovery feature support")
      Signed-off-by: default avatarAbinaya Kalaiselvan <akalaise@codeaurora.org>
      Signed-off-by: default avatarJouni Malinen <jouni@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20211020075054.23061-1-kvalo@codeaurora.org
      6f8c8bf4
    • Arnd Bergmann's avatar
      ath10k: fix invalid dma_addr_t token assignment · 937e79c6
      Arnd Bergmann authored
      Using a kernel pointer in place of a dma_addr_t token can
      lead to undefined behavior if that makes it into cache
      management functions. The compiler caught one such attempt
      in a cast:
      
      drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_add_interface':
      drivers/net/wireless/ath/ath10k/mac.c:5586:47: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
       5586 |                         arvif->beacon_paddr = (dma_addr_t)arvif->beacon_buf;
            |                                               ^
      
      Looking through how this gets used down the way, I'm fairly
      sure that beacon_paddr is never accessed again for ATH10K_DEV_TYPE_HL
      devices, and if it was accessed, that would be a bug.
      
      Change the assignment to use a known-invalid address token
      instead, which avoids the warning and makes it easier to catch
      bugs if it does end up getting used.
      
      Fixes: e263bdab ("ath10k: high latency fixes for beacon buffer")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20211014075153.3655910-1-arnd@kernel.org
      937e79c6