1. 22 Apr, 2013 1 commit
  2. 08 Apr, 2013 7 commits
  3. 25 Mar, 2013 1 commit
  4. 20 Mar, 2013 1 commit
  5. 18 Mar, 2013 2 commits
  6. 11 Mar, 2013 1 commit
  7. 06 Mar, 2013 4 commits
    • Johannes Berg's avatar
      mac80211: simplify AP interface stop · 1861b845
      Johannes Berg authored
      For AP interfaces, there's no need to flush stations
      or keys again when the interface is stopped as already
      happened when the BSS was stopped on the interface.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: flush keys when stopping AP · 7b4396bd
      Johannes Berg authored
      Since hostapd will remove keys this isn't usually
      an issue, but we shouldn't leak keys to the next
      BSS started on the same interface. For VLANs this
      also fixes a bug, keys that aren't removed would
      otherwise be leaked.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: defer tailroom counter manipulation when roaming · 8d1f7ecd
      Johannes Berg authored
      During roaming, the crypto_tx_tailroom_needed_cnt counter
      will often take values 2,1,0,1,2 because first keys are
      removed and then new keys are added. This is inefficient
      because during the 0->1 transition, synchronize_net must
      be called to avoid packet races, although typically no
      packets would be flowing during that time.
      To avoid that, defer the decrement (2->1, 1->0) when keys
      are removed (by half a second). This means the counter
      will really have the values 2,2,2,3,4 ... 2, thus never
      reaching 0 and having to do the 0->1 transition.
      Note that this patch entirely disregards the drivers for
      which this optimisation was done to start with, for them
      the key removal itself will be expensive because it has
      to synchronize_net() after the counter is incremented to
      remove the key from HW crypto. For them the sequence will
      look like this: 0,1,0,1,0,1,0,1,0 (*) which is clearly a
      lot more inefficient. This could be addressed separately,
      during key removal the 0->1->0 sequence isn't necessary.
      (*) it starts at 0 because HW crypto is on, then goes to
          1 when HW crypto is disabled for a key, then back to
          0 because the key is deleted; this happens for both
          keys in the example. When new keys are added, it goes
          to 1 first because they're added in software; when a
          key is moved to hardware it goes back to 0
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Stanislaw Gruszka's avatar
      mac80211: remove napi · 30c97120
      Stanislaw Gruszka authored
      Since two years no mac80211 driver implement support for NAPI. Looks
      this feature is unneeded, so remove it from generic mac80211 code.
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  8. 02 Mar, 2013 1 commit
  9. 26 Feb, 2013 1 commit
  10. 18 Feb, 2013 1 commit
  11. 15 Feb, 2013 3 commits
    • Bob Copeland's avatar
      mac80211: enable vif.cab_queue for mesh · 8ffb5c00
      Bob Copeland authored
      Since mesh powersaving was added, pending bcast/mcast frames may go out the
      CAB queue now.  Unfortunately, the queue was only set up for AP mode, so we
      would try to tx on the IEEE80211_INVAL_HW_QUEUE.  Allow cab_queue for mesh
      interfaces as well.
      Fixes the following warning (or crash without MAC80211_VERBOSE_DEBUG):
      WARNING: at net/mac80211/tx.c:1223 __ieee80211_tx+0x162/0x35f [mac80211]()
      Modules linked in: mac80211_hwsim mac80211 cfg80211 [...]
      Pid: 3085, comm: avahi-daemon Tainted: G        W    3.8.0-rc1+ #377
      Call Trace:
       [<ffffffff81045c20>] warn_slowpath_common+0x83/0x9c
       [<ffffffff81045c53>] warn_slowpath_null+0x1a/0x1c
       [<ffffffffa083aef0>] __ieee80211_tx+0x162/0x35f [mac80211]
       [<ffffffffa083cb1d>] ieee80211_tx+0xd3/0xf9 [mac80211]
       [<ffffffffa083cc0f>] ieee80211_xmit+0xcc/0xd5 [mac80211]
       [<ffffffffa083db59>] ieee80211_subif_start_xmit+0xc53/0xcd8 [mac80211]
       [<ffffffff81319acd>] dev_hard_start_xmit+0x259/0x3ce
       [<ffffffff81333d6b>] sch_direct_xmit+0x74/0x17d
       [<ffffffff8131a0b1>] dev_queue_xmit+0x230/0x414
       [<ffffffff8134877a>] ip_finish_output2+0x348/0x3aa
       [<ffffffff81349029>] ip_finish_output+0x6c/0x71
       [<ffffffff81349046>] NF_HOOK_COND.constprop.44+0x18/0x58
       [<ffffffff8134a03a>] ip_mc_output+0x134/0x13c
       [<ffffffff8134835a>] dst_output+0x18/0x1c
       [<ffffffff81349a24>] ip_local_out+0x20/0x24
       [<ffffffff8134a8cf>] ip_send_skb+0x16/0x3c
       [<ffffffff8136bfba>] udp_send_skb+0x254/0x2b9
       [<ffffffff8136c85e>] udp_sendmsg+0x5a8/0x7d4
      Signed-off-by: default avatarBob Copeland <bob@cozybit.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Michael Braun's avatar
      mac80211: free ps->bc_buf skbs on vlan device stop · 397a7a24
      Michael Braun authored
      When the vlan device is removed, ps->bc_buf processing can no longer
      send its frames.
      Signed-off-by: default avatarMichael Braun <michael-dev@fami-braun.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Simon Wunderlich's avatar
      mac80211: add radar detection command/event · 164eb02d
      Simon Wunderlich authored
      Add command to trigger radar detection in the driver/FW.
      Once radar detection is started it should continuously
      monitor for radars as long as the channel active.
      If radar is detected usermode notified with 'radar
      detected' event.
      Scanning and remain on channel functionality must be disabled
      while doing radar detection/scanning, and vice versa.
      Based on original patch by Victor Goldenshtein <victorg@ti.com>
      Signed-off-by: default avatarSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  12. 11 Feb, 2013 3 commits
  13. 18 Jan, 2013 1 commit
  14. 03 Jan, 2013 8 commits
  15. 06 Dec, 2012 1 commit
  16. 28 Nov, 2012 1 commit
  17. 26 Nov, 2012 1 commit
    • Johannes Berg's avatar
      mac80211: convert to channel definition struct · 4bf88530
      Johannes Berg authored
      Convert mac80211 (and where necessary, some drivers a
      little bit) to the new channel definition struct.
      This will allow extending mac80211 for VHT, which is
      currently restricted to channel contexts since there
      are no drivers using that which makes it easier. As
      I also don't care about VHT for drivers not using the
      channel context API, I won't convert the previous API
      to VHT support.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  18. 30 Oct, 2012 1 commit
    • Johannes Berg's avatar
      mac80211: handle TX power per virtual interface · 1ea6f9c0
      Johannes Berg authored
      Even before channel contexts/multi-channel, having a
      single global TX power limit was already problematic,
      in particular if two managed interfaces connected to
      two APs with different power constraints. The channel
      context introduction completely broke this though and
      in fact I had disabled TX power configuration there
      for drivers using channel contexts.
      Change everything to track TX power per interface so
      that different user settings and different channel
      maxima are treated correctly. Also continue tracking
      the global TX power though for compatibility with
      applications that attempt to configure the wiphy's
      TX power globally.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  19. 26 Oct, 2012 1 commit