1. 13 Dec, 2010 2 commits
    • Luis R. Rodriguez's avatar
      ath9k: fix assumptions for idle calls on suspend/resume · a08e7ade
      Luis R. Rodriguez authored
      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: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a08e7ade
    • Luis R. Rodriguez's avatar
      ath9k: Fix power save count imbalance on ath_radio_enable() · c2731b81
      Luis R. Rodriguez authored
      Upon a failure we never call ath9k_ps_restore() on ath_radio_enable(),
      this will throw off the sc->ps_usecount. When the sc->ps_usecount
      is > 0 we never put the chip to full sleep. This drains battery,
      and will also make the chip fail upon resume with:
      
      ath: Starting driver with initial channel: 5745 MHz
      ath: timeout (100000 us) on reg 0x7000: 0xdeadbeef & 0x00000003 != 0x00000000
      
      This would make the chip useless upon resume.
      
      I cannot prove this can happen but in theory it is so best to
      avoid this race completely and not have users complain about
      a broken device after resume.
      
      Cc: stable@kernel.org
      Cc: Paul Stewart <pstew@google.com>
      Cc: Amod Bodas <amod.bodas@atheros.com>
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      c2731b81
  2. 09 Dec, 2010 2 commits
  3. 08 Dec, 2010 24 commits
  4. 07 Dec, 2010 12 commits