1. 13 1月, 2010 2 次提交
  2. 06 1月, 2010 1 次提交
  3. 29 12月, 2009 4 次提交
  4. 23 12月, 2009 2 次提交
  5. 22 12月, 2009 2 次提交
  6. 15 12月, 2009 1 次提交
  7. 30 11月, 2009 1 次提交
  8. 20 11月, 2009 2 次提交
  9. 19 11月, 2009 3 次提交
  10. 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
  11. 05 11月, 2009 1 次提交
  12. 31 10月, 2009 1 次提交
    • 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
  13. 29 8月, 2009 1 次提交
    • J
      mac80211: remove tasklet enable/disable · ea77f12f
      Johannes Berg 提交于
      Due to the way the tasklets work in mac80211 there's
      no need to ever disable them.
      
      However, we need to clear the pending packets when
      taking down the last interface because otherwise
      the tx_pending_tasklet might be queued if the
      driver mucks with the queues (which it shouldn't).
      
      I've had a situation occasionally with ar9170 in
      which ksoftirq was using 100% CPU time because
      a disabled tasklet was scheduled, and I think that
      was due to ar9170 receiving a packet while the
      tasklet was disabled. That's strange and it really
      should not do that for other reasons, but there's
      no need to waste that much CPU time over it, it
      should just warn instead.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ea77f12f
  14. 20 8月, 2009 4 次提交
  15. 14 8月, 2009 1 次提交
  16. 05 8月, 2009 4 次提交
    • I
      mac80211: FIF_PSPOLL filter flag · e3b90ca2
      Igor Perminov 提交于
      When an interface is configured in the AP mode, the mac80211
      implementation doesn't inform the driver to receive PS Poll frames.
      It leads to inability to communicate with power-saving stations
      reliably.
      The FIF_CONTROL flag isn't passed by mac80211 to
      ieee80211_ops.configure_filter when an interface is in the AP mode.
      And it's ok, because we don't want to receive ACK frames and other
      control ones, but only PS Poll ones.
      
      This patch introduces the FIF_PSPOLL filter flag in addition to
      FIF_CONTROL, which means for the driver "pass PS Poll frames".
      
      This flag is passed to the driver:
      A) When an interface is configured in the AP mode.
      B) In all cases, when the FIF_CONTROL flag was passed earlier (in
      addition to it).
      Signed-off-by: NIgor Perminov <igor.perminov@inbox.ru>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e3b90ca2
    • L
      mac80211: redefine usage of the mac80211 workqueue · 42935eca
      Luis R. Rodriguez 提交于
      The mac80211 workqueue exists to enable mac80211 and drivers
      to queue their own work on a single threaded workqueue. mac80211
      takes care to flush the workqueue during suspend but we never
      really had requirements on drivers for how they should use
      the workqueue in consideration for suspend.
      
      We extend mac80211 to document how the mac80211 workqueue should
      be used, how it should not be used and finally move raw access to
      the workqueue to mac80211 only. Drivers and mac80211 use helpers
      to queue work onto the mac80211 workqueue:
      
        * ieee80211_queue_work()
        * ieee80211_queue_delayed_work()
      
      These helpers will now warn if mac80211 already completed its
      suspend cycle and someone is trying to queue work. mac80211
      flushes the mac80211 workqueue prior to suspend a few times,
      but we haven't taken the care to ensure drivers won't add more
      work after suspend. To help with this we add a warning when
      someone tries to add work and mac80211 already completed the
      suspend cycle.
      
      Drivers should ensure they cancel any work or delayed work
      in the mac80211 stop() callback.
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      42935eca
    • B
      mac80211: disable beacons before removing the associated interface · 97af7432
      Bob Copeland 提交于
      When downing interfaces, it's a good idea to tell the driver to
      stop sending beacons; that way the driver doesn't need special
      code in ops->remove_interface() when it should already handle the
      case in bss_info_changed().
      
      This fixes a potential crash with at least ath5k since the vif
      pointer will be nullified while beacon interrupts are still active.
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      97af7432
    • J
      mac80211: disable software retry for now · 4da163ab
      Johannes Berg 提交于
      Pavel Roskin reported a problem that seems to be due to
      software retry of already transmitted frames. It turns
      out that we've never done that correctly, but due to
      some recent changes it now crashes in the TX code. I've
      added a comment in the patch that explains the problem
      better and also points to possible solutions -- which
      I can't implement right now.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4da163ab
  17. 28 7月, 2009 2 次提交
  18. 25 7月, 2009 1 次提交
  19. 11 7月, 2009 1 次提交
    • J
      mac80211: push rx status into skb->cb · f1d58c25
      Johannes Berg 提交于
      Within mac80211, we often need to copy the rx status into
      skb->cb. This is wasteful, as drivers could be building it
      in there to start with. This patch changes the API so that
      drivers are expected to pass the RX status in skb->cb, now
      accessible as IEEE80211_SKB_RXCB(skb). It also updates all
      drivers to pass the rx status in there, but only by making
      them memcpy() it into place before the call to the receive
      function (ieee80211_rx(_irqsafe)). Each driver can now be
      optimised on its own schedule.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f1d58c25
  20. 11 6月, 2009 1 次提交
    • J
      mac80211: do not pass PS frames out of mac80211 again · 8f77f384
      Johannes Berg 提交于
      In order to handle powersave frames properly we had needed
      to pass these out to the device queues again, and introduce
      the skb->requeue bit. This, however, also has unnecessary
      overhead by needing to 'clean up' already tried frames, and
      this clean-up code is also buggy when software encryption
      is used.
      
      Instead of sending the frames via the master netdev queue
      again, simply put them into the pending queue. This also
      fixes a problem where frames for that particular station
      could be reordered when some were still on the software
      queues and older ones are re-injected into the software
      queue after them.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8f77f384
  21. 04 6月, 2009 1 次提交
  22. 28 5月, 2009 1 次提交
  23. 21 5月, 2009 1 次提交
  24. 12 5月, 2009 1 次提交
    • J
      mac80211: fix scan channel race · 58905ca5
      Johannes Berg 提交于
      When a software scan starts, it first sets sw_scanning, but
      leaves the scan_channel "unset" (it currently actually gets
      initialised to a default). Now, when something else tries
      to (re)configure the hardware in the window between these two
      events (after sw_scanning = true, but before scan_channel is
      set), the current code switches to the (unset!) scan_channel.
      This causes trouble, especially when switching bands and
      sending frames on the wrong channel.
      
      To work around this, leave scan_channel initialised to NULL
      and use it to determine whether or not a switch to a different
      channel should occur (and also use the same condition to check
      whether to adjust power for scan or not).
      
      Additionally, avoid reconfiguring the hardware completely when
      recalculating idle resulted in no changes, this was the problem
      that originally led us to discover the race condition in the
      first place, which was helpfully bisected by Pavel. This part
      of the patch should not be necessary with the other fixes, but
      not calling the ieee80211_hw_config function when we know it to
      be unnecessary is certainly a correct thing to do.
      
      Unfortunately, this patch cannot and does not fix the race
      condition completely, but due to the way the scan code is
      structured it makes the particular problem Pavel discovered
      (race while changing channel at the same time as transmitting
      frames) go away. To fix it completely, more work especially
      with locking configuration is needed.
      Bisected-by: NPavel Roskin <proski@gnu.org>
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      58905ca5