1. 29 1月, 2011 2 次提交
  2. 23 12月, 2010 4 次提交
    • M
      ath9k: Reset keycache on resume · db7ec38d
      Mohammed Shafi Shajakhan 提交于
      It looks like some hardware registers are left into undefined state
      after suspend/resume. At minimum, this can cause odd issues related to
      key cache and hardware trying to encrypt/decrypt frames unexpectedly.
      This seems to happen even when there is no keys configured, i.e., hardware
      can end up touching TX frames just based of invalid key cache context
      even if the driver is not asking a specific entry to be used. In
      addition, RX can likely be affected. This patch fixes this issue.
      Signed-off-by: NJouni Malinen <Jouni.Malinen@Atheros.com>
      Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      db7ec38d
    • H
      ath9k: Use pci_is_pcie() · e40b5faa
      Hauke Mehrtens 提交于
      Use function pci_is_pcie() instead of accessing struct member directly.
      
      CC: Luis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e40b5faa
    • L
      ath9k: fix aphy / wiphy idle mismatch · afe68d0a
      Luis R. Rodriguez 提交于
      ath9k supports its own set of virtual wiphys, and it uses
      the mac80211 idle notifications to know when a device needs
      to be idle or not. We recently changed ath9k to force idle
      on driver stop() and on resume but forgot to take into account
      ath9k's own virtual wiphy idle states. These are used internally
      by ath9k to check if the device's radio should be powered down
      on each idle call. Without this change its possible that the
      device could have been forced off but the virtual wiphy idle
      was left on.
      
      Cc: stable@kernel.org
      Cc: Paul Stewart <pstew@google.com>
      Cc: Amod Bodas <amod.bodas@atheros.com>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      afe68d0a
    • R
      ath9k: Fix warnings on card removal · d584747b
      Rajkumar Manoharan 提交于
      The recently added warning message on power change failure
      is not needed on device removal.
      
      ath: Failed to wakeup in 500us
      ------------[ cut here ]------------
      WARNING: at drivers/net/wireless/ath/ath9k/hw.c:1618
      ath9k_hw_setpower+0x61f/0x630 [ath9k_hw]()
      Hardware name: 64756D6
      Pid: 540, comm: kworker/u:3 Not tainted 2.6.37-rc6-wl #37
      Call Trace:
       [<ffffffff810501aa>] warn_slowpath_common+0x7a/0xb0
       [<ffffffffa056e280>] ? ath9k_iowrite32+0x0/0x90 [ath9k]
       [<ffffffff810501f5>] warn_slowpath_null+0x15/0x20
       [<ffffffffa05226ef>] ath9k_hw_setpower+0x61f/0x630 [ath9k_hw]
       [<ffffffffa05700e5>] ath9k_ps_wakeup+0x85/0xd0 [ath9k]
       [<ffffffffa0570685>] ath9k_configure_filter+0x25/0x80 [ath9k]
       [<ffffffffa04dde43>] ieee80211_configure_filter+0x133/0x190 [mac80211]
       [<ffffffffa04ee502>] ieee80211_do_stop+0x132/0x540 [mac80211]
       [<ffffffff813466ff>] ? _raw_spin_unlock_bh+0x1f/0x30
       [<ffffffff812b6923>] ? dev_deactivate+0x1c3/0x1e0
       [<ffffffffa04ee925>] ieee80211_stop+0x15/0x20 [mac80211]
       [<ffffffff8129d1b6>] __dev_close+0x56/0x90
      Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d584747b
  3. 14 12月, 2010 1 次提交
    • L
      ath9k: fix assumptions for idle calls on suspend/resume · a08e7ade
      Luis R. Rodriguez 提交于
      mac80211 will notify drivers when to go idle and ath9k
      assumed that it would get further notifications for idle
      states after a device stop() config call but as per agreed
      semantics the idle state of the radio is left up to driver
      after mac80211 issues the stop() callback. The driver is
      resposnbile for ensuring the device remains idle after
      that even between suspend / resume calls.
      
      This fixes suspend/resume when you issue suspend and resume
      twice on ath9k when ath9k_stop() was already called. We need
      to put the radio to full sleep in order for resume to work
      correctly.
      
      What might seem fishy is we are turning the radio off
      after resume. The reason why we do this is because we know
      we should not have anything enabled after a mac80211 tells
      us to stop(), if we resume and never get a start() we won't
      get another stop() by mac80211 so to be safe always bring
      the 802.11 device with the radio disabled after resume,
      this ensures that if we suspend we already have the radio
      disabled and only a start() will ever trigger it on.
      
      Cc: stable@kernel.org
      Cc: Paul Stewart <pstew@google.com>
      Cc: Amod Bodas <amod.bodas@atheros.com>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a08e7ade
  4. 08 12月, 2010 3 次提交
  5. 19 11月, 2010 1 次提交
  6. 10 11月, 2010 1 次提交
  7. 28 7月, 2010 1 次提交
  8. 15 6月, 2010 1 次提交
  9. 22 5月, 2010 1 次提交
  10. 17 4月, 2010 1 次提交
  11. 07 4月, 2010 1 次提交
  12. 03 2月, 2010 1 次提交
  13. 02 2月, 2010 1 次提交
  14. 15 1月, 2010 1 次提交
  15. 13 1月, 2010 1 次提交
  16. 08 1月, 2010 1 次提交
  17. 29 12月, 2009 1 次提交
  18. 31 10月, 2009 2 次提交
  19. 08 10月, 2009 4 次提交
  20. 09 9月, 2009 5 次提交
  21. 20 8月, 2009 1 次提交
  22. 14 8月, 2009 1 次提交
  23. 05 8月, 2009 1 次提交
  24. 28 7月, 2009 1 次提交
  25. 19 6月, 2009 1 次提交
    • J
      ath9k: Fix PCI FATAL interrupts by restoring RETRY_TIMEOUT disabling · f0214843
      Jouni Malinen 提交于
      An earlier commit, 'ath9k: remove dummy PCI "retry timeout" fix', removed
      code that was documented to disable RETRY_TIMEOUT register (PCI reg
      0x41) since it was claimed to be a no-op. However, it turns out that
      there are some combinations of hosts and ath9k-supported cards for
      which this is not a no-op (reg 0x41 has value 0x80, not 0) and this
      code (or something similar) is needed. In such cases, the driver may
      be next to unusable due to very frequent PCI FATAL interrupts from the
      card.
      
      Reverting the earlier commit, i.e., restoring the RETRY_TIMEOUT
      disabling, seems to resolve the issue. Since the removal of this code
      was not based on any known issue and was purely a cleanup change, the
      safest option here is to just revert that commit. Should there be
      desire to clean this up in the future, the change will need to be
      tested with a more complete coverage of cards and host systems.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=13483
      
      Cc: stable@kernel.org
      Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f0214843
  26. 04 6月, 2009 1 次提交
    • J
      rfkill: rewrite · 19d337df
      Johannes Berg 提交于
      This patch completely rewrites the rfkill core to address
      the following deficiencies:
      
       * all rfkill drivers need to implement polling where necessary
         rather than having one central implementation
      
       * updating the rfkill state cannot be done from arbitrary
         contexts, forcing drivers to use schedule_work and requiring
         lots of code
      
       * rfkill drivers need to keep track of soft/hard blocked
         internally -- the core should do this
      
       * the rfkill API has many unexpected quirks, for example being
         asymmetric wrt. alloc/free and register/unregister
      
       * rfkill can call back into a driver from within a function the
         driver called -- this is prone to deadlocks and generally
         should be avoided
      
       * rfkill-input pointlessly is a separate module
      
       * drivers need to #ifdef rfkill functions (unless they want to
         depend on or select RFKILL) -- rfkill should provide inlines
         that do nothing if it isn't compiled in
      
       * the rfkill structure is not opaque -- drivers need to initialise
         it correctly (lots of sanity checking code required) -- instead
         force drivers to pass the right variables to rfkill_alloc()
      
       * the documentation is hard to read because it always assumes the
         reader is completely clueless and contains way TOO MANY CAPS
      
       * the rfkill code needlessly uses a lot of locks and atomic
         operations in locked sections
      
       * fix LED trigger to actually change the LED when the radio state
         changes -- this wasn't done before
      Tested-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
      Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad]
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      19d337df