1. 11 Feb, 2013 1 commit
    • Johannes Berg's avatar
      mac80211: explicitly copy channels to VLANs where needed · 1f4ac5a6
      Johannes Berg authored
      
      
      Currently the code assigns channel contexts to VLANs
      (for use by the TX/RX code) when the AP master gets
      its channel context assigned. This works fine, but
      in the upcoming radar detection work the VLANs don't
      require a channel context (during radar detection)
      and assigning one to them anyway causes issues with
      locking and also inconsistencies -- a VLAN interface
      that is added before radar detection would get the
      channel context, while one added during it wouldn't.
      
      Fix these issues moving the channel context copying
      to a new explicit operation that will not be used
      in the radar detection code.
      Acked-by: default avatarSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      1f4ac5a6
  2. 04 Feb, 2013 1 commit
    • Marco Porsch's avatar
      mac80211: mesh power save basics · 3f52b7e3
      Marco Porsch authored
      
      
      Add routines to
      - maintain a PS mode for each peer and a non-peer PS mode
      - indicate own PS mode in transmitted frames
      - track neighbor STAs power modes
      - buffer frames when neighbors are in PS mode
      - add TIM and Awake Window IE to beacons
      - release frames in Mesh Peer Service Periods
      
      Add local_pm to sta_info to represent the link-specific power
      mode at this station towards the remote station. When a peer
      link is established, use the default power mode stored in mesh
      config. Update the PS status if the peering status of a neighbor
      changes.
      Maintain a mesh power mode for non-peer mesh STAs. Set the
      non-peer power mode to active mode during peering. Authenticated
      mesh peering is currently not working when either node is
      configured to be in power save mode.
      
      Indicate the current power mode in transmitted frames. Use QoS
      Nulls to indicate mesh power mode transitions.
      For performance reasons, calls to the function setting the frame
      flags are placed in HWMP routing routines, as there the STA
      pointer is already available.
      
      Add peer_pm to sta_info to represent the peer's link-specific
      power mode towards the local station. Add nonpeer_pm to
      represent the peer's power mode towards all non-peer stations.
      Track power modes based on received frames.
      
      Add the ps_data structure to ieee80211_if_mesh (for TIM map, PS
      neighbor counter and group-addressed frame buffer).
      
      Set WLAN_STA_PS flag for STA in PS mode to use the unicast frame
      buffering routines in the tx path. Update num_sta_ps to buffer
      and release group-addressed frames after DTIM beacons.
      
      Announce the awake window duration in beacons if in light or
      deep sleep mode towards any peer or non-peer. Create a TIM IE
      similarly to AP mode and add it to mesh beacons. Parse received
      Awake Window IEs and check TIM IEs for buffered frames.
      
      Release frames towards peers in mesh Peer Service Periods. Use
      the corresponding trigger frames and monitor the MPSP status.
      Append a QoS Null as trigger frame if neccessary to properly end
      the MPSP. Currently, in HT channels MPSPs behave imperfectly and
      show large delay spikes and frame losses.
      Signed-off-by: default avatarMarco Porsch <marco@cozybit.com>
      Signed-off-by: default avatarIvan Bezyazychnyy <ivan.bezyazychnyy@gmail.com>
      Signed-off-by: default avatarMike Krinkin <krinkin.m.u@gmail.com>
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      3f52b7e3
  3. 16 Jan, 2013 4 commits
  4. 03 Jan, 2013 6 commits
  5. 29 Nov, 2012 1 commit
  6. 27 Nov, 2012 1 commit
  7. 26 Nov, 2012 6 commits
    • Johannes Berg's avatar
      mac80211: support VHT rates in TX info · 8bc83c24
      Johannes Berg authored
      
      
      To achieve this, limit the number of retries to
      31 (instead of 255) and use the three bits that
      are then free for VHT flags.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      8bc83c24
    • Johannes Berg's avatar
      mac80211: support drivers reporting VHT RX · 5614618e
      Johannes Berg authored
      
      
      Add support to mac80211 for having drivers report
      received VHT MCS information.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      5614618e
    • 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
    • Johannes Berg's avatar
      nl80211/cfg80211: support VHT channel configuration · 3d9d1d66
      Johannes Berg authored
      
      
      Change nl80211 to support specifying a VHT (or HT)
      using the control channel frequency (as before) and
      new attributes for the channel width and first and
      second center frequency. The old channel type is of
      course still supported for HT.
      
      Also change the cfg80211 channel definition struct
      to support these by adding the relevant fields to
      it (and removing the _type field.)
      
      This also adds new helper functions:
       - cfg80211_chandef_create to create a channel def
         struct given the control channel and channel type,
       - cfg80211_chandef_identical to check if two channel
         definitions are identical
       - cfg80211_chandef_compatible to check if the given
         channel definitions are compatible, and return the
         wider of the two
      
      This isn't entirely complete, but that doesn't matter
      until we have a driver using it. In particular, it's
      missing
       - regulatory checks on the usable bandwidth (if that
         even makes sense)
       - regulatory TX power (database can't deal with it)
       - a proper channel compatibility calculation for the
         new channel types
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      3d9d1d66
    • Johannes Berg's avatar
      cfg80211: pass a channel definition struct · 683b6d3b
      Johannes Berg authored
      
      
      Instead of passing a channel pointer and channel type
      to all functions and driver methods, pass a new channel
      definition struct. Right now, this struct contains just
      the control channel and channel type, but for VHT this
      will change.
      
      Also, add a small inline cfg80211_get_chandef_type() so
      that drivers don't need to use the _type field of the
      new structure all the time, which will change.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      683b6d3b
    • Johannes Berg's avatar
      cfg80211: remove remain-on-channel channel type · 42d97a59
      Johannes Berg authored
      
      
      As mwifiex (and mac80211 in the software case) are the
      only drivers actually implementing remain-on-channel
      with channel type, userspace can't be relying on it.
      This is the case, as it's used only for P2P operations
      right now.
      
      Rather than adding a flag to tell userspace whether or
      not it can actually rely on it, simplify all the code
      by removing the ability to use different channel types.
      Leave only the validation of the attribute, so that if
      we extend it again later (with the needed capability
      flag), it can't break userspace sending invalid data.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      42d97a59
  8. 19 Nov, 2012 1 commit
  9. 05 Nov, 2012 1 commit
  10. 31 Oct, 2012 1 commit
  11. 30 Oct, 2012 3 commits
    • Johannes Berg's avatar
      mac80211: use a counter for remain-on-channel cookie · 50febf6a
      Johannes Berg authored
      
      
      Instead of using the pointer which can be re-used
      fairly quickly due to allocator patterns and then
      makes debugging difficult, maintain a counter and
      use its value. Since it's a 64-bit value it can't
      really wrap, but catch that case anyway since it
      most likely points to a bug somewhere.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      50febf6a
    • 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
    • Johannes Berg's avatar
      cfg80211: allow per interface TX power setting · c8442118
      Johannes Berg authored
      
      
      The TX power setting is currently per wiphy (hardware
      device) but with multi-channel capabilities that doesn't
      make much sense any more.
      
      Allow drivers (and mac80211) to advertise support for
      per-interface TX power configuration. When the TX power
      is configured for the wiphy, the wdev will be NULL and
      the driver can still handle that, but when a wdev is
      given the TX power can be set only for that wdev now.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      c8442118
  12. 26 Oct, 2012 2 commits
  13. 18 Oct, 2012 2 commits
  14. 17 Oct, 2012 3 commits
  15. 16 Oct, 2012 1 commit
    • Johannes Berg's avatar
      mac80211: track whether to use channel contexts · fe57d9f5
      Johannes Berg authored
      
      
      Depending on the driver, channel contexts may be used or
      not. If they are used, the driver must have support for
      hardware scan and remain-on-channel; otherwise the driver
      must not advertise support for multiple channels.
      
      Also prohibit WDS type interfaces when channel contexts
      are to be used as there's no clear definition of which
      channel they use.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      fe57d9f5
  16. 19 Sep, 2012 1 commit
  17. 14 Sep, 2012 1 commit
  18. 10 Sep, 2012 1 commit
    • Johannes Berg's avatar
      mac80211: add key flag for management keys · e548c49e
      Johannes Berg authored
      
      
      Mark keys that might be used to receive management
      frames so drivers can fall back on software crypto
      for them if they don't support hardware offload.
      As the new flag is only set correctly for RX keys
      and the existing IEEE80211_KEY_FLAG_SW_MGMT flag
      can only affect TX, also rename the latter to
      IEEE80211_KEY_FLAG_SW_MGMT_TX.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      e548c49e
  19. 05 Sep, 2012 1 commit
  20. 22 Aug, 2012 1 commit
  21. 20 Aug, 2012 1 commit