1. 06 Mar, 2013 1 commit
  2. 02 Mar, 2013 1 commit
  3. 26 Feb, 2013 1 commit
  4. 18 Feb, 2013 1 commit
  5. 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>
      8ffb5c00
    • 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>
      397a7a24
    • 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>
      164eb02d
  6. 11 Feb, 2013 3 commits
  7. 18 Jan, 2013 1 commit
  8. 03 Jan, 2013 8 commits
  9. 06 Dec, 2012 1 commit
  10. 28 Nov, 2012 1 commit
  11. 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>
      4bf88530
  12. 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>
      1ea6f9c0
  13. 26 Oct, 2012 1 commit
  14. 19 Oct, 2012 1 commit
    • Marco Porsch's avatar
      mac80211: make client powersave independent of interface type · d012a605
      Marco Porsch authored
      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: default avatarMarco Porsch <marco.porsch@etit.tu-chemnitz.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      d012a605
  15. 17 Oct, 2012 2 commits
    • Johannes Berg's avatar
      mac80211: track needed RX chains for channel contexts · 04ecd257
      Johannes Berg authored
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      04ecd257
    • Johannes Berg's avatar
      mac80211: use channel contexts · 55de908a
      Johannes Berg authored
      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: default avatarEliad Peller <eliad@wizery.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      55de908a
  16. 15 Oct, 2012 1 commit
  17. 10 Sep, 2012 1 commit
  18. 04 Sep, 2012 1 commit
  19. 20 Aug, 2012 4 commits
    • Johannes Berg's avatar
      mac80211: add IEEE80211_HW_P2P_DEV_ADDR_FOR_INTF · 6d71117a
      Johannes Berg authored
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      6d71117a
    • Johannes Berg's avatar
      mac80211: support P2P Device abstraction · f142c6b9
      Johannes Berg authored
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      f142c6b9
    • Johannes Berg's avatar
      cfg80211: add P2P Device abstraction · 98104fde
      Johannes Berg authored
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      98104fde
    • Eyal Shapira's avatar
      mac80211: avoid using synchronize_rcu in ieee80211_set_probe_resp · aa7a0080
      Eyal Shapira authored
      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: default avatarEyal Shapira <eyal@wizery.com>
      Signed-off-by: default avatarArik Nemtsov <arik@wizery.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      aa7a0080
  20. 03 Aug, 2012 2 commits
  21. 31 Jul, 2012 3 commits
  22. 13 Jul, 2012 1 commit