1. 27 11月, 2012 2 次提交
  2. 26 11月, 2012 8 次提交
    • J
      mac80211: support VHT rates in TX info · 8bc83c24
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      8bc83c24
    • J
      mac80211: support drivers reporting VHT RX · 5614618e
      Johannes Berg 提交于
      Add support to mac80211 for having drivers report
      received VHT MCS information.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      5614618e
    • 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
      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
    • 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
    • A
      cfg80211: change function signature of cfg80211_get_p2p_attr() · c216e641
      Arend van Spriel 提交于
      The function cfg80211_get_p2p_attr() can fail and returns
      a negative error code. However, the return type is unsigned
      int. The largest positive number is determined by desired_len
      variable in the function, which is u16. So changing the return
      type to int to allow easy error checking. Also change the type
      for the attribute to enum for improved type checking.
      Signed-off-by: NArend van Spriel <arend@broadcom.com>
      [fix indentation, don't use u8 attr variable]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      c216e641
  3. 21 11月, 2012 1 次提交
  4. 19 11月, 2012 3 次提交
  5. 14 11月, 2012 1 次提交
  6. 10 11月, 2012 2 次提交
    • J
      mac80211: clarify interface iteration and make it configurable · 8b2c9824
      Johannes Berg 提交于
      During hardware restart, all interfaces are iterated even
      though they haven't been re-added to the driver, document
      this behaviour. The same also happens during resume, which
      is even more confusing since all of the interfaces were
      previously removed from the driver. Make this optional so
      drivers relying on the current behaviour can still use it,
      but to let drivers that don't want this behaviour disable
      it.
      
      Also convert all API users, keeping the old semantics
      except in hwsim, where the new normal ones are desired.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8b2c9824
    • J
      mac80211: call driver method when restart completes · 9214ad7f
      Johannes Berg 提交于
      When the driver requests a restart (reconfiguration) it
      gets all the normal method calls, but can't really tell
      why they're happening. Call a new restart_complete op
      in the driver when the restart completes, so it could
      keep its own state about the restart and clear it there.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      9214ad7f
  7. 06 11月, 2012 2 次提交
  8. 05 11月, 2012 2 次提交
  9. 30 10月, 2012 2 次提交
    • 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
    • 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
  10. 27 10月, 2012 7 次提交
  11. 26 10月, 2012 1 次提交
  12. 24 10月, 2012 1 次提交
  13. 18 10月, 2012 4 次提交
  14. 17 10月, 2012 4 次提交