1. 20 4月, 2011 1 次提交
    • F
      ath9k: fix powersave frame filtering/buffering in AP mode · 5519541d
      Felix Fietkau 提交于
      This patch fixes a long standing issue of pending packets in the queue being
      sent (and retransmitted many times) to sleeping stations.
      This was made worse by aggregation through driver-internal retransmitting
      of A-MDPU subframes.
      Previously the hardware tx filter was cleared unconditionally for every
      single packet - with this patch it uses the IEEE80211_TX_CTL_CLEAR_PS_FILT
      for unaggregated frames.
      A sta_notify driver op is added to stop aggregation for stations when they
      enter powersave mode. Subframes stay buffered inside the driver, to ensure
      that the BlockAck window keeps a sane state.
      Since the driver uses software aggregation, the clearing of the tx filter
      needs to be handled by the driver instead of mac80211 for aggregated frames.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5519541d
  2. 14 4月, 2011 1 次提交
    • G
      ath9k: introduce ATH9K_{PCI,AHB} config options · 8e26a030
      Gabor Juhos 提交于
      Currently ath9k only available in menuconfig if PCI bus
      support is enabled. However the driver is required for
      the built-in wireless MACs of the Atheros AR9130/AR9132
      SoCs. These SoCs have no PCI controller, the wireless
      MAC is connected to the AHB bus on them.
      
      Introduce separated config options for the supported
      buses, in order to allow building of ath9h without PCI
      bus support.
      
      As a bonus, this patch removes the cross-reference of
      the ATHEROS_AR71XX option which is not present in the
      kernel.
      
      Cc: Luis R. Rodriguez <lrodriguez@atheros.com>
      Cc: Vasanthakumar Thiagarajan <vasanth@atheros.com>
      Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8e26a030
  3. 08 4月, 2011 3 次提交
  4. 05 4月, 2011 1 次提交
  5. 31 3月, 2011 2 次提交
    • F
      ath9k: fix stuck beacon detection · c944daf4
      Felix Fietkau 提交于
      Stuck beacon detection is supposed to trigger when 9 consecutive beacons
      could not be sent by the hardware. When the driver runs only one active
      AP mode interface, it still configures the hardware beacon timer for
      4 (ATH_BCBUF) beacon slots slots, which causes stuck beacon detection
      to be reset if ath9k_hw_stoptxdma clears the stuck frames between
      SWBA intervals.
      Fix this by not resetting the missed beacon count for empty slots and
      multiplying the threshold not by the maximum number of beacon slots
      but by the configured number of beacon interfaces.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c944daf4
    • F
      ath9k: fix beacon timer handling issues · dd347f2f
      Felix Fietkau 提交于
      AP mode beacon timers in ath9k are configured in milliseconds, which breaks
      when increasing ATH_BCBUF to 8 instead of 4 (due to rounding errors).
      Since the hardware timers are actually configured in microseconds, it's
      better to let the driver use that unit directly.
      
      To be able to do that, the beacon interval parameter abuse for passing
      certain flags needs to be removed. This is easy to do, because those flags
      are completely unnecessary anyway. ATH9K_BEACON_ENA is ignored,
      ATH9K_BEACON_RESET_TSF can be replaced with calling ath9k_hw_reset_tsf
      from the driver directly.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      dd347f2f
  6. 15 3月, 2011 1 次提交
  7. 01 3月, 2011 2 次提交
  8. 22 2月, 2011 1 次提交
  9. 16 2月, 2011 1 次提交
  10. 15 2月, 2011 1 次提交
  11. 10 2月, 2011 1 次提交
  12. 05 2月, 2011 2 次提交
    • F
      ath9k: add additional checks for the baseband hang detection · cb8d61de
      Felix Fietkau 提交于
      Since even with the latest changes the false positive issue of the baseband
      hang check is not fully solved yet, additional checks are needed.
      If the baseband hang occurs, the rx_clear signal will be stuck to high, so
      we can use the cycle counters to confirm it.
      With this patch, a hardware reset is only triggered if the baseband hang
      check returned true three times in a row, with a beacon interval between
      each check and if the busy time was also 99% or more during the check
      intervals.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      cb8d61de
    • M
      ath9k: Fix possible double free of PAPRD skb's · 9cf04dcc
      Mohammed Shafi Shajakhan 提交于
      This patch reverts the following commit
      ath9k: remove bfs_paprd_timestamp from struct ath_buf_state
      
      Under high interference/noisy environment conditions where PAPRD frames
      fails heavily introduces a possibility of double freeing skb's and causes
      kernel panic after some time.This patch reverts back to the original approach
      of using paprd_timestamp before freeing the PAPRD frame skb's
      
      [  194.193705] Pid: 0, comm: swapper Tainted: G      D WC
      2.6.35-22-generic #33-Ubuntu
      [  194.193712] Call Trace:
      [  194.193722]  [<c05c6468>] ? printk+0x2d/0x35
      [  194.193732]  [<c05c63c3>] panic+0x5a/0xd2
      [  194.193741]  [<c05ca3ed>] oops_end+0xcd/0xd0
      [  194.193750]  [<c0105f74>] die+0x54/0x80
      [  194.193758]  [<c05c9a16>] do_trap+0x96/0xc0
      [  194.193837]  [<c0103fb0>] ? do_invalid_op+0x0/0xa0
      [  194.193846]  [<c010403b>] do_invalid_op+0x8b/0xa0
      [  194.193856]  [<c020bd4c>] ? kfree+0xec/0xf0
      [  194.193866]  [<c012ce18>] ? default_spin_lock_flags+0x8/0x10
      [  194.193877]  [<c01de47a>] ? free_one_page+0x12a/0x2d0
      [  194.193888]  [<c01e04dc>] ? __free_pages+0x1c/0x40
      [  194.193897]  [<c05c97a7>] error_code+0x73/0x78
      [  194.193906]  [<c020bd4c>] ? kfree+0xec/0xf0
      [  194.193915]  [<c04ecdd0>] ? skb_release_data+0x70/0xa0
      [  194.193924]  [<c04ecdd0>] skb_release_data+0x70/0xa0
      [  194.193933]  [<c04ec997>] __kfree_skb+0x17/0x90
      [  194.193941]  [<c04eca31>] consume_skb+0x21/0x40
      [  194.193964]  [<f85e0b70>] ieee80211_tx_status+0x760/0x860 [mac80211]
      [  194.193979]  [<f85caddf>] ath_tx_complete_buf+0x1bf/0x2c0 [ath9k]
      [  194.193988]  [<c05c8b9f>] ? _raw_spin_lock_irqsave+0x2f/0x50
      [  194.193997]  [<c04ec40e>] ? skb_queue_tail+0x3e/0x50
      [  194.194010]  [<f85cc803>] ath_tx_complete_aggr+0x823/0x940 [ath9k]
      [  194.194021]  [<c0108a28>] ? sched_clock+0x8/0x10
      [  194.194030]  [<c016bf14>] ? sched_clock_local+0xa4/0x180
      [  194.194040]  [<c0139f57>] ? enqueue_sleeper+0x1e7/0x2b0
      [  194.194051]  [<c013a194>] ? enqueue_entity+0x174/0x200
      [  194.194064]  [<f85ce83d>] ath_tx_edma_tasklet+0x2bd/0x3b0 [ath9k]
      [  194.194074]  [<c05c8b9f>] ? _raw_spin_lock_irqsave+0x2f/0x50
      [  194.194088]  [<f85c7b9f>] ath9k_tasklet+0x9f/0x190 [ath9k]
      [  194.194097]  [<c01505d7>] tasklet_action+0xa7/0xb0
      [  194.194107]  [<c015127c>] __do_softirq+0x9c/0x1b0
      [  194.194117]  [<c01a7f64>] ? irq_to_desc+0x14/0x20
      [  194.194126]  [<c0124fc4>] ? ack_apic_level+0x64/0x1f0
      [  194.194136]  [<c01513d5>] do_softirq+0x45/0x50
      [  194.194145]  [<c0151545>] irq_exit+0x65/0x70
      [  194.194153]  [<c05cf665>] do_IRQ+0x55/0xc0
      [  194.194162]  [<c016a6c7>] ? hrtimer_start+0x27/0x30
      [  194.194171]  [<c0103630>] common_interrupt+0x30/0x38
      [  194.194181]  [<c012c21a>] ? native_safe_halt+0xa/0x10
      [  194.194268]  [<c010a2f9>] default_idle+0x49/0xb0
      [  194.194277]  [<c0101fcc>] cpu_idle+0x8c/0xd0
      [  194.194286]  [<c05b2431>] rest_init+0x71/0x80
      [  194.194295]  [<c081981a>] start_kernel+0x36e/0x374
      [  194.194305]  [<c08199dd>] ? pass_all_bootoptions+0x0/0xa
      [  194.194314]  [<c08190d7>] i386_start_kernel+0xd7/0xdf
      [  194.194364] panic occurred, switching back to text console
      Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9cf04dcc
  13. 29 1月, 2011 7 次提交
  14. 27 1月, 2011 1 次提交
  15. 22 1月, 2011 3 次提交
  16. 20 1月, 2011 1 次提交
  17. 06 1月, 2011 1 次提交
  18. 23 12月, 2010 2 次提交
    • M
      ath9k: Reset keycache on resume · db7ec38d
      Mohammed Shafi Shajakhan 提交于
      It looks like some hardware registers are left into undefined state
      after suspend/resume. At minimum, this can cause odd issues related to
      key cache and hardware trying to encrypt/decrypt frames unexpectedly.
      This seems to happen even when there is no keys configured, i.e., hardware
      can end up touching TX frames just based of invalid key cache context
      even if the driver is not asking a specific entry to be used. In
      addition, RX can likely be affected. This patch fixes this issue.
      Signed-off-by: NJouni Malinen <Jouni.Malinen@Atheros.com>
      Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      db7ec38d
    • R
      ath9k: Fix warnings on card removal · d584747b
      Rajkumar Manoharan 提交于
      The recently added warning message on power change failure
      is not needed on device removal.
      
      ath: Failed to wakeup in 500us
      ------------[ cut here ]------------
      WARNING: at drivers/net/wireless/ath/ath9k/hw.c:1618
      ath9k_hw_setpower+0x61f/0x630 [ath9k_hw]()
      Hardware name: 64756D6
      Pid: 540, comm: kworker/u:3 Not tainted 2.6.37-rc6-wl #37
      Call Trace:
       [<ffffffff810501aa>] warn_slowpath_common+0x7a/0xb0
       [<ffffffffa056e280>] ? ath9k_iowrite32+0x0/0x90 [ath9k]
       [<ffffffff810501f5>] warn_slowpath_null+0x15/0x20
       [<ffffffffa05226ef>] ath9k_hw_setpower+0x61f/0x630 [ath9k_hw]
       [<ffffffffa05700e5>] ath9k_ps_wakeup+0x85/0xd0 [ath9k]
       [<ffffffffa0570685>] ath9k_configure_filter+0x25/0x80 [ath9k]
       [<ffffffffa04dde43>] ieee80211_configure_filter+0x133/0x190 [mac80211]
       [<ffffffffa04ee502>] ieee80211_do_stop+0x132/0x540 [mac80211]
       [<ffffffff813466ff>] ? _raw_spin_unlock_bh+0x1f/0x30
       [<ffffffff812b6923>] ? dev_deactivate+0x1c3/0x1e0
       [<ffffffffa04ee925>] ieee80211_stop+0x15/0x20 [mac80211]
       [<ffffffff8129d1b6>] __dev_close+0x56/0x90
      Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d584747b
  19. 21 12月, 2010 2 次提交
  20. 16 12月, 2010 1 次提交
  21. 08 12月, 2010 1 次提交
  22. 01 12月, 2010 1 次提交
  23. 30 11月, 2010 1 次提交
    • G
      ath9k: use per-device struct for pm_qos_* operations · 98c316e3
      Gabor Juhos 提交于
      The ath9k driver uses a shared pm_qos_request_list structure for all
      devices. This causes the following warning if more than one device is
      present in the system:
      
      WARNING: at kernel/pm_qos_params.c:234 ath9k_init_device+0x5e8/0x6b0()
      pm_qos_add_request() called for already added request
      Modules linked in:
      Call Trace:
      [<802b1cdc>] dump_stack+0x8/0x34
      [<8007dd90>] warn_slowpath_common+0x78/0xa4
      [<8007de44>] warn_slowpath_fmt+0x2c/0x38
      [<801b0828>] ath9k_init_device+0x5e8/0x6b0
      [<801bc508>] ath_pci_probe+0x2dc/0x39c
      [<80176254>] pci_device_probe+0x64/0xa4
      [<8019471c>] driver_probe_device+0xbc/0x188
      [<80194854>] __driver_attach+0x6c/0xa4
      [<80193e20>] bus_for_each_dev+0x60/0xb0
      [<80193580>] bus_add_driver+0xcc/0x268
      [<80194c08>] driver_register+0xe0/0x198
      [<801764e0>] __pci_register_driver+0x50/0xe0
      [<80365f48>] ath9k_init+0x3c/0x6c
      [<8006050c>] do_one_initcall+0xfc/0x1d8
      [<80355340>] kernel_init+0xd4/0x174
      [<800639a4>] kernel_thread_helper+0x10/0x18
      
      ---[ end trace 5345fc6f870564a6 ]---
      
      This patch fixes that warning by using a separate pm_qos_request_list
      sructure for each device.
      Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      98c316e3
  24. 18 11月, 2010 2 次提交