1. 01 9月, 2013 6 次提交
  2. 28 8月, 2013 1 次提交
    • M
      ath10k: Fix mutex unlock balance · e2951f7f
      Mohammed Shafi Shajakhan 提交于
      ath10k_debug_read_target_stats is properly
      protected by data_lock (spinlock). Remove
      the unwanted mutex_unlock(&ar->conf_mutex)
      
      [ BUG: bad unlock balance detected! ]
      -------------------------------------
      kworker/u4:0/12459 is trying to release lock
      (&ar->conf_mutex) at:
      [<c16a170d>] mutex_unlock+0xd/0x10
      but there are no more locks to release!
      
       Call Trace:
        [<c16a170d>] ? mutex_unlock+0xd/0x10
        [<c10b697d>] __lock_release+0x4d/0xe0
        [<f88ca0fc>] ? ath10k_debug_read_target_stats+0xac/0x290
      
        [<c16a170d>] ? mutex_unlock+0xd/0x10
        [<c10b6a5b>] lock_release+0x4b/0x150
        [<c16a1580>] __mutex_unlock_slowpath+0x70/0x150
        [<f88ca0fc>] ? ath10k_debug_read_target_stats+0xac/0x290
      
        [<c10b456b>] ? trace_hardirqs_on+0xb/0x10
        [<c16a170d>] mutex_unlock+0xd/0x10
        [<f88ca107>] ath10k_debug_read_target_stats+0xb7/0x290
      
        [<f88d337a>] ath10k_wmi_event_process+0x3fa/0x6e0
      
        [<c10b456b>] ? trace_hardirqs_on+0xb/0x10
        [<f88d36e1>] ath10k_wmi_event_work+0x21/0x40
                     [ath10k_core]
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      e2951f7f
  3. 15 8月, 2013 2 次提交
  4. 14 8月, 2013 8 次提交
  5. 13 8月, 2013 1 次提交
  6. 12 8月, 2013 3 次提交
  7. 07 8月, 2013 3 次提交
  8. 06 8月, 2013 1 次提交
    • M
      ath10k: fix device teardown · 32270b61
      Michal Kazior 提交于
      This fixes interrupt-related issue when no
      interfaces were running thus the device was
      considered powered down.
      
      The power_down() function isn't really powering
      down the device. It simply assumed it won't
      interrupt. This wasn't true in some cases and
      could lead to paging failures upon FW indication
      interrupt (i.e. FW crash) because some structures
      aren't allocated in that device state.
      
      One reason for that was that ar_pci->started
      wasn't reset. The other is interrupts should've
      been masked when teardown starts.
      
      The patch reorganized interrupt setup and makes
      sure ar_pci->started is reset accordingly.
      Reported-by: NBen Greear <greearb@candelatech.com>
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      32270b61
  9. 02 8月, 2013 8 次提交
  10. 31 7月, 2013 2 次提交
  11. 30 7月, 2013 5 次提交