1. 10 May, 2011 4 commits
    • Paul Fox's avatar
      libertas: fix cmdpendingq locking · 2ae1b8b3
      Paul Fox authored
      We occasionally see list corruption using libertas.
      
      While we haven't been able to diagnose this precisely, we have spotted
      a possible cause: cmdpendingq is generally modified with driver_lock
      held. However, there are a couple of points where this is not the case.
      
      Fix up those operations to execute under the lock, it seems like
      the correct thing to do and will hopefully improve the situation.
      Signed-off-by: default avatarPaul Fox <pgf@laptop.org>
      Signed-off-by: default avatarDaniel Drake <dsd@laptop.org>
      Acked-by: default avatarDan Williams <dcbw@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2ae1b8b3
    • Stanislaw Gruszka's avatar
      iwlegacy: fix IBSS mode crashes · eb85de3f
      Stanislaw Gruszka authored
      We should not switch to non-IBSS channels when working in IBSS mode,
      otherwise there are microcode errors, and after some time system
      crashes.
      
      This bug is only observable when software scan is used in IBSS mode,
      so should be considered as regression after:
      
      commit 0263aa45
      Author: Stanislaw Gruszka <sgruszka@redhat.com>
      Date:   Tue Mar 29 11:24:21 2011 +0200
      
          iwl3945: disable hw scan by default
      
      However IBSS mode check, which this patch add again, was removed by
      
      commit b2f30e8b
      Author: Johannes Berg <johannes.berg@intel.com>
      Date:   Thu Jan 21 07:32:20 2010 -0800
      
          iwlwifi: remove IBSS channel sanity check
      
      That commit claim that mac80211 will not use non-IBSS channel in IBSS
      mode, what definitely is not true. Bug probably should be fixed in
      mac80211, but that will require more work, so better to apply that patch
      temporally, and provide proper mac80211 fix latter.
      
      Resolves:
      https://bugzilla.kernel.org/show_bug.cgi?id=34452Reported-and-tested-by: default avatarMikko Rapeli <mikko.rapeli@iki.fi>
      Cc: stable@kernel.org # 2.6.38.5+
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      eb85de3f
    • Mohammed Shafi Shajakhan's avatar
      ath9k: Fix a warning due to a queued work during S3 state · 99aa55b6
      Mohammed Shafi Shajakhan authored
      during suspend/S3 state drv_flush is called from mac80211 irrespective of
      interface count. In ath9k we queue a work in ath9k_flush which we expect
      to be cancelled in the drv_stop call back. during suspend process mac80211
      calls drv_stop only when the interface count(local->count) is non-zero.
      unfortunately when the network manager is enabled, drv_flush is called
      while drv_stop is not called as local->count reaches '0'.
      	So fix this by simply checking for the device presence in the
      drv_flush call back in the driver before queueing work or anything else.
      this patch fixes the following WARNING
      
      	Call Trace:
      	[<c014c6e2>] warn_slowpath_common+0x72/0xa0
      	[<fc133f99>] ? ieee80211_can_queue_work+0x39/0x50 [mac80211]
      	[<fc133f99>] ? ieee80211_can_queue_work+0x39/0x50 [mac80211]
      	[<c014c75b>] warn_slowpath_fmt+0x2b/0x30
      	[<fc133f99>] ieee80211_can_queue_work+0x39/0x50 [mac80211]
      	[<fc134ed1>] ieee80211_queue_delayed_work+0x21/0x50 [mac80211]
      	[<fc1e5b22>] ath_tx_complete_poll_work+0xb2/0x100 [ath9k]
      	[<c016399e>] run_workqueue+0x8e/0x150
      	[<fc1e5a70>] ? ath_tx_complete_poll_work+0x0/0x100 [ath9k]
      	[<c0163ae4>] worker_thread+0x84/0xe0
      	[<c0167a60>] ? autoremove_wake_function+0x0/0x50
      	[<c0163a60>] ? worker_thread+0x0/0xe0
      	[<c01677d4>] kthread+0x74/0x80
      	[<c0167760>] ? kthread+0x0/0x80
      	[<c0104087>] kernel_thread_helper+0x7/0x10
      ---[ end trace 2aff81010df9215b ]---
      Signed-off-by: default avatarRajkumar Manoharan <rmanoharan@atheros.com>
      Signed-off-by: default avatarMohammed Shafi Shajakhan <mshajakhan@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      99aa55b6
    • Luciano Coelho's avatar
      mac80211: don't start the dynamic ps timer if not associated · 5db1c07c
      Luciano Coelho authored
      When we are disconnecting, we set PS off, but this happens before we
      send the deauth/disassoc request.  When the deauth/disassoc frames are
      sent, we trigger the dynamic ps timer, which then times out and turns
      PS back on.  Thus, PS remains on after disconnecting, causing problems
      when associating again.
      
      This can be fixed by preventing the timer to start when we're not
      associated anymore.
      Signed-off-by: default avatarLuciano Coelho <coelho@ti.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5db1c07c
  2. 29 Apr, 2011 2 commits
  3. 28 Apr, 2011 3 commits
  4. 20 Apr, 2011 4 commits
  5. 19 Apr, 2011 1 commit
  6. 18 Apr, 2011 5 commits
  7. 13 Apr, 2011 1 commit
  8. 12 Apr, 2011 2 commits
    • Sujith Manoharan's avatar
      ath9k_htc: Fix ethtool reporting · 50f68712
      Sujith Manoharan authored
      Pass the correct module name and device interface so that
      ethtool can display the proper values.
      
      The firmware version will be fixed later on when the FW
      can actually report a version. :)
      Reported-by: default avatarRichard Farina <sidhayn@gmail.com>
      Signed-off-by: default avatarSujith Manoharan <Sujith.Manoharan@atheros.com>
      Tested-by: default avatarRichard Farina <sidhayn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      50f68712
    • Felix Fietkau's avatar
      ath9k_hw: fix stopping rx DMA during resets · 5882da02
      Felix Fietkau authored
      During PHY errors, the MAC can sometimes fail to enter an idle state on older
      hardware (before AR9380) after an rx stop has been requested.
      
      This typically shows up in the kernel log with messages like these:
      
      ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
      ------------[ cut here ]------------
      WARNING: at drivers/net/wireless/ath/ath9k/recv.c:504 ath_stoprecv+0xcc/0xf0 [ath9k]()
      Call Trace:
      [<8023f0e8>] dump_stack+0x8/0x34
      [<80075050>] warn_slowpath_common+0x78/0xa4
      [<80075094>] warn_slowpath_null+0x18/0x24
      [<80d66d60>] ath_stoprecv+0xcc/0xf0 [ath9k]
      [<80d642cc>] ath_set_channel+0xbc/0x270 [ath9k]
      [<80d65254>] ath_radio_disable+0x4a4/0x7fc [ath9k]
      
      When this happens, the state that the MAC enters is easy to identify and
      does not result in bogus DMA traffic, however to ensure a working state
      after a channel change, the hardware should still be reset.
      
      This patch adds detection for this specific MAC state, after which the above
      warnings completely disappear in my tests.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Cc: stable@kernel.org
      Cc: Kyungwan Nam <Kyungwan.Nam@Atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5882da02
  9. 11 Apr, 2011 1 commit
  10. 08 Apr, 2011 2 commits
  11. 07 Apr, 2011 3 commits
  12. 04 Apr, 2011 12 commits