1. 18 7月, 2012 2 次提交
  2. 13 7月, 2012 1 次提交
  3. 07 6月, 2012 2 次提交
  4. 24 4月, 2012 1 次提交
  5. 12 4月, 2012 1 次提交
  6. 11 4月, 2012 2 次提交
  7. 10 4月, 2012 1 次提交
    • R
      ath9k: recover ar9380 chips from rare stuck state · 01e18918
      Rajkumar Manoharan 提交于
      In the experiment with Azimuth ADEPT-n testbed where the APs transmit
      power was reduced to 25% and the signal strength was futher attenuated
      by 20dB and induced a path loss of ~7dB, the station was reporting
      beacon losses and the following issue were observed.
      
      * rx clear is stuck at low for more than 300ms
      * dcu chain and complete state is stuck at one of the hang signature
      
      This patch triggers the hang detection logic that recovers the chip
      from any of the above conditions. As the issue was originally reported
      in ChromeOs with AR9382 chips, this detection logic is enabled only for
      AR9380/2 chips.
      
      Cc: Paul Stewart <pstew@google.com>
      Reported-by: NGary Morain <gmorain@google.com>
      Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      01e18918
  8. 27 3月, 2012 1 次提交
  9. 16 3月, 2012 3 次提交
  10. 08 3月, 2012 1 次提交
  11. 28 2月, 2012 2 次提交
  12. 04 2月, 2012 1 次提交
    • M
      ath9k: Fix kernel panic during driver initilization · 07445f68
      Mohammed Shafi Shajakhan 提交于
      all works need to be initialized before ieee80211_register_hw
      to prevent mac80211 call backs such as drv_start, drv_config
      getting started. otherwise we would queue/cancel works before
      initializing them and it leads to kernel panic.
      this issue can be recreated with the following script
      in Chrome laptops with AR928X cards, with background scan
      running (or) Network manager is running
      
      while true
      do
      sudo modprobe -v ath9k
      sleep 3
      sudo modprobe -r ath9k
      sleep 3
      done
      
      	 EIP: [<81040a47>] __cancel_work_timer+0xb8/0xe1 SS:ESP 0068:f6be9d70
      	 ---[ end trace 4f86d6139a9900ef ]---
      	 Registered led device: ath9k-phy0
      	 ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf88a0000,
      	 irq=16
      	 Kernel panic - not syncing: Fatal exception
      	 Pid: 456, comm: wpa_supplicant Tainted: G      D
      	 3.0.13 #1
      	Call Trace:
      	 [<81379e21>] panic+0x53/0x14a
      	 [<81004a30>] oops_end+0x73/0x81
      	 [<81004b53>] die+0x4c/0x55
      	 [<81002710>] do_trap+0x7c/0x83
      	 [<81002855>] ? do_bounds+0x58/0x58
      	 [<810028cc>] do_invalid_op+0x77/0x81
      	 [<81040a47>] ? __cancel_work_timer+0xb8/0xe1
      	 [<810489ec>] ? sched_clock_cpu+0x81/0x11f
      	 [<8103f809>] ? wait_on_work+0xe2/0xf7
      	 [<8137f807>] error_code+0x67/0x6c
      	 [<810300d8>] ? wait_consider_task+0x4ba/0x84c
      	 [<81040a47>] ? __cancel_work_timer+0xb8/0xe1
      	 [<810380c9>] ? try_to_del_timer_sync+0x5f/0x67
      	 [<81040a91>] cancel_work_sync+0xf/0x11
      	 [<f88d7b7c>] ath_set_channel+0x62/0x25c [ath9k]
      	 [<f88d67d1>] ? ath9k_tx_last_beacon+0x26a/0x85c [ath9k]
      	 [<f88d8899>] ath_radio_disable+0x3f1/0x68e [ath9k]
      	 [<f90d0edb>] ieee80211_hw_config+0x111/0x116 [mac80211]
      	 [<f90dd95c>] __ieee80211_recalc_idle+0x919/0xa37 [mac80211]
      	 [<f90dda76>] __ieee80211_recalc_idle+0xa33/0xa37 [mac80211]
      	 [<812dbed8>] __dev_open+0x82/0xab
      
      Cc: <stable@vger.kernel.org>
      Cc: Gary Morain <gmorain@google.com>
      Cc: Paul Stewart <pstew@google.com>
      Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
      Tested-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      07445f68
  13. 20 12月, 2011 2 次提交
  14. 14 12月, 2011 1 次提交
  15. 07 12月, 2011 1 次提交
  16. 01 12月, 2011 2 次提交
  17. 10 11月, 2011 1 次提交
  18. 09 11月, 2011 1 次提交
  19. 01 11月, 2011 1 次提交
  20. 12 10月, 2011 1 次提交
    • F
      ath9k_hw: clean up tx power handling · ca2c68cc
      Felix Fietkau 提交于
      The code for handling various restrictions concerning regulatory limits,
      antenna gain, etc. is very convoluted and duplicated across various
      EEPROM parsing implementations, making it hard to review.
      
      This patch partially cleans up the mess by unifying regulatory limit
      handling in one function and simplifying handling of antenna gain.
      It also removes unused transmit power scaling arrays from the EEPROM code,
      which belonged to an unimplemented API that isn't supposed to be in
      the driver anyway.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ca2c68cc
  21. 20 9月, 2011 1 次提交
  22. 15 9月, 2011 3 次提交
  23. 30 8月, 2011 1 次提交
  24. 25 8月, 2011 1 次提交
  25. 10 8月, 2011 1 次提交
  26. 09 8月, 2011 1 次提交
  27. 02 8月, 2011 1 次提交
  28. 19 7月, 2011 1 次提交
    • R
      ath9k: Fix sparse warnings · 5479de6e
      Rajkumar Manoharan 提交于
      drivers/net/wireless/ath/ath9k/init.c:199:21: warning: context imbalance
      in 'ath9k_reg_rmw' - different lock contexts for basic block
      drivers/net/wireless/ath/ath9k/xmit.c:1175:31: warning: context
      imbalance in 'ath_drain_txq_list' - unexpected unlock
      drivers/net/wireless/ath/ath9k/xmit.c:2047:23: warning: context
      imbalance in 'ath_tx_process_buffer' - unexpected unlock
      drivers/net/wireless/ath/ath9k/ar9003_eeprom.c:3041:24: warning: cast to
      restricted __le32
      Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5479de6e
  29. 30 6月, 2011 1 次提交
  30. 23 6月, 2011 1 次提交