1. 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
  2. 27 3月, 2012 1 次提交
    • E
      ath9k: fix a memory leak in ath_rx_tasklet() · b5447ff9
      Eric Dumazet 提交于
      commit 0d95521e (ath9k: use split rx buffers to get rid of order-1 skb
      allocations) added in memory leak in error path.
      
      sc->rx.frag should be cleared after the pskb_expand_head() call, or else
      we jump to requeue_drop_frag and leak an skb.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Cc: Jouni Malinen <jouni@qca.qualcomm.com>
      Cc: Felix Fietkau <nbd@openwrt.org>
      Cc: John W. Linville <linville@tuxdriver.com>
      Cc: Trond Wuellner <trond@chromium.org>
      Cc: Grant Grundler <grundler@chromium.org>
      Cc: Paul Stewart <pstew@chromium.org>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b5447ff9
  3. 13 3月, 2012 1 次提交
  4. 08 3月, 2012 2 次提交
  5. 06 3月, 2012 1 次提交
  6. 07 2月, 2012 1 次提交
  7. 20 12月, 2011 1 次提交
  8. 16 12月, 2011 1 次提交
  9. 01 12月, 2011 2 次提交
  10. 22 11月, 2011 1 次提交
  11. 12 10月, 2011 4 次提交
  12. 01 10月, 2011 1 次提交
  13. 27 9月, 2011 1 次提交
    • M
      ath9k: Fix a dma warning/memory leak · ba542385
      Mohammed Shafi Shajakhan 提交于
      proper dma_unmapping and freeing of skb's has to be done in the rx
      cleanup for EDMA chipsets when the device is unloaded and this also
      seems to address the following warning which shows up occasionally when
      the device is unloaded
      
      	Call Trace:
      	[<c0148cd2>] warn_slowpath_common+0x72/0xa0
      	[<c03b669c>] ? dma_debug_device_change+0x19c/0x200
      	[<c03b669c>] ? dma_debug_device_change+0x19c/0x200
      	[<c0148da3>] warn_slowpath_fmt+0x33/0x40
      	[<c03b669c>] dma_debug_device_change+0x19c/0x200
      	[<c0657f12>] notifier_call_chain+0x82/0xb0
      	[<c0171370>] __blocking_notifier_call_chain+0x60/0x90
      	[<c01713bf>] blocking_notifier_call_chain+0x1f/0x30
      	[<c044f594>] __device_release_driver+0xa4/0xc0
      	[<c044f647>] driver_detach+0x97/0xa0
      	[<c044e65c>] bus_remove_driver+0x6c/0xe0
      	[<c029af0b>] ? sysfs_addrm_finish+0x4b/0x60
      	[<c0450109>] driver_unregister+0x49/0x80
      	[<c0299f54>] ? sysfs_remove_file+0x14/0x20
      	[<c03c3ab2>] pci_unregister_driver+0x32/0x80
      	[<f92c2162>] ath_pci_exit+0x12/0x20 [ath9k]
      	[<f92c8467>] ath9k_exit+0x17/0x36 [ath9k]
      	[<c06523cd>] ? mutex_unlock+0xd/0x10
      	[<c018e27f>] sys_delete_module+0x13f/0x200
      	[<c02139bb>] ? sys_munmap+0x4b/0x60
      	[<c06547c5>] ? restore_all+0xf/0xf
      	[<c0657a20>] ? spurious_fault+0xe0/0xe0
      	[<c01832f4>] ? trace_hardirqs_on_caller+0xf4/0x180
      	[<c065b863>] sysenter_do_call+0x12/0x38
      	 ---[ end trace 16e1c1521c06bcf9 ]---
      	Mapped at:
      	[<c03b7938>] debug_dma_map_page+0x48/0x120
      	[<f92ba3e8>] ath_rx_init+0x3f8/0x4b0 [ath9k]
      	[<f92b5ae4>] ath9k_init_device+0x4c4/0x7b0 [ath9k]
      	[<f92c2813>] ath_pci_probe+0x263/0x330 [ath9k]
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ba542385
  14. 17 9月, 2011 1 次提交
  15. 15 9月, 2011 1 次提交
  16. 30 8月, 2011 2 次提交
  17. 25 8月, 2011 3 次提交
  18. 11 8月, 2011 1 次提交
  19. 10 8月, 2011 1 次提交
  20. 09 8月, 2011 1 次提交
  21. 16 7月, 2011 1 次提交
    • F
      ath9k: improve reliability of MIC error detection · 66760eac
      Felix Fietkau 提交于
      For unicast the hardware sometimes reports MIC errors even though the
      frame that it received actually contains a valid MIC - on some chips this
      can happen frequently enough to trigger TKIP countermeasures.
      Fix this issue by not reporting MIC errors for unicast frames with a
      valid key, letting mac80211 validate the MIC instead.
      
      Additionally, strip the MIC for all frames that the hardware considers
      valid to avoid wasting CPU cycles re-validating it.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      66760eac
  22. 23 6月, 2011 3 次提交
  23. 22 6月, 2011 1 次提交
    • A
      net: remove mm.h inclusion from netdevice.h · b7f080cf
      Alexey Dobriyan 提交于
      Remove linux/mm.h inclusion from netdevice.h -- it's unused (I've checked manually).
      
      To prevent mm.h inclusion via other channels also extract "enum dma_data_direction"
      definition into separate header. This tiny piece is what gluing netdevice.h with mm.h
      via "netdevice.h => dmaengine.h => dma-mapping.h => scatterlist.h => mm.h".
      Removal of mm.h from scatterlist.h was tried and was found not feasible
      on most archs, so the link was cutoff earlier.
      
      Hope people are OK with tiny include file.
      
      Note, that mm_types.h is still dragged in, but it is a separate story.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b7f080cf
  24. 20 5月, 2011 1 次提交
  25. 17 5月, 2011 4 次提交
  26. 11 5月, 2011 2 次提交