1. 05 4月, 2011 1 次提交
  2. 02 3月, 2011 1 次提交
  3. 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
  4. 16 12月, 2010 1 次提交
  5. 08 12月, 2010 1 次提交
  6. 30 11月, 2010 1 次提交
  7. 25 11月, 2010 2 次提交
  8. 19 11月, 2010 1 次提交
  9. 07 10月, 2010 2 次提交
  10. 17 8月, 2010 1 次提交
    • C
      mac80211: AMPDU rx reorder timeout timer · 2bff8ebf
      Christian Lamparter 提交于
      This patch introduces a new timer, which will release
      queued-up MPDUs from the reorder buffer, whenever
      they've waited for more than HT_RX_REORDER_BUF_TIMEOUT
      (which is at around 100 ms).
      
      The advantage of having a dedicated timer, instead of
      relying on a constant stream of freshly arriving aMPDUs
      to release the old ones, is particularly observable when
      even a small fraction of MPDUs are forever lost at
      low network speeds.
      
      Previously under these circumstances frames would become
      stuck in the reorder buffer and the network stack of both
      HT peers throttled back, instead of revving up and
      gunning the pipes.
      Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2bff8ebf
  11. 29 6月, 2010 1 次提交
  12. 15 6月, 2010 6 次提交
    • 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
    • J
      mac80211: defer RX agg session teardown to work · 7c3b1dd8
      Johannes Berg 提交于
      Since we want the code to be able to sleep
      in the future, it must not be called from
      the timer directly. To prepare, move it out
      into the aggregation work.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7c3b1dd8
    • J
      mac80211: make TX aggregation start/stop request async · 0ab33703
      Johannes Berg 提交于
      When the driver or rate control requests starting
      or stopping an aggregation session, that currently
      causes a direct callback into the driver, which
      could potentially cause locking problems. Also,
      the functions need to be callable from contexts
      that cannot sleep, and thus will interfere with
      making the ampdu_action callback sleeping.
      
      To address these issues, add a new work item for
      each station that will process any start or stop
      requests out of line.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0ab33703
    • J
      mac80211: use RCU for TX aggregation · a622ab72
      Johannes Berg 提交于
      Currently we allocate some memory for each TX
      aggregation session and additionally keep a
      state bitmap indicating the state it is in.
      By using RCU to protect the pointer, moving
      the state into the structure and some locking
      trickery we can avoid locking when the TX agg
      session is fully operational.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a622ab72
    • J
      mac80211: use RCU for RX aggregation · a87f736d
      Johannes Berg 提交于
      Currently we allocate some memory for each RX
      aggregation session and additionally keep a
      flag indicating whether or not it is valid.
      By using RCU to protect the pointer and making
      sure that the memory is fully set up before it
      becomes visible to the RX path, we can remove
      the need for the bool that indicates validity,
      as well as for locking on the RX path since it
      is always synchronised against itself, and we
      can guarantee that all other modifications are
      done when the structure is not visible to the
      RX path.
      
      The net result is that since we remove locking
      requirements from the RX path, we can in the
      future use any kind of lock for the setup and
      teardown code paths.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a87f736d
    • J
      mac80211: simplify station/aggregation code · 2a419056
      Johannes Berg 提交于
      A number of places use RCU locking for accessing
      the station list, even though they do not need
      to. Use mutex locking instead to prepare for the
      locking changes I want to make. The mlme code is
      also using a WLAN_STA_DISASSOC flag that has the
      same meaning as WLAN_STA_BLOCK_BA, so use that.
      
      While doing so, combine places where we loop
      over stations twice, and optimise away some of
      the loops by checking if the hardware supports
      aggregation at all first.
      
      Also fix a more theoretical race condition: right
      now we could resume, set up an aggregation session,
      and right after tear it down again due to the code
      that is needed for hardware reconfiguration here.
      Also mark add a comment to that code marking it as
      a workaround.
      
      Finally, remove a pointless aggregation disabling
      loop when an interface is stopped, directly after
      that we remove all stations from it which will also
      disable all aggregation sessions that may still be
      active, and does so in a race-free way unlike the
      current loop that doesn't block new sessions.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2a419056
  13. 04 6月, 2010 1 次提交
  14. 25 5月, 2010 1 次提交
  15. 08 4月, 2010 2 次提交
  16. 10 3月, 2010 1 次提交
  17. 11 2月, 2010 1 次提交
  18. 09 2月, 2010 1 次提交
    • 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
  19. 13 1月, 2010 1 次提交
  20. 22 12月, 2009 1 次提交
    • J
      mac80211: make station management completely depend on vif · abe60632
      Johannes Berg 提交于
      The station management currently uses the virtual
      interface, but you cannot add the same station to
      multiple virtual interfaces if you're communicating
      with it in multiple ways.
      
      This restriction should be lifted so that in the
      future we can, for instance, support bluetooth 3
      with an access point that mac80211 is already
      associated to.
      
      We can do that by requiring all sta_info_get users
      to provide the virtual interface and making the RX
      code aware that an address may match more than one
      station struct. Thanks to the previous patches this
      one isn't all that large and except for the RX and
      TX status paths changes has low complexity.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      abe60632
  21. 24 11月, 2009 1 次提交
  22. 19 11月, 2009 1 次提交
  23. 07 11月, 2009 1 次提交
    • J
      mac80211: async station powersave handling · af818581
      Johannes Berg 提交于
      Some devices require that all frames to a station
      are flushed when that station goes into powersave
      mode before being able to send frames to that
      station again when it wakes up or polls -- all in
      order to avoid reordering and too many or too few
      frames being sent to the station when it polls.
      
      Normally, this is the case unless the station
      goes to sleep and wakes up very quickly again.
      But in that case, frames for it may be pending
      on the hardware queues, and thus races could
      happen in the case of multiple hardware queues
      used for QoS/WMM. Normally this isn't a problem,
      but with the iwlwifi mechanism we need to make
      sure the race doesn't happen.
      
      This makes mac80211 able to cope with the race
      with driver help by a new WLAN_STA_PS_DRIVER
      per-station flag that can be controlled by the
      driver and tells mac80211 whether it can transmit
      frames or not. This flag must be set according to
      very specific rules outlined in the documentation
      for the function that controls it.
      
      When we buffer new frames for the station, we
      normally set the TIM bit right away, but while
      the driver has blocked transmission to that sta
      we need to avoid that as well since we cannot
      respond to the station if it wakes up due to the
      TIM bit. Once the driver unblocks, we can set
      the TIM bit.
      
      Similarly, when the station just wakes up, we
      need to wait until all other frames are flushed
      before we can transmit frames to that station,
      so the same applies here, we need to wait for
      the driver to give the OK.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      af818581
  24. 31 10月, 2009 2 次提交
    • J
      mac80211: deprecate qual value · c27f2fde
      Johannes Berg 提交于
      This value is unused by mac80211, because it was only
      be used by wireless extensions, and turned out to not
      be useful there because the quality value needs to be
      comparable between scan results and the current value
      which is impossible when the qual value is calculated
      taking into account noise, for example.
      
      Since it is unused anyway, this patch deprecates it
      in the hope that drivers will remove their sometimes
      quite expensive calculations of the value.
      
      I'm open to actual uses of the value, but the best
      way of using it seems to be what the Intel drivers do
      which should probably be generalised if we have noise
      values from the hardware.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c27f2fde
    • J
      cfg80211/mac80211: use debugfs_remove_recursive · 7bcfaf2f
      Johannes Berg 提交于
      We can save a lot of code and pointers in the structs
      by using debugfs_remove_recursive().
      
      First, change cfg80211 to use debugfs_remove_recursive()
      so that drivers do not need to clean up any files they
      added to the per-wiphy debugfs (if and only if they are
      ok to be accessed until after wiphy_unregister!).
      
      Then also make mac80211 use debugfs_remove_recursive()
      where necessary -- it need not remove per-wiphy files
      as cfg80211 now removes those, but netdev etc. files
      still need to be handled but can now be removed without
      needing struct dentry pointers to all of them.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7bcfaf2f
  25. 28 7月, 2009 1 次提交
  26. 11 7月, 2009 1 次提交
  27. 21 5月, 2009 2 次提交
  28. 07 5月, 2009 1 次提交
    • J
      mac80211: Add a timeout for frames in the RX reorder buffer · 4d050f1d
      Jouni Malinen 提交于
      This patch allows skbs to be released from the RX reorder buffer in
      case they have been there for an unexpectedly long time without us
      having received the missing frames before them. Previously, these
      frames were only released when the reorder window moved and that could
      take very long time unless new frames were received constantly (e.g.,
      TCP connections could be killed more or less indefinitely).
      
      This situation should not happen very frequently, but it looks like
      there are some scenarious that trigger it for some reason. As such,
      this should be considered mostly a workaround to speed up recovery
      from unexpected siutation that could result in connections hanging for
      long periods of time.
      
      The changes here will only check for timeout situation when adding new
      RX frames to the reorder buffer. It does not handle all possible
      cases, but seems to help for most cases that could result from common
      network usage (e.g., TCP retrying at least couple of times). For more
      completely coverage, a timer could be used to periodically check
      whether there are any frames remaining in the reorder buffer if no new
      frames are received.
      Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4d050f1d
  29. 23 4月, 2009 1 次提交
  30. 28 3月, 2009 1 次提交
    • J
      mac80211/iwlwifi: move virtual A-MDPU queue bookkeeping to iwlwifi · e4e72fb4
      Johannes Berg 提交于
      This patch removes all the virtual A-MPDU-queue bookkeeping from
      mac80211. Curiously, iwlwifi already does its own bookkeeping, so
      it doesn't require much changes except where it needs to handle
      starting and stopping the queues in mac80211.
      
      To handle the queue stop/wake properly, we rewrite the software
      queue number for aggregation frames and internally to iwlwifi keep
      track of the queues that map into the same AC queue, and only talk
      to mac80211 about the AC queue. The implementation requires calling
      two new functions, iwl_stop_queue and iwl_wake_queue instead of the
      mac80211 counterparts.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Cc: Reinette Chattre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e4e72fb4