1. 20 8月, 2012 1 次提交
  2. 12 7月, 2012 1 次提交
    • J
      mac80211: add time synchronisation with BSS for assoc · 8c358bcd
      Johannes Berg 提交于
      Some drivers (iwlegacy, iwlwifi and rt2x00) today use the
      bss_conf.last_tsf value. By itself though that value is
      completely worthless since it may be ancient. What really
      is needed is synchronisation between some device time and
      the TSF.
      
      To clarify this, rename bss_conf.last_tsf to sync_tsf and
      add sync_device_ts which is obtained from rx_status which
      gets a new field device_timestamp for this purpose. This
      is intentionally not using the mactime field since that
      is used for other things and in IBSS is expected to sync
      with the IBSS's TSF which isn't necessarily true for the
      device timestamp.
      
      Also, since we have the information and it's useful even
      before the connection has been established, give all the
      timing details to the driver before authenticating.
      Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8c358bcd
  3. 03 7月, 2012 1 次提交
  4. 24 6月, 2012 2 次提交
  5. 21 6月, 2012 1 次提交
  6. 09 5月, 2012 1 次提交
  7. 12 4月, 2012 1 次提交
  8. 11 4月, 2012 2 次提交
  9. 14 3月, 2012 1 次提交
  10. 13 3月, 2012 1 次提交
  11. 07 2月, 2012 1 次提交
    • J
      mac80211: add sta_state callback · f09603a2
      Johannes Berg 提交于
      (based on Eliad's patch)
      
      Add a callback to notify the low-level driver whenever
      the state of a station changes. The driver is only
      notified when the station is actually in the mac80211
      hash table, not for pre-insert state transitions.
      
      To allow the driver to replace sta_add/remove calls
      with this, call extra transitions with the NOTEXIST
      state.
      
      This callback can fail, so we need to be careful in
      handling it when a station is inserted, particularly
      in the IBSS case where we still keep the station entry
      around for mac80211 purposes.
      Signed-off-by: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f09603a2
  12. 29 11月, 2011 1 次提交
  13. 01 10月, 2011 3 次提交
    • J
      mac80211: allow out-of-band EOSP notification · 37fbd908
      Johannes Berg 提交于
      iwlwifi has a separate EOSP notification from
      the device, and to make use of that properly
      it needs to be passed to mac80211. To be able
      to mix with tx_status_irqsafe and rx_irqsafe
      it also needs to be an "_irqsafe" version in
      the sense that it goes through the tasklet,
      the actual flag clearing would be IRQ-safe
      but doing it directly would cause reordering
      issues.
      
      This is needed in the case of a P2P GO going
      into an absence period without transmitting
      any frames that should be driver-released as
      in this case there's no other way to inform
      mac80211 that the service period ended. Note
      that for drivers that don't use the _irqsafe
      functions another version of this function
      will be required.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      37fbd908
    • J
      mac80211: explicitly notify drivers of frame release · 40b96408
      Johannes Berg 提交于
      iwlwifi needs to know the number of frames that are
      going to be sent to a station while it is asleep so
      it can properly handle the uCode blocking of that
      station.
      
      Before uAPSD, we got by by telling the device that
      a single frame was going to be released whenever we
      encountered IEEE80211_TX_CTL_POLL_RESPONSE. With
      uAPSD, however, that is no longer possible since
      there could be more than a single frame.
      
      To support this model, add a new callback to notify
      drivers when frames are going to be released.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      40b96408
    • 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
  14. 28 9月, 2011 2 次提交
  15. 21 7月, 2011 1 次提交
  16. 12 7月, 2011 1 次提交
  17. 07 7月, 2011 1 次提交
  18. 18 6月, 2011 1 次提交
  19. 12 5月, 2011 2 次提交
  20. 06 5月, 2011 1 次提交
  21. 29 4月, 2011 1 次提交
  22. 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
  23. 12 3月, 2011 1 次提交
  24. 26 2月, 2011 1 次提交
  25. 27 1月, 2011 1 次提交
    • J
      mac80211: use DECLARE_EVENT_CLASS · ba99d93b
      Johannes Berg 提交于
      For events that include only the local struct as
      their parameter, we can use DECLARE_EVENT_CLASS
      and save quite some binary size across segments
      as well lines of code.
      
         text	   data	    bss	    dec	    hex	filename
       375745	  19296	    916	 395957	  60ab5	mac80211.ko.before
       367473	  17888	    916	 386277	  5e4e5	mac80211.ko.after
        -8272   -1408       0   -9680   -25d0 delta
      
      Some more tracepoints with identical arguments
      could be combined like this but for now this is
      the one that benefits most.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ba99d93b
  26. 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
  27. 06 1月, 2011 1 次提交
  28. 17 11月, 2010 2 次提交
  29. 17 9月, 2010 1 次提交
  30. 28 8月, 2010 1 次提交
  31. 17 8月, 2010 1 次提交
  32. 30 6月, 2010 1 次提交
  33. 15 6月, 2010 1 次提交
    • 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