1. 21 Nov, 2011 1 commit
  2. 11 Oct, 2011 4 commits
  3. 30 Sep, 2011 1 commit
  4. 26 Sep, 2011 1 commit
    • Mohammed Shafi Shajakhan's avatar
      ath9k: Fix a dma warning/memory leak · ba542385
      Mohammed Shafi Shajakhan authored
      
      
      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: default avatarMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      ba542385
  5. 16 Sep, 2011 1 commit
  6. 14 Sep, 2011 1 commit
  7. 29 Aug, 2011 2 commits
  8. 24 Aug, 2011 3 commits
  9. 10 Aug, 2011 1 commit
  10. 09 Aug, 2011 1 commit
  11. 08 Aug, 2011 1 commit
  12. 15 Jul, 2011 1 commit
    • Felix Fietkau's avatar
      ath9k: improve reliability of MIC error detection · 66760eac
      Felix Fietkau authored
      
      
      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: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      66760eac
  13. 22 Jun, 2011 3 commits
  14. 21 Jun, 2011 1 commit
    • Alexey Dobriyan's avatar
      net: remove mm.h inclusion from netdevice.h · b7f080cf
      Alexey Dobriyan authored
      
      
      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: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b7f080cf
  15. 19 May, 2011 1 commit
  16. 16 May, 2011 4 commits
  17. 10 May, 2011 2 commits
  18. 25 Apr, 2011 2 commits
  19. 19 Apr, 2011 1 commit
  20. 12 Apr, 2011 3 commits
    • Felix Fietkau's avatar
      ath9k: fix too early enabling of rx during ath_startrecv() · 95294973
      Felix Fietkau authored
      
      
      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: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      95294973
    • Felix Fietkau's avatar
      ath9k: fix PS-Poll reception on AR9160 and earlier · 264bbec8
      Felix Fietkau authored
      
      
      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: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      264bbec8
    • Felix Fietkau's avatar
      ath9k_hw: fix stopping rx DMA during resets · 5882da02
      Felix Fietkau authored
      
      
      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: default avatarFelix Fietkau <nbd@openwrt.org>
      Cc: stable@kernel.org
      Cc: Kyungwan Nam <Kyungwan.Nam@Atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5882da02
  21. 07 Apr, 2011 1 commit
    • Rajkumar Manoharan's avatar
      ath9k: configure beacons based on hw opmode · 99e4d43a
      Rajkumar Manoharan authored
      
      
      Current ath9k code does not handle beacon timers on opmode
      specific. One such example is that a STA beacon config overwrites
      already configured AP vif's beacon timers during scan.
      
      On multi station vif case, configure beacon timers beased
      on primary vif selected. This also helps while moving back
      to single STA vif from multi STA vifs, where the power save
      is enabled and hw has to be reconfigured with proper
      beacon and bssid/aid. Otherwise connection poll will be triggered
      so frequently due to beacon loss.
      
      Signed-off-by: default avatarRajkumar Manoharan <rmanoharan@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      99e4d43a
  22. 11 Mar, 2011 1 commit
    • Felix Fietkau's avatar
      ath9k: remove support for the FIF_PROMISC_IN_BSS filter flag · 2e286947
      Felix Fietkau authored
      
      
      The hardware rx filter flag triggered by FIF_PROMISC_IN_BSS is overly broad
      and covers even frames with PHY errors. When this flag is enabled, this message
      shows up frequently during scanning or hardware resets:
      
      ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
      
      Since promiscuous mode is usually not particularly useful, yet enabled by
      default by bridging (either used normally in 4-addr mode, or with hacks
      for various virtualization software), we should sacrifice it for better
      reliability during normal operation.
      
      This patch leaves it enabled if there are active monitor mode interfaces, since
      it's very useful for debugging.
      
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2e286947
  23. 23 Feb, 2011 1 commit
  24. 28 Jan, 2011 2 commits