1. 29 Apr, 2019 3 commits
    • Wen Gong's avatar
      ath10k: add PN replay protection for high latency devices · 130c7749
      Wen Gong authored
      On high latency devices (SDIO, USB) ath10k did not do PN replay check, a data
      frame with an invalid PN number was not discard as it should have been. So this
      patch implements PN replay in ath10k. PN replay check for fragmented frames is
      implemented in followup patch.
      
      With low latency devices (PCI, AHB) hardware can store the data
      frames's content to host memory directly and the firmware can fully reorder
      data frames, and do PN replay check at the same time. But for high latency
      devices all data frames will be received and stored in firmware's memory and it
      is hard to do full reorder because of the memory size limitations in the
      firmware. This is why the PN replay protections needs to be implemented in host
      driver.
      
      Tested on QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1.
      Signed-off-by: default avatarWen Gong <wgong@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      130c7749
    • Wen Gong's avatar
      ath10k: add handler for HTT_T2H_MSG_TYPE_SEC_IND event · 28ce53b6
      Wen Gong authored
      Add the handler for HTT_T2H_MSG_TYPE_SEC_IND event from firmware, which stores
      PN for replay check implemented in the following patch.
      
      Tested on QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1.
      Signed-off-by: default avatarWen Gong <wgong@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      28ce53b6
    • Wen Gong's avatar
      ath10k: add struct for high latency PN replay protection · e1bddde9
      Wen Gong authored
      Add the struct for PN replay protection and fragment packet
      handler.
      
      Also fix the bitmask of HTT_RX_DESC_HL_INFO_MCAST_BCAST to match what's currently
      used by SDIO firmware. The defines are not used yet so it's safe to modify
      them. Remove the conflicting HTT_RX_DESC_HL_INFO_FRAGMENT as
      it's not either used in ath10k.
      
      Tested on QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1.
      Signed-off-by: default avatarWen Gong <wgong@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      e1bddde9
  2. 23 Apr, 2019 8 commits
    • Erik Stromdahl's avatar
      ath10k: sdio: add missing error check · f91b63b0
      Erik Stromdahl authored
      Although not likely, the bundle allocation might fail.
      Add proper error check and warning print.
      Signed-off-by: default avatarErik Stromdahl <erik.stromdahl@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      f91b63b0
    • Alagu Sankar's avatar
      ath10k: add initialization of HTC header · fbd428a5
      Alagu Sankar authored
      HTC header carries junk values that may be interpreted by the firmware
      differently. Enable credit update only if flow control is enabled for
      the corresponding endpoint.
      Signed-off-by: default avatarAlagu Sankar <alagusankar@silex-india.com>
      Signed-off-by: default avatarErik Stromdahl <erik.stromdahl@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      fbd428a5
    • Kalle Valo's avatar
      ath10k: fix use-after-free on SDIO data frames · 30382dd1
      Kalle Valo authored
      With SDIO there's a use after free after a data frame is transfered, call stack
      below. This happens because ath10k_htt_tx_hl() directly transmits the skb
      provided by mac80211 using ath10k_htc_send(), all other HTT functions use
      separate skb created with ath10k_htc_alloc_skb() to transmit the HTC packet.
      After the packet is transmitted mac80211 frees the skb in ieee80211_tx_status()
      but HTT layer expects  that it still owns the skb, and frees it in
      ath10k_htt_htc_tx_complete().
      
      To fix this take a reference of skb before sending it to HTC layer to make sure
      we still own the skb.
      
      Tested on QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1.
      ath10k_htt_tx_hl() is only used by SDIO and USB so other busses (PCI, AHB and
      SNOC) should be unaffected.
      
      call stack of use-after-free:
      dump_backtrace+0x0/0x2d8
      show_stack+0x20/0x2c
      __dump_stack+0x20/0x28
      dump_stack+0xc8/0xec
      print_address_description+0x74/0x240
      kasan_report+0x258/0x274
      __asan_report_load4_noabort+0x20/0x28
      skb_pull+0xbc/0x114
      ath10k_htc_notify_tx_completion+0x190/0x2a4 [ath10k_core]
      ath10k_sdio_write_async_work+0x1e4/0x2c4 [ath10k_sdio]
      process_one_work+0x3d8/0x8b0
      worker_thread+0x518/0x7e0
      kthread+0x260/0x278
      ret_from_fork+0x10/0x18
      
      Allocated by one task:
      kasan_kmalloc+0xa0/0x13c
      kasan_slab_alloc+0x14/0x1c
      kmem_cache_alloc+0x144/0x208
      __alloc_skb+0xec/0x394
      alloc_skb_with_frags+0x8c/0x374
      sock_alloc_send_pskb+0x520/0x5d4
      sock_alloc_send_skb+0x40/0x50
      __ip_append_data+0xf5c/0x1858
      ip_make_skb+0x194/0x1d4
      udp_sendmsg+0xf24/0x1ab8
      inet_sendmsg+0x1b0/0x2e0
      sock_sendmsg+0x88/0xa0
      __sys_sendto+0x220/0x3a8
      __arm64_sys_sendto+0x78/0x80
      el0_svc_common+0x120/0x1e0
      el0_svc_compat_handler+0x64/0x80
      el0_svc_compat+0x8/0x18
      
      Freed by another task:
      __kasan_slab_free+0x120/0x1d4
      kasan_slab_free+0x10/0x1c
      kmem_cache_free+0x74/0x504
      kfree_skbmem+0x88/0xc8
      __kfree_skb+0x24/0x2c
      consume_skb+0x114/0x18c
      __ieee80211_tx_status+0xb7c/0xf60 [mac80211]
      ieee80211_tx_status+0x224/0x270 [mac80211]
      ath10k_txrx_tx_unref+0x564/0x950 [ath10k_core]
      ath10k_htt_t2h_msg_handler+0x178c/0x2a38 [ath10k_core]
      ath10k_htt_htc_t2h_msg_handler+0x20/0x30 [ath10k_core]
      ath10k_sdio_irq_handler+0xcc0/0x1654 [ath10k_sdio]
      process_sdio_pending_irqs+0xec/0x358
      sdio_run_irqs+0x68/0xe4
      sdio_irq_work+0x1c/0x28
      process_one_work+0x3d8/0x8b0
      worker_thread+0x518/0x7e0
      kthread+0x260/0x278
      ret_from_fork+0x10/0x18
      Reported-by: default avatarWen Gong <wgong@codeaurora.org>
      Tested-by: default avatarWen Gong <wgong@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      30382dd1
    • Alagu Sankar's avatar
      ath10k: htt: support MSDU ids with SDIO · 8ea51e40
      Alagu Sankar authored
      Transmit completion for SDIO is similar to PCIe, modify the high
      latency path to allow SDIO modules to use the msdu id.
      
      kvalo: the original patch from Alagu enabled this only for SDIO but I'm not
      sure should we also enable this with USB. I'll use bus params to enable this
      for so that it's easy to enable also for USB later.
      
      Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1.
      Co-developed-by: default avatarWen Gong <wgong@codeaurora.org>
      Signed-off-by: default avatarAlagu Sankar <alagusankar@silex-india.com>
      Signed-off-by: Wen Gong <wgong@codeaurora.org>.
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      8ea51e40
    • Kalle Valo's avatar
      ath10k: initialise struct ath10k_bus params to zero · 6d084ac2
      Kalle Valo authored
      This way we don't need to set every variable and give them to default, which is
      zero. This is also safer in case we forgot to initalise a new field in some of
      the bus modules.
      
      Compile tested only.
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      6d084ac2
    • Alagu Sankar's avatar
      ath10k: htt: don't use txdone_fifo with SDIO · e2a6b711
      Alagu Sankar authored
      HTT High Latency (ATH10K_DEV_TYPE_HL) does not use txdone_fifo at all, we don't
      even initialise it by skipping ath10k_htt_tx_alloc_buf() in
      ath10k_htt_tx_start(). Because of this using QCA6174 SDIO
      ath10k_htt_rx_tx_compl_ind() will crash when it accesses unitialised
      txdone_fifo. So skip txdone_fifo when using High Latency mode.
      
      Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1.
      Co-developed-by: default avatarWen Gong <wgong@codeaurora.org>
      Signed-off-by: default avatarAlagu Sankar <alagusankar@silex-india.com>
      Signed-off-by: default avatarWen Gong <wgong@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      e2a6b711
    • Wen Gong's avatar
      ath10k: don't disable interrupts in ath10k_sdio_remove() · 70736b97
      Wen Gong authored
      Disabling interrupts this early meant WMI communication was not working anymore
      when the SDIO device was removed. But we call ath10k_core_unregister() that
      will eventually call ath10k_sdio_hif_stop(), which disables the interrupts. So
      there's actually no need to disable interrupts here.
      
      Also remove cancel_work_sync() as it's also called in ath10k_sdio_hif_stop().
      
      Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1.
      Signed-off-by: default avatarWen Gong <wgong@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      70736b97
    • Wen Gong's avatar
      ath10k: sdio: workaround firmware UART pin configuration bug · 4504f0e5
      Wen Gong authored
      On QCA6174 SDIO devices the SDIO interrupt will fail if UART is
      disabled from ath10k. SDIO firmware enables UART printouts by
      default. If ath10k will try to enable UART again the firmware
      will configure it's GPIO line incorrectly and SDIO interrupts
      won't work anymore. The workaround is to set UART pin again (19
      for QCA6174 SDIO) if uart_print is 0.
      
      Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1.
      Signed-off-by: default avatarWen Gong <wgong@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      4504f0e5
  3. 19 Apr, 2019 11 commits
  4. 18 Apr, 2019 18 commits