1. 04 2月, 2011 1 次提交
  2. 02 2月, 2011 1 次提交
  3. 01 2月, 2011 1 次提交
  4. 29 1月, 2011 7 次提交
  5. 28 1月, 2011 1 次提交
  6. 22 1月, 2011 2 次提交
  7. 20 1月, 2011 3 次提交
    • J
      mac80211: track receiver's aggregation reorder buffer size · 0b01f030
      Johannes Berg 提交于
      The aggregation code currently doesn't implement the
      buffer size negotiation. It will always request a max
      buffer size (which is fine, if a little pointless, as
      the mac80211 code doesn't know and might just use 0
      instead), but if the peer requests a smaller size it
      isn't possible to honour this request.
      
      In order to fix this, look at the buffer size in the
      addBA response frame, keep track of it and pass it to
      the driver in the ampdu_action callback when called
      with the IEEE80211_AMPDU_TX_OPERATIONAL action. That
      way the driver can limit the number of subframes in
      aggregates appropriately.
      
      Note that this doesn't fix any drivers apart from the
      addition of the new argument -- they all need to be
      updated separately to use this variable!
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0b01f030
    • B
      ath9k: Fix up hardware mode and beacons with multiple vifs. · 4801416c
      Ben Greear 提交于
      When using a mixture of AP and Station interfaces,
      the hardware mode was using the type of the
      last VIF registered.  Instead, we should keep track
      of the number of different types of vifs and set the
      mode accordingly.
      
      In addtion, use the vif type instead of hardware opmode
      when dealing with beacons.
      
      Attempt to move some of the common setup code into smaller
      methods so we can re-use it when changing vif mode as
      well as adding/deleting vifs.
      Signed-off-by: NBen Greear <greearb@candelatech.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4801416c
    • F
      ath9k: reduce the likelihood of baseband hang check false positives · 8b3f4616
      Felix Fietkau 提交于
      Since baseband hangs are rare, but the hang check function has a high
      false positive rate in some situations, we need to add more reliable
      indicators.
      
      In AP mode we can use blocked beacon transmissions as an indicator,
      they should be rare enough.
      
      In station mode, we can skip the hang check entirely, since a true
      hang will trigger beacon loss detection, and mac80211 will rescan,
      which leads to a hw reset that will bring the hardware back to life.
      
      To make this more reliable, we need to skip fast channel changes
      if the hardware appears to be stuck.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8b3f4616
  8. 06 1月, 2011 1 次提交
  9. 05 1月, 2011 2 次提交
  10. 23 12月, 2010 2 次提交
  11. 21 12月, 2010 1 次提交
  12. 17 12月, 2010 1 次提交
  13. 16 12月, 2010 2 次提交
  14. 14 12月, 2010 6 次提交
  15. 09 12月, 2010 1 次提交
  16. 08 12月, 2010 5 次提交
  17. 01 12月, 2010 1 次提交
  18. 30 11月, 2010 2 次提交
    • R
      ath9k: Disable SWBA interrupt on remove_interface · 46047784
      Rajkumar Manoharan 提交于
      while removing beaconing mode interface, SWBA interrupt
      was never disabled when there are no other beaconing interfaces.
      
      Cc: stable@kernel.org
      Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      46047784
    • 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