1. 01 10月, 2011 1 次提交
    • J
      mac80211: allow releasing driver-buffered frames · 4049e09a
      Johannes Berg 提交于
      If there are frames for a station buffered in
      the driver, mac80211 announces those in the TIM
      IE but there's no way to release them. Add new
      API to release such frames and use it when the
      station polls for a frame.
      
      Since the API will soon also be used for uAPSD
      it is easily extensible.
      
      Note that before this change drivers announcing
      driver-buffered frames in the TIM bit actually
      will respond to a PS-Poll with a potentially
      lower priority frame (if there are any frames
      buffered in mac80211), after this patch a driver
      that hasn't been changed will no longer respond
      at all. This only affects ath9k, which will need
      to be fixed to implement the new API.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4049e09a
  2. 28 9月, 2011 2 次提交
  3. 09 8月, 2011 1 次提交
  4. 21 7月, 2011 1 次提交
  5. 12 7月, 2011 1 次提交
  6. 07 7月, 2011 1 次提交
  7. 18 6月, 2011 1 次提交
  8. 12 5月, 2011 1 次提交
  9. 06 5月, 2011 1 次提交
  10. 29 4月, 2011 1 次提交
  11. 13 4月, 2011 1 次提交
    • V
      mac80211: Check for queued frames before entering power save. · e8306f98
      Vivek Natarajan 提交于
      In a highly noisy environment, the tx rate of the driver drops and
      the application slows down since it has not yet received ACKs for
      the frames already queued in the hardware. Since this ACK may take
      more than 100ms, stopping the dev queues for entering PS at this
      stage breaks applications, WMM test cases in my testing.
      If there are frames already pending in the tx queue, postponing the
      PS logic helps to avoid redundant queue stops. When power save is
      enabled by default and in a noisy environment, this API certainly
      helps in improving the average throughput.
      Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e8306f98
  12. 12 3月, 2011 1 次提交
  13. 26 2月, 2011 2 次提交
    • J
      mac80211: support direct offchannel TX offload · 5f16a436
      Johannes Berg 提交于
      For devices supported by iwlwifi sometimes
      off-channel transmissions need to be handled
      by the device completely. To support this
      mac80211 needs to pass the frame directly
      to the driver and not through the TX path
      as the driver needs the frame and channel
      information at the same time.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5f16a436
    • J
      mac80211: make tx() operation return void · 7bb45683
      Johannes Berg 提交于
      The return value of the tx operation is commonly
      misused by drivers, leading to errors. All drivers
      will drop frames if they fail to TX the frame, and
      they must also properly manage the queues (if they
      didn't, mac80211 would already warn).
      
      Removing the ability for drivers to return a BUSY
      value also allows significant cleanups of the TX
      TX handling code in mac80211.
      
      Note that this also fixes a bug in ath9k_htc, the
      old "return -1" there was wrong.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Tested-by: Sedat Dilek <sedat.dilek@googlemail.com> [ath5k]
      Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> [rt2x00]
      Acked-by: Larry Finger <Larry.Finger@lwfinger.net> [b43, rtl8187, rtlwifi]
      Acked-by: Luciano Coelho <coelho@ti.com> [wl12xx]
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7bb45683
  14. 20 1月, 2011 1 次提交
    • 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
  15. 06 1月, 2011 1 次提交
  16. 14 12月, 2010 1 次提交
    • T
      mac80211 default tx_last_beacon false (congestion) · 91f44b02
      Tim Harvey 提交于
      The 802.11 spec states that the STA that generated the last Beacon frame shall
      be the STA that response to a probe request.  This is important for congestion
      reduction when a probe request is received - only 1 node in an adhoc BSS
      will transmit a response.  While mac80211 drivers should provide the
      tx_last_beacon function to report if they transmitted the last beacon many
      do not.  As an attempt to reduce probe response congestion default this
      to 0 such that a node not implementing this capability does not contribute
      to unnecessary congestion.
      
      In a modern medium sized office environment I see upwards of 100 probe
      requests per second received at a given node from various hardware/OS/drivers
      doing zeroconf 'active probing' as opposed to passively listening for beacons.
      With a modest 10-node adhoc network consisting of drivers that do not implement
      this tx_last_beacon feature, I have seen this result in the simultaneous xmit
      of probe responses accumulating to 500 probe responses per second because of
      collisions which brings the adhoc network to its knees as well as causes
      needless congestion.
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      91f44b02
  17. 17 11月, 2010 2 次提交
  18. 17 9月, 2010 1 次提交
  19. 28 8月, 2010 1 次提交
  20. 30 6月, 2010 1 次提交
  21. 15 6月, 2010 5 次提交
    • J
      mac80211: Fix circular locking dependency in ARP filter handling · 68542962
      Juuso Oikarinen 提交于
      There is a circular locking dependency when configuring the
      hardware ARP filters on association, occurring when flushing the mac80211
      workqueue. This is what happens:
      
      [   92.026800] =======================================================
      [   92.030507] [ INFO: possible circular locking dependency detected ]
      [   92.030507] 2.6.34-04781-g2b2c009e #85
      [   92.030507] -------------------------------------------------------
      [   92.030507] modprobe/5225 is trying to acquire lock:
      [   92.030507]  ((wiphy_name(local->hw.wiphy))){+.+.+.}, at: [<ffffffff8105b5c0>] flush_workq
      ueue+0x0/0xb0
      [   92.030507]
      [   92.030507] but task is already holding lock:
      [   92.030507]  (rtnl_mutex){+.+.+.}, at: [<ffffffff812b9ce2>] rtnl_lock+0x12/0x20
      [   92.030507]
      [   92.030507] which lock already depends on the new lock.
      [   92.030507]
      [   92.030507]
      [   92.030507] the existing dependency chain (in reverse order) is:
      [   92.030507]
      [   92.030507] -> #2 (rtnl_mutex){+.+.+.}:
      [   92.030507]        [<ffffffff810761fb>] lock_acquire+0xdb/0x110
      [   92.030507]        [<ffffffff81341754>] mutex_lock_nested+0x44/0x300
      [   92.030507]        [<ffffffff812b9ce2>] rtnl_lock+0x12/0x20
      [   92.030507]        [<ffffffffa022d47c>] ieee80211_assoc_done+0x6c/0xe0 [mac80211]
      [   92.030507]        [<ffffffffa022f2ad>] ieee80211_work_work+0x31d/0x1280 [mac80211]
      
      [   92.030507] -> #1 ((&local->work_work)){+.+.+.}:
      [   92.030507]        [<ffffffff810761fb>] lock_acquire+0xdb/0x110
      [   92.030507]        [<ffffffff8105a51a>] worker_thread+0x22a/0x370
      [   92.030507]        [<ffffffff8105ecc6>] kthread+0x96/0xb0
      [   92.030507]        [<ffffffff81003a94>] kernel_thread_helper+0x4/0x10
      [   92.030507]
      [   92.030507] -> #0 ((wiphy_name(local->hw.wiphy))){+.+.+.}:
      [   92.030507]        [<ffffffff81075fdc>] __lock_acquire+0x1c0c/0x1d50
      [   92.030507]        [<ffffffff810761fb>] lock_acquire+0xdb/0x110
      [   92.030507]        [<ffffffff8105b60e>] flush_workqueue+0x4e/0xb0
      [   92.030507]        [<ffffffffa023ff7b>] ieee80211_stop_device+0x2b/0xb0 [mac80211]
      [   92.030507]        [<ffffffffa0231635>] ieee80211_stop+0x3e5/0x680 [mac80211]
      
      The locking in this case is quite complex. Fix the problem by rewriting the
      way the hardware ARP filter list is handled - i.e. make a copy of the address
      list to the bss_conf struct, and provide that list to the hardware driver
      when needed.
      
      The current patch will enable filtering also in promiscuous mode. This may need
      to be changed in the future.
      Reported-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      68542962
    • J
      mac80211: bracket driver tracing · 4efc76bd
      Johannes Berg 提交于
      Currently, driver tracing is sometimes invoked
      after and sometimes before the actual driver
      callback. This is fine as long as the driver
      has no tracing itself, but as soon as it does
      it gets confusing.
      
      To make traces containing such information
      easier to read, introduce a return tracer in
      mac80211 that essentially brackets any driver
      tracing, and invoke the real trace before the
      driver's callback, only showing the return
      value, if any, afterwards.
      
      Since tracing records the process, there's no
      problem with overlapping calls if that should
      happen.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4efc76bd
    • J
      mac80211: allow drivers to sleep in ampdu_action · 85ad181e
      Johannes Berg 提交于
      Allow drivers to sleep, and indicate this in
      the documentation. ath9k has some locking I
      don't understand, so keep it safe and disable
      BHs in it, all other drivers look fine with
      the context change.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      85ad181e
    • J
      mac80211: change TX aggregation locking · cfcdbde3
      Johannes Berg 提交于
      To prepare for allowing drivers to sleep in
      ampdu_action, change the locking in the TX
      aggregation code to use the mutex the RX part
      already uses. The spinlock is still necessary
      around some code to avoid races with TX, but
      now we can also synchronize_net() to avoid
      getting an inconsistent sequence number.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      cfcdbde3
    • J
      mac80211: change RX aggregation locking · a93e3644
      Johannes Berg 提交于
      To prepare for allowing drivers to sleep in
      ampdu_action, change the locking in the RX
      aggregation code to use a mutex, so that it
      would already allow drivers to sleep. But
      explicitly disable BHs around the callback
      for now since the TX part cannot yet sleep,
      and drivers' locking might require it.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a93e3644
  22. 08 6月, 2010 1 次提交
  23. 05 6月, 2010 1 次提交
  24. 04 6月, 2010 1 次提交
  25. 13 5月, 2010 1 次提交
  26. 28 4月, 2010 1 次提交
  27. 20 4月, 2010 1 次提交
  28. 04 4月, 2010 1 次提交
    • J
      net: convert multicast list to list_head · 22bedad3
      Jiri Pirko 提交于
      Converts the list and the core manipulating with it to be the same as uc_list.
      
      +uses two functions for adding/removing mc address (normal and "global"
       variant) instead of a function parameter.
      +removes dev_mcast.c completely.
      +exposes netdev_hw_addr_list_* macros along with __hw_addr_* functions for
       manipulation with lists on a sandbox (used in bonding and 80211 drivers)
      Signed-off-by: NJiri Pirko <jpirko@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22bedad3
  29. 09 2月, 2010 2 次提交
    • K
      mac80211: remove get_tx_stats() driver op · 349e6b72
      Kalle Valo 提交于
      get_tx_stats() driver operation is not currently used anywhere in mac80211
      and there are no plans to use it in the not-so-near future. So it can go
      without anyone missing it.
      Signed-off-by: NKalle Valo <kalle.valo@iki.fi>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      349e6b72
    • J
      mac80211: allow station add/remove to sleep · 34e89507
      Johannes Berg 提交于
      Many drivers would like to sleep during station
      addition and removal, and currently have a high
      complexity there from not being able to.
      
      This introduces two new callbacks sta_add() and
      sta_remove() that drivers can implement instead
      of using sta_notify() and that can sleep, and
      the new sta_add() callback is also allowed to
      fail.
      
      The reason we didn't do this previously is that
      the IBSS code wants to insert stations from the
      RX path, which is a tasklet, so cannot sleep.
      This patch will keep the station allocation in
      that path, but moves adding the station to the
      driver out of line. Since the addition can now
      fail, we can have IBSS peer structs the driver
      rejected -- in that case we still talk to the
      station but never tell the driver about it in
      the control.sta pointer. If there will ever be
      a driver that has a low limit on the number of
      stations and that cannot talk to any stations
      that are not known to it, we need to do come up
      with a new strategy of handling larger IBSSs,
      maybe quicker expiry or rejecting peers.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      34e89507
  30. 26 1月, 2010 1 次提交
  31. 23 1月, 2010 1 次提交
  32. 13 1月, 2010 1 次提交