An error occurred fetching the project authors.
  1. 16 Jul, 2015 1 commit
  2. 01 Dec, 2014 1 commit
  3. 26 Nov, 2014 12 commits
  4. 17 Nov, 2014 1 commit
  5. 04 Nov, 2014 1 commit
  6. 31 Oct, 2014 2 commits
    • Michal Kazior's avatar
      ath10k: speed up hw recovery · 7962b0d8
      Michal Kazior authored
      In some cases hw recovery was taking an absurdly
      long time due to ath10k waiting for things that
      would never really complete.
      
      Instead of waiting for inevitable timeouts poke
      all completions and wakequeues and check if it's
      still worth waiting.
      
      Reading/writing ar->state requires conf_mutex.
      Since waiters might be holding it introduce a new
      flag CRASH_FLUSH so it's possible to tell waiters
      to abort whatever they were waiting for.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      7962b0d8
    • Michal Kazior's avatar
      ath10k: avoid possible deadlock with scan timeout · 4eb2e164
      Michal Kazior authored
      This should prevent deadlock predicted by the
      following splat:
      
       ======================================================
       [ INFO: possible circular locking dependency detected ]
       3.17.0-wl-ath+ #67 Not tainted
       -------------------------------------------------------
       kworker/u32:1/7230 is trying to acquire lock:
        (&ar->conf_mutex){+.+.+.}, at: [<ffffffffa040a57d>] ath10k_scan_timeout_work+0x2d/0x50 [ath10k_core]
      
       but task is already holding lock:
        ((&(&ar->scan.timeout)->work)){+.+...}, at: [<ffffffff8106dae1>] process_one_work+0x151/0x470
      
       which lock already depends on the new lock.
      
       the existing dependency chain (in reverse order) is:
      
       -> #1 ((&(&ar->scan.timeout)->work)){+.+...}:
              [<ffffffff810a12e5>] lock_acquire+0x85/0x100
              [<ffffffff8106cb4d>] flush_work+0x3d/0x270
              [<ffffffff8106e49d>] __cancel_work_timer+0x7d/0x110
              [<ffffffff8106e543>] cancel_delayed_work_sync+0x13/0x20
              [<ffffffffa0409f16>] ath10k_cancel_remain_on_channel+0x36/0x60 [ath10k_core]
              [<ffffffffa028c75c>] ieee80211_cancel_roc+0x1cc/0x2f0 [mac80211]
              [<ffffffffa028c8a2>] ieee80211_mgmt_tx_cancel_wait+0x22/0x30 [mac80211]
              [<ffffffffa0132288>] nl80211_tx_mgmt_cancel_wait+0xa8/0x130 [cfg80211]
              [<ffffffff816654a5>] genl_family_rcv_msg+0x1a5/0x3c0
              [<ffffffff81665749>] genl_rcv_msg+0x89/0xc0
              [<ffffffff81664e91>] netlink_rcv_skb+0xb1/0xc0
              [<ffffffff816650bc>] genl_rcv+0x2c/0x40
              [<ffffffff8166474d>] netlink_unicast+0x18d/0x200
              [<ffffffff81664add>] netlink_sendmsg+0x31d/0x430
              [<ffffffff8161a9ac>] sock_sendmsg+0x9c/0xd0
              [<ffffffff8161b469>] ___sys_sendmsg+0x389/0x3a0
              [<ffffffff8161bed9>] __sys_sendmsg+0x49/0x90
              [<ffffffff8161bf32>] SyS_sendmsg+0x12/0x20
              [<ffffffff8174c456>] system_call_fastpath+0x1a/0x1f
      
       -> #0 (&ar->conf_mutex){+.+.+.}:
              [<ffffffff810a0bde>] __lock_acquire+0x1b6e/0x1ce0
              [<ffffffff810a12e5>] lock_acquire+0x85/0x100
              [<ffffffff817491eb>] mutex_lock_nested+0x4b/0x370
              [<ffffffffa040a57d>] ath10k_scan_timeout_work+0x2d/0x50 [ath10k_core]
              [<ffffffff8106db41>] process_one_work+0x1b1/0x470
              [<ffffffff8106df63>] worker_thread+0x123/0x460
              [<ffffffff81073f34>] kthread+0xe4/0x100
              [<ffffffff8174c3ac>] ret_from_fork+0x7c/0xb0
      
       other info that might help us debug this:
      
        Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock((&(&ar->scan.timeout)->work));
                                      lock(&ar->conf_mutex);
                                      lock((&(&ar->scan.timeout)->work));
         lock(&ar->conf_mutex);
      
        *** DEADLOCK ***
      Reported-by: default avatarMarek Puzyniak <marek.puzyniak@tieto.com>
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      4eb2e164
  7. 24 Oct, 2014 2 commits
  8. 21 Oct, 2014 4 commits
  9. 12 Oct, 2014 1 commit
  10. 08 Oct, 2014 1 commit
  11. 01 Oct, 2014 2 commits
  12. 23 Sep, 2014 3 commits
    • Michal Kazior's avatar
      ath10k: deduplicate wmi_channel code · 2d66721c
      Michal Kazior authored
      The structure is being set up in 2 places.
      Deduplicate the code by creating a helper.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      2d66721c
    • Michal Kazior's avatar
      ath10k: fix tx/rx chainmask init · fdb959c7
      Michal Kazior authored
      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: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      fdb959c7
    • Michal Kazior's avatar
      ath10k: workaround fw beaconing bug · 64badcb6
      Michal Kazior authored
      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: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      64badcb6
  13. 18 Sep, 2014 5 commits
  14. 11 Sep, 2014 2 commits
  15. 02 Sep, 2014 2 commits