1. 12 8月, 2013 1 次提交
  2. 02 8月, 2013 1 次提交
  3. 16 7月, 2013 1 次提交
  4. 04 6月, 2013 1 次提交
    • J
      cfg80211/mac80211: clean up cfg80211 SME APIs · 6ff57cf8
      Johannes Berg 提交于
      Do some cleanups in the cfg80211 SME APIs, which are
      only used by mac80211.
      
      Most of these functions get a frame passed, and there
      isn't really any reason to export multiple functions
      as cfg80211 can check the frame type instead, do that.
      
      Additionally, the API functions have confusing names
      like cfg80211_send_...() which was meant to indicate
      that it sends an event to userspace, but gets a bit
      confusing when there's both TX and RX and they're not
      all clearly labeled.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6ff57cf8
  5. 25 5月, 2013 1 次提交
    • J
      cfg80211/mac80211: use cfg80211 wdev mutex in mac80211 · 8d61ffa5
      Johannes Berg 提交于
      Using separate locks in cfg80211 and mac80211 has always
      caused issues, for example having to unlock in places in
      mac80211 to call cfg80211, which even needed a framework
      to make cfg80211 calls after some functions returned etc.
      
      Additionally, I suspect some issues people have reported
      with the cfg80211 state getting confused could be due to
      such issues, when cfg80211 is asking mac80211 to change
      state but mac80211 is in the process of telling cfg80211
      that the state changed (in another way.)
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8d61ffa5
  6. 17 5月, 2013 1 次提交
  7. 22 4月, 2013 1 次提交
  8. 21 3月, 2013 1 次提交
  9. 07 3月, 2013 1 次提交
  10. 06 3月, 2013 1 次提交
  11. 15 2月, 2013 1 次提交
  12. 31 1月, 2013 1 次提交
  13. 26 1月, 2013 1 次提交
  14. 26 11月, 2012 4 次提交
    • J
      cfg80211: fix some tracing output issues · ec816087
      Johannes Berg 提交于
      In some cases, e.g. probe_status, there were spaces
      missing so the trace output was confusing. Also make
      it more like mac80211 when printing netdevs/wiphys
      to make reading a combined log easier.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      ec816087
    • J
      nl80211/cfg80211: support VHT channel configuration · 3d9d1d66
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      3d9d1d66
    • J
      cfg80211: pass a channel definition struct · 683b6d3b
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      683b6d3b
    • J
      cfg80211: remove remain-on-channel channel type · 42d97a59
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      42d97a59
  15. 19 11月, 2012 1 次提交
    • J
      cfg80211: Add TDLS event to allow drivers to request operations · 3475b094
      Jouni Malinen 提交于
      The NL80211_CMD_TDLS_OPER command was previously used only for userspace
      request for the kernel code to perform TDLS operations. However, there
      are also cases where the driver may need to request operations from
      userspace, e.g., when using security on the AP path. Add a new cfg80211
      function for generating a TDLS operation event for drivers to request a
      new link to be set up (NL80211_TDLS_SETUP) or an existing link to be
      torn down (NL80211_TDLS_TEARDOWN). Drivers can optionally use these
      events, e.g., based on noticing data traffic being sent to a peer
      station that is seen with good signal strength.
      Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      3475b094
  16. 30 10月, 2012 1 次提交
    • J
      cfg80211: allow per interface TX power setting · c8442118
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      c8442118
  17. 24 10月, 2012 1 次提交
  18. 18 10月, 2012 2 次提交