1. 18 6月, 2011 1 次提交
  2. 12 5月, 2011 2 次提交
  3. 06 5月, 2011 1 次提交
  4. 29 4月, 2011 1 次提交
  5. 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
  6. 12 3月, 2011 1 次提交
  7. 26 2月, 2011 1 次提交
  8. 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
  9. 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
  10. 06 1月, 2011 1 次提交
  11. 17 11月, 2010 2 次提交
  12. 17 9月, 2010 1 次提交
  13. 28 8月, 2010 1 次提交
  14. 17 8月, 2010 1 次提交
  15. 30 6月, 2010 1 次提交
  16. 15 6月, 2010 2 次提交
    • 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
  17. 04 6月, 2010 2 次提交
  18. 13 5月, 2010 1 次提交
  19. 28 4月, 2010 1 次提交
  20. 09 4月, 2010 1 次提交
  21. 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
  22. 27 1月, 2010 1 次提交
    • Z
      mac80211: fix NULL pointer dereference when ftrace is enabled · 3092ad05
      Zhu Yi 提交于
      I got below kernel oops when I try to bring down the network interface if
      ftrace is enabled. The root cause is drv_ampdu_action() is passed with a
      NULL ssn pointer in the BA session tear down case. We need to check and
      avoid dereferencing it in trace entry assignment.
      
      BUG: unable to handle kernel NULL pointer dereference
      Modules linked in: at (null)
      IP: [<f98fe02a>] ftrace_raw_event_drv_ampdu_action+0x10a/0x160 [mac80211]
      *pde = 00000000
      Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
      [...]
      Call Trace:
       [<f98fdf20>] ? ftrace_raw_event_drv_ampdu_action+0x0/0x160 [mac80211]
       [<f98dac4c>] ? __ieee80211_stop_rx_ba_session+0xfc/0x220 [mac80211]
       [<f98d97fb>] ? ieee80211_sta_tear_down_BA_sessions+0x3b/0x50 [mac80211]
       [<f98dc6f6>] ? ieee80211_set_disassoc+0xe6/0x230 [mac80211]
       [<f98dc6ac>] ? ieee80211_set_disassoc+0x9c/0x230 [mac80211]
       [<f98dcbb8>] ? ieee80211_mgd_deauth+0x158/0x170 [mac80211]
       [<f98e4bdb>] ? ieee80211_deauth+0x1b/0x20 [mac80211]
       [<f8987f49>] ? __cfg80211_mlme_deauth+0xe9/0x120 [cfg80211]
       [<f898b870>] ? __cfg80211_disconnect+0x170/0x1d0 [cfg80211]
      
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: stable@kernel.org
      Signed-off-by: NZhu Yi <yi.zhu@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3092ad05
  23. 23 1月, 2010 1 次提交
  24. 13 1月, 2010 1 次提交
  25. 29 12月, 2009 1 次提交
  26. 23 12月, 2009 1 次提交
  27. 22 12月, 2009 2 次提交
  28. 29 11月, 2009 1 次提交
  29. 19 11月, 2009 1 次提交
  30. 20 8月, 2009 1 次提交
    • J
      mac80211: allow configure_filter callback to sleep · 3ac64bee
      Johannes Berg 提交于
      Over time, a whole bunch of drivers have come up
      with their own scheme to delay the configure_filter
      operation to a workqueue. To be able to simplify
      things, allow configure_filter to sleep, and add
      a new prepare_multicast callback that drivers that
      need the multicast address list implement. This new
      callback must be atomic, but most drivers either
      don't care or just calculate a hash which can be
      done atomically and then uploaded to the hardware
      non-atomically.
      
      A cursory look suggests that at76c50x-usb, ar9170,
      mwl8k (which is actually very broken now), rt2x00,
      wl1251, wl1271 and zd1211 should make use of this
      new capability.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3ac64bee
  31. 25 7月, 2009 2 次提交
    • C
      mac80211: fix spare warnings in driver-trace.h · f742880c
      Christian Lamparter 提交于
      This patch fixes the following errors:
      
      driver-trace.h:148:1: error: cannot size expression
      driver-trace.h:148:1: error: cannot size expression
      [...]
      driver-trace.h:222:1: error: cannot size expression
      driver-trace.h:71:1: error: incompatible types for operation (<)
      driver-trace.h:71:1:    left side has type void *<noident>
      driver-trace.h:71:1:    right side has type int
      driver-trace.h:99:1: error: incompatible types for operation (<)
      driver-trace.h:99:1:    left side has type void *<noident>
      driver-trace.h:99:1:    right side has type int
      driver-trace.h:148:1: error: incompatible types for operation (<)
      driver-trace.h:148:1:    left side has type void *<noident>
      driver-trace.h:148:1:    right side has type int
      driver-trace.h:222:1: error: cannot size expression
      driver-trace.h:248:1: error: incompatible types for operation (<)
      driver-trace.h:248:1:    left side has type void *<noident>
      driver-trace.h:248:1:    right side has type int
      driver-trace.h:446:1: error: incompatible types for operation (<)
      driver-trace.h:446:1:    left side has type void *<noident>
      driver-trace.h:446:1:    right side has type int
      Signed-off-by: NChristian Lamparter <chunkeey@web.de>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f742880c
    • J
      mac80211: driver operation debugging · 0a2b8bb2
      Johannes Berg 提交于
      This makes mac80211 use the event tracing framework
      to log all operations as given to the driver. This
      will need to be extended with more information, but
      as a start it should be good.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0a2b8bb2