1. 26 2月, 2013 2 次提交
    • J
      nl80211: remove TCP WoWLAN information · 162589f7
      Johannes Berg 提交于
      Just like the radar information, the TCP WoWLAN capability
      data can increase the wiphy information and make it too
      big. Remove the TCP WoWLAN information; no driver supports
      it and new userspace tools will be required as well.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      162589f7
    • J
      nl80211: remove radar information · 1c33a059
      Johannes Berg 提交于
      The wiphy information is getting very close to being too
      much for a typical netlink dump message and adding the
      radar attributes to channels and interface combinations
      can push it over the limit, which means userspace gets no
      information whatsoever. Therefore, remove these again for
      now, no driver actually supports radar detection anyway
      and a modified userspace is required as well.
      
      We're working on a solution that will allow userspace to
      request splitting the information across multiple netlink
      messages, which will allow us to add this back.
      
      Cc: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      1c33a059
  2. 19 2月, 2013 1 次提交
  3. 15 2月, 2013 5 次提交
  4. 13 2月, 2013 2 次提交
  5. 12 2月, 2013 1 次提交
    • J
      cfg80211: move TSF into IEs · 8cef2c9d
      Johannes Berg 提交于
      While technically the TSF isn't an IE, it can be
      necessary to distinguish between the TSF from a
      beacon and a probe response, in particular in
      order to know the next DTIM TBTT, as not all APs
      are spec compliant wrt. TSF==0 being a DTIM TBTT
      and thus the DTIM count needs to be taken into
      account as well.
      
      To allow this, move the TSF into the IE struct
      so it can be known whence it came.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8cef2c9d
  6. 05 2月, 2013 1 次提交
    • V
      cfg80211: expand per-station byte counters to 64bit · 42745e03
      Vladimir Kondratiev 提交于
      In per-station statistics, present 32bit counters are too small
      for practical purposes - with gigabit speeds, it get overlapped
      every few seconds.
      
      Expand counters in the struct station_info to be 64-bit.
      Driver can still fill only 32-bit and indicate in @filled
      only bits like STATION_INFO_[TR]X_BYTES; in case driver provides
      full 64-bit counter, it should also set in @filled
      bit STATION_INFO_[TR]RX_BYTES64
      
      Netlink sends both 32-bit and 64-bit counters, if present, to not
      break userspace.
      Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
      [change to also have 32-bit counters if driver advertises 64-bit]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      42745e03
  7. 31 1月, 2013 1 次提交
  8. 26 1月, 2013 1 次提交
  9. 17 1月, 2013 6 次提交
  10. 03 1月, 2013 7 次提交
  11. 30 11月, 2012 2 次提交
  12. 29 11月, 2012 1 次提交
  13. 28 11月, 2012 1 次提交
  14. 27 11月, 2012 2 次提交
  15. 26 11月, 2012 4 次提交
    • J
      nl80211/cfg80211: add VHT MCS support · db9c64cf
      Johannes Berg 提交于
      Add support for reporting and calculating VHT MCSes.
      
      Note that I'm not completely sure that the bitrate
      calculations are correct, nor that they can't be
      simplified.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      db9c64cf
    • 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
  16. 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
  17. 08 11月, 2012 2 次提交