1. 19 3月, 2013 2 次提交
  2. 11 3月, 2013 1 次提交
  3. 06 3月, 2013 4 次提交
    • J
      mac80211: simplify AP interface stop · 1861b845
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      1861b845
    • J
      mac80211: flush keys when stopping AP · 7b4396bd
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      7b4396bd
    • J
      mac80211: defer tailroom counter manipulation when roaming · 8d1f7ecd
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      8d1f7ecd
    • S
      mac80211: remove napi · 30c97120
      Stanislaw Gruszka 提交于
      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: NStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      30c97120
  4. 03 3月, 2013 1 次提交
  5. 27 2月, 2013 1 次提交
  6. 18 2月, 2013 1 次提交
  7. 15 2月, 2013 3 次提交
    • B
      mac80211: enable vif.cab_queue for mesh · 8ffb5c00
      Bob Copeland 提交于
      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: NBob Copeland <bob@cozybit.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8ffb5c00
    • M
      mac80211: free ps->bc_buf skbs on vlan device stop · 397a7a24
      Michael Braun 提交于
      When the vlan device is removed, ps->bc_buf processing can no longer
      send its frames.
      Signed-off-by: NMichael Braun <michael-dev@fami-braun.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      397a7a24
    • S
      mac80211: add radar detection command/event · 164eb02d
      Simon Wunderlich 提交于
      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: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      164eb02d
  8. 12 2月, 2013 3 次提交
  9. 19 1月, 2013 1 次提交
  10. 03 1月, 2013 8 次提交
  11. 06 12月, 2012 1 次提交
  12. 28 11月, 2012 1 次提交
  13. 26 11月, 2012 1 次提交
    • J
      mac80211: convert to channel definition struct · 4bf88530
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      4bf88530
  14. 30 10月, 2012 1 次提交
    • J
      mac80211: handle TX power per virtual interface · 1ea6f9c0
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      1ea6f9c0
  15. 26 10月, 2012 1 次提交
  16. 19 10月, 2012 1 次提交
    • M
      mac80211: make client powersave independent of interface type · d012a605
      Marco Porsch 提交于
      This patch prepares mac80211 for a later implementation of mesh or
      ad-hoc powersave clients.
      The structures related to powersave (buffer, TIM map, counters) are
      moved from the AP-specific interface structure to a generic structure
      that can be embedded into any interface type.
      The functions related to powersave are prepared to allow easy
      extension with different interface types. For example with:
      
      + } else if (sta->sdata->vif.type == NL80211_IFTYPE_MESH_POINT) {
      +         ps = &sdata->u.mesh.ps;
      
      Some references to the AP's beacon structure are removed where they
      were obviously not used.
      
      The patch compiles without warning and has been briefly tested as AP
      interface with one client in PS mode.
      Signed-off-by: NMarco Porsch <marco.porsch@etit.tu-chemnitz.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d012a605
  17. 17 10月, 2012 2 次提交
    • J
      mac80211: track needed RX chains for channel contexts · 04ecd257
      Johannes Berg 提交于
      On each channel that the device is operating on, it
      may need to listen using one or more chains depending
      on the SMPS settings of the interfaces using it. The
      previous channel context changes completely removed
      this ability (before, it was available as the SMPS
      mode).
      
      Add per-context tracking of the required static and
      dynamic RX chains and notify the driver on changes.
      To achieve this, track the chains and SMPS mode used
      on each virtual interface and update the channel
      context whenever this changes.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      04ecd257
    • J
      mac80211: use channel contexts · 55de908a
      Johannes Berg 提交于
      Instead of operating on a single channel only,
      use the new channel context infrastructure in
      all mac80211 code.
      
      This enables drivers that want to use the new
      channel context infrastructure to use multiple
      channels, while nothing should change for all
      the other drivers that don't support it.
      
      Right now this disables both TX power settings
      and spatial multiplexing powersave. Both need
      to be re-enabled on a channel context basis.
      
      Additionally, when channel contexts are used
      drop the connection when channel switch is
      received rather than trying to handle it. This
      will have to be improved later.
      
      [With fixes from Eliad and Emmanuel incorporated]
      Signed-off-by: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      55de908a
  18. 16 10月, 2012 1 次提交
  19. 10 9月, 2012 1 次提交
  20. 04 9月, 2012 1 次提交
  21. 20 8月, 2012 4 次提交
    • J
      mac80211: add IEEE80211_HW_P2P_DEV_ADDR_FOR_INTF · 6d71117a
      Johannes Berg 提交于
      Some devices like the current iwlwifi implementation
      require that the P2P interface address match the P2P
      Device address (only one P2P interface is supported.)
      Add the HW flag IEEE80211_HW_P2P_DEV_ADDR_FOR_INTF
      that allows drivers to request that P2P Interfaces
      added while a P2P Device is active get the same MAC
      address by default.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6d71117a
    • J
      mac80211: support P2P Device abstraction · f142c6b9
      Johannes Berg 提交于
      After cfg80211 got a P2P Device abstraction, add
      support to mac80211. Whether it really is supported
      or not will depend on whether or not the driver has
      support for it, but mac80211 needs to change to be
      able to support drivers that need a P2P Device.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f142c6b9
    • J
      cfg80211: add P2P Device abstraction · 98104fde
      Johannes Berg 提交于
      In order to support using a different MAC address
      for the P2P Device address we must first have a
      P2P Device abstraction that can be assigned a MAC
      address.
      
      This abstraction will also be useful to support
      offloading P2P operations to the device, e.g.
      periodic listen for discoverability.
      
      Currently, the driver is responsible for assigning
      a MAC address to the P2P Device, but this could be
      changed by allowing a MAC address to be given to
      the NEW_INTERFACE command.
      
      As it has no associated netdev, a P2P Device can
      only be identified by its wdev identifier but the
      previous patches allowed using the wdev identifier
      in various APIs, e.g. remain-on-channel.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      98104fde
    • E
      mac80211: avoid using synchronize_rcu in ieee80211_set_probe_resp · aa7a0080
      Eyal Shapira 提交于
      This could take a while (100ms+) and may delay sending assoc resp
      in AP mode with WPS or P2P GO (as setting the probe resp takes place
      there). We've encountered situations where the delay was big enough
      to cause connection problems with devices like Galaxy Nexus.
      Switch to using call_rcu with a free handler.
      
      [Arik - rework to use plain buffer and instead of skb]
      Signed-off-by: NEyal Shapira <eyal@wizery.com>
      Signed-off-by: NArik Nemtsov <arik@wizery.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      aa7a0080