1. 08 10月, 2014 1 次提交
  2. 01 10月, 2014 2 次提交
  3. 23 9月, 2014 3 次提交
    • M
      ath10k: deduplicate wmi_channel code · 2d66721c
      Michal Kazior 提交于
      The structure is being set up in 2 places.
      Deduplicate the code by creating a helper.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      2d66721c
    • M
      ath10k: fix tx/rx chainmask init · fdb959c7
      Michal Kazior 提交于
      Firmware reports the number of RF chains so use
      that for initialization of supp_{tx,rx}_chainmask
      instead of using a macro for 3x3 chips.
      
      This should make tx/rx chainmask reports correct
      for chips other than 3x3.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      fdb959c7
    • M
      ath10k: workaround fw beaconing bug · 64badcb6
      Michal Kazior 提交于
      Some firmware revisions don't wait for beacon tx
      completion before sending another SWBA event. This
      could lead to hardware using old (freed) beacon
      data in some cases, e.g. tx credit starvation
      combined with missed TBTT. This is very very rare.
      
      On non-IOMMU-enabled hosts this could be a
      possible security issue because hw could beacon
      some random data on the air.  On IOMMU-enabled
      hosts DMAR faults would occur in most cases and
      target device would crash.
      
      Since there are no beacon tx completions (implicit
      nor explicit) propagated to host the only
      workaround for this is to allocate a DMA-coherent
      buffer for a lifetime of a vif and use it for all
      beacon tx commands. Worst case for this approach
      is some beacons may become corrupted, e.g. garbled
      IEs or out-of-date TIM bitmap.
      
      Keep the original beacon-related code as-is in
      case future firmware revisions solve this problem
      so that the old path can be easily re-enabled with
      a fw_feature flag.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      64badcb6
  4. 18 9月, 2014 5 次提交
  5. 12 9月, 2014 1 次提交
    • K
      ath10k: add testmode · 43d2a30f
      Kalle Valo 提交于
      Add testmode interface for starting and using UTF firmware which is used to run
      factory tests. This is implemented by adding new state ATH10K_STATE_UTF and user
      space can enable this state with ATH10K_TM_CMD_UTF_START command. To go back to
      normal mode user space can send ATH10K_TM_CMD_UTF_STOP.
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      43d2a30f
  6. 02 9月, 2014 4 次提交
  7. 27 8月, 2014 1 次提交
  8. 14 8月, 2014 2 次提交
  9. 12 8月, 2014 2 次提交
  10. 04 8月, 2014 1 次提交
    • S
      ath10k: add spectral scan feature · 855aed12
      Simon Wunderlich 提交于
      Adds the spectral scan feature for ath10k. The spectral scan is triggered by
      configuring a mode through a debugfs control file. Samples can be gathered via
      another relay debugfs file.
      
      Essentially, to try it out:
      
      ip link set dev wlan0 up
      echo background > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
      echo trigger > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
      iw dev wlan0 scan
      echo disable > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
      cat /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan0 > samples
      
      This feature is still experimental. Based on the original RFC patch of
      Sven Eckelmann.
      Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      855aed12
  11. 02 8月, 2014 1 次提交
  12. 25 7月, 2014 2 次提交
  13. 22 7月, 2014 2 次提交
  14. 25 6月, 2014 1 次提交
  15. 27 5月, 2014 5 次提交
  16. 23 5月, 2014 2 次提交
  17. 16 5月, 2014 1 次提交
    • M
      ath10k: fix pmf for action frames · eeab266c
      Marek Kwaczynski 提交于
      Fix sending and receiveing protected managment frames.
      Lack of protected flag for received protected action frames
      causes report these frames as unprotected robust action frames.
      If the driver in AP mode sent frame with protected flag and
      CCMP header using IEEE80211_KEY_FLAG_SW_MGMT_TX flag,
      the FW encrypted frames once again. From user side all
      received SA Query Requests and Responses were skipped and
      all protected action frames were sent as malformed packets.
      Signed-off-by: NMarek Kwaczynski <marek.kwaczynski@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      eeab266c
  18. 24 4月, 2014 2 次提交
  19. 11 4月, 2014 2 次提交