1. 07 2月, 2012 1 次提交
  2. 20 12月, 2011 1 次提交
  3. 16 12月, 2011 1 次提交
  4. 01 12月, 2011 2 次提交
  5. 22 11月, 2011 1 次提交
  6. 12 10月, 2011 4 次提交
  7. 01 10月, 2011 1 次提交
  8. 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
  9. 17 9月, 2011 1 次提交
  10. 15 9月, 2011 1 次提交
  11. 30 8月, 2011 2 次提交
  12. 25 8月, 2011 3 次提交
  13. 11 8月, 2011 1 次提交
  14. 10 8月, 2011 1 次提交
  15. 09 8月, 2011 1 次提交
  16. 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
  17. 23 6月, 2011 3 次提交
  18. 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
  19. 20 5月, 2011 1 次提交
  20. 17 5月, 2011 4 次提交
  21. 11 5月, 2011 2 次提交
  22. 26 4月, 2011 2 次提交
  23. 20 4月, 2011 1 次提交
  24. 13 4月, 2011 3 次提交
    • F
      ath9k: fix too early enabling of rx during ath_startrecv() · 95294973
      Felix Fietkau 提交于
      rx should only be enabled after enough rx buffers have been given to the
      hardware, however ath_rx_buf_link was calling ath9k_hw_rxena after every
      single added buffer.
      Fix this by calling ath9k_hw_rxena directly from the rx tasklet after
      completion instead.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      95294973
    • F
      ath9k: fix PS-Poll reception on AR9160 and earlier · 264bbec8
      Felix Fietkau 提交于
      I can't find any valid reason for not setting the ATH9K_RX_FILTER_PSPOLL
      flag on older hardware and neither the documentation nor the reference
      code mention any reason for excluding older hardware here.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      264bbec8
    • F
      ath9k_hw: fix stopping rx DMA during resets · 5882da02
      Felix Fietkau 提交于
      During PHY errors, the MAC can sometimes fail to enter an idle state on older
      hardware (before AR9380) after an rx stop has been requested.
      
      This typically shows up in the kernel log with messages like these:
      
      ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
      ------------[ cut here ]------------
      WARNING: at drivers/net/wireless/ath/ath9k/recv.c:504 ath_stoprecv+0xcc/0xf0 [ath9k]()
      Call Trace:
      [<8023f0e8>] dump_stack+0x8/0x34
      [<80075050>] warn_slowpath_common+0x78/0xa4
      [<80075094>] warn_slowpath_null+0x18/0x24
      [<80d66d60>] ath_stoprecv+0xcc/0xf0 [ath9k]
      [<80d642cc>] ath_set_channel+0xbc/0x270 [ath9k]
      [<80d65254>] ath_radio_disable+0x4a4/0x7fc [ath9k]
      
      When this happens, the state that the MAC enters is easy to identify and
      does not result in bogus DMA traffic, however to ensure a working state
      after a channel change, the hardware should still be reset.
      
      This patch adds detection for this specific MAC state, after which the above
      warnings completely disappear in my tests.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Cc: stable@kernel.org
      Cc: Kyungwan Nam <Kyungwan.Nam@Atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5882da02