1. 19 3月, 2013 1 次提交
  2. 11 12月, 2012 3 次提交
  3. 22 11月, 2012 2 次提交
  4. 20 10月, 2012 1 次提交
    • R
      ath9k: perform ANI cycle in idle state · 424749c7
      Rajkumar Manoharan 提交于
      As of now the ANI cycle is executed only when the chip is awake.
      On idle state case, the station wakes up from network sleep for
      beacon reception. Since most of the time, ANI cycle is not syncing
      with beacon wakeup, ANI cycle is ignored. Approx 5 mins once, the
      calibration is performed. This could affect the connection stability
      when the station is idle for long. Even though the OFDM and CCK phy
      error rates are too high, ANI is unable to tune its immunity level
      as quick enough due to rare execution.
      
      Here the experiment shows that OFDM and CCK levels are at default
      even on higher phy error rate.
      
      listenTime=44 OFDM:3 errs=121977/s CCK:2 errs=440818/s ofdm_turn=1
      
      This change ensures that ANI calibration will be exectued atleast
      once for every 10 seconds. The below result shows improvements and
      immunity levels are adopted quick enough.
      
      listenTime=557 OFDM:4 errs=752/s CCK:4 errs=125/s ofdm_turn=0
      Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      424749c7
  5. 11 9月, 2012 1 次提交
  6. 06 9月, 2012 2 次提交
  7. 18 7月, 2012 2 次提交
  8. 21 6月, 2012 1 次提交
  9. 14 6月, 2012 1 次提交
    • M
      ath9k: Fix softlockup in AR9485 · 64bc1239
      Mohammed Shafi Shajakhan 提交于
      steps to recreate:
      load latest ath9k driver with AR9485
      stop the network-manager and wpa_supplicant
      bring the interface up
      
      	Call Trace:
      	[<ffffffffa0517490>] ? ath_hw_check+0xe0/0xe0 [ath9k]
      	[<ffffffff812cd1e8>] __const_udelay+0x28/0x30
      	[<ffffffffa03bae7a>] ar9003_get_pll_sqsum_dvc+0x4a/0x80 [ath9k_hw]
      	[<ffffffffa05174eb>] ath_hw_pll_work+0x5b/0xe0 [ath9k]
      	[<ffffffff810744fe>] process_one_work+0x11e/0x470
      	[<ffffffff8107530f>] worker_thread+0x15f/0x360
      	[<ffffffff810751b0>] ? manage_workers+0x230/0x230
      	[<ffffffff81079af3>] kthread+0x93/0xa0
      	[<ffffffff815fd3a4>] kernel_thread_helper+0x4/0x10
      	[<ffffffff81079a60>] ? kthread_freezable_should_stop+0x70/0x70
      	[<ffffffff815fd3a0>] ? gs_change+0x13/0x13
      
      ensure that the PLL-WAR for AR9485/AR9340 is executed only if the STA is
      associated (or) IBSS/AP mode had started beaconing. Ideally this WAR
      is needed to recover from some rare beacon stuck during stress testing.
      Before the STA is associated/IBSS had started beaconing, PLL4(0x1618c)
      always seem to have zero even though we had configured PLL3(0x16188) to
      query about PLL's locking status. When we keep on polling infinitely PLL4's
      8th bit(ie check for PLL locking measurements is done), machine hangs
      due to softlockup.
      
      fixes https://bugzilla.redhat.com/show_bug.cgi?id=811142Reported-by: NRolf Offermanns <rolf.offermanns@gmx.net>
      Cc: stable@vger.kernel.org
      Tested-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      64bc1239
  10. 07 6月, 2012 3 次提交