1. 12 1月, 2013 2 次提交
  2. 12 12月, 2012 1 次提交
  3. 14 11月, 2012 1 次提交
  4. 30 10月, 2012 1 次提交
  5. 29 9月, 2012 1 次提交
  6. 14 8月, 2012 1 次提交
    • L
      ath9k: fix decrypt_error initialization in ath_rx_tasklet() · e1352fde
      Lorenzo Bianconi 提交于
      ath_rx_tasklet() calls ath9k_rx_skb_preprocess() and ath9k_rx_skb_postprocess()
      in a loop over the received frames. The decrypt_error flag is
      initialized to false
      just outside ath_rx_tasklet() loop. ath9k_rx_accept(), called by
      ath9k_rx_skb_preprocess(),
      only sets decrypt_error to true and never to false.
      Then ath_rx_tasklet() calls ath9k_rx_skb_postprocess() and passes
      decrypt_error to it.
      So, after a decryption error, in ath9k_rx_skb_postprocess(), we can
      have a leftover value
      from another processed frame. In that case, the frame will not be marked with
      RX_FLAG_DECRYPTED even if it is decrypted correctly.
      When using CCMP encryption this issue can lead to connection stuck
      because of CCMP
      PN corruption and a waste of CPU time since mac80211 tries to decrypt an already
      deciphered frame with ieee80211_aes_ccm_decrypt.
      Fix the issue initializing decrypt_error flag at the begging of the
      ath_rx_tasklet() loop.
      Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi83@gmail.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e1352fde
  7. 18 7月, 2012 1 次提交
    • S
      ath9k: Cleanup beacon logic · ef4ad633
      Sujith Manoharan 提交于
      * The beaconing status routine is not required, since in
        multi-VIF cases the HW beacon parameters should not be
        re-configured.
      
      * Remove SC_OP_TSF_RESET - when a beaconing interface comes
        up the first time, the TSF has to be reset.
      
      * Simplify ath9k_allow_beacon_config().
      
      * Handle setting/clearing the SWBA interrupt properly.
      
      * Remove the TSF mangling in IBSS mode, it is not required.
      
      * General code cleanup.
      Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ef4ad633
  8. 10 7月, 2012 1 次提交
  9. 28 6月, 2012 1 次提交
    • T
      ath9k: fix panic caused by returning a descriptor we have queued for reuse · 6bb51c70
      Tom Hughes 提交于
      Commit 3a2923e8 introduced a bug when a corrupt descriptor
      is encountered - although the following descriptor is discarded
      and returned to the queue for reuse the associated frame is
      also returned for processing. This leads to a panic:
      
      BUG: unable to handle kernel NULL pointer dereference at 000000000000003a
      IP: [<ffffffffa02599a5>] ath_rx_tasklet+0x165/0x1b00 [ath9k]
      Call Trace:
      <IRQ>
      [<ffffffff812d7fa0>] ? map_single+0x60/0x60
      [<ffffffffa028f044>] ? ath9k_ioread32+0x34/0x90 [ath9k]
      [<ffffffffa0292eec>] athk9k_tasklet+0xdc/0x160 [ath9k]
      [<ffffffff8105e133>] tasklet_action+0x63/0xd0
      [<ffffffff8105dbc0>] __do_softirq+0xc0/0x1e0
      [<ffffffff8101a873>] ? native_sched_clock+0x13/0x80
      [<ffffffff815f9d5c>] call_softirq+0x1c/0x30
      [<ffffffff810151f5>] do_softirq+0x75/0xb0
      [<ffffffff8105df95>] irq_exit+0xb5/0xc0
      [<ffffffff815fa5b3>] do_IRQ+0x63/0xe0
      [<ffffffff815f0cea>] common_interrupt+0x6a/0x6a
      <EOI>
      [<ffffffff8131840a>] ? intel_idle+0xea/0x150
      [<ffffffff813183eb>] ? intel_idle+0xcb/0x150
      [<ffffffff814a1db9>] cpuidle_enter+0x19/0x20
      [<ffffffff814a23d9>] cpuidle_idle_call+0xa9/0x240
      [<ffffffff8101c4bf>] cpu_idle+0xaf/0x120
      [<ffffffff815cda8e>] rest_init+0x72/0x74
      [<ffffffff81cf4c1a>] start_kernel+0x3b7/0x3c4
      [<ffffffff81cf4662>] ? repair_env_string+0x5e/0x5e
      [<ffffffff81cf4346>] x86_64_start_reservations+0x131/0x135
      [<ffffffff81cf444a>] x86_64_start_kernel+0x100/0x10f
      
      Making sure bf is cleared to NULL in this case restores the
      old behaviour.
      Signed-off-by: NTom Hughes <tom@compton.nu>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6bb51c70
  10. 26 6月, 2012 1 次提交
  11. 07 6月, 2012 5 次提交
  12. 11 5月, 2012 1 次提交
    • J
      drivers/net: Convert compare_ether_addr to ether_addr_equal · 2e42e474
      Joe Perches 提交于
      Use the new bool function ether_addr_equal to add
      some clarity and reduce the likelihood for misuse
      of compare_ether_addr for sorting.
      
      Done via cocci script:
      
      $ cat compare_ether_addr.cocci
      @@
      expression a,b;
      @@
      -	!compare_ether_addr(a, b)
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	compare_ether_addr(a, b)
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!ether_addr_equal(a, b) == 0
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!ether_addr_equal(a, b) != 0
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	ether_addr_equal(a, b) == 0
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	ether_addr_equal(a, b) != 0
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!!ether_addr_equal(a, b)
      +	ether_addr_equal(a, b)
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2e42e474
  13. 24 4月, 2012 2 次提交
  14. 12 4月, 2012 1 次提交
  15. 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
  16. 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
  17. 13 3月, 2012 1 次提交
  18. 08 3月, 2012 2 次提交
  19. 06 3月, 2012 1 次提交
  20. 07 2月, 2012 1 次提交
  21. 20 12月, 2011 1 次提交
  22. 16 12月, 2011 1 次提交
  23. 01 12月, 2011 2 次提交
  24. 22 11月, 2011 1 次提交
  25. 12 10月, 2011 4 次提交
  26. 01 10月, 2011 1 次提交
  27. 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
  28. 17 9月, 2011 1 次提交
  29. 15 9月, 2011 1 次提交