1. 09 10月, 2014 1 次提交
  2. 05 9月, 2014 1 次提交
  3. 23 6月, 2014 1 次提交
  4. 26 5月, 2014 1 次提交
    • L
      mac80211: add a single-transaction driver op to switch contexts · 1a5f0c13
      Luciano Coelho 提交于
      In some cases, when the driver is already using all the channel
      contexts it can handle at once, we have to do an in-place switch
      (ie. we cannot afford using an extra context temporarily for the
      transaction).  But some drivers may not support switching the channel
      context assigned to a vif on the fly (ie. without unassigning and
      assigning it) while others may only work if the context is changed on
      the fly, without unassigning it first.
      
      To allow these different scenarios, add a new driver operation that
      let's the driver decide how to handle an in-place switch.
      Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      1a5f0c13
  5. 21 5月, 2014 1 次提交
    • A
      mac80211: export the expected throughput · cca674d4
      Antonio Quartulli 提交于
      Add get_expected_throughput() API to mac80211 so that each
      driver can implement its own version based on the RC
      algorithm they are using (might be using an HW RC algo).
      The API returns a value expressed in Kbps.
      
      Also, add the new get_expected_throughput() member
      to the rate_control_ops structure in order to be
      able to query the RC algorithm (this patch provides an
      implementation of this API for both minstrel and
      minstrel_ht).
      
      The related member in the station_info object is now
      filled accordingly when dumping a station.
      
      Cc: Felix Fietkau <nbd@openwrt.org>
      Signed-off-by: NAntonio Quartulli <antonio@open-mesh.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      cca674d4
  6. 09 5月, 2014 1 次提交
  7. 06 1月, 2014 1 次提交
  8. 18 12月, 2013 1 次提交
  9. 16 12月, 2013 1 次提交
    • J
      mac80211: add pre-RCU-sync sta removal driver operation · 6a9d1b91
      Johannes Berg 提交于
      Currently, mac80211 allows drivers to keep RCU-protected station
      references that are cleared when the station is removed from the
      driver and consequently needs to synchronize twice, once before
      removing the station from the driver (so it can guarantee that
      the station is no longer used in TX towards the driver) and once
      after the station is removed from the driver.
      
      Add a new pre-RCU-synchronisation station removal operation to
      the API to allow drivers to clear/invalidate their RCU-protected
      station pointers before the RCU synchronisation.
      
      This will allow removing the second synchronisation by changing
      the driver API so that the driver may no longer assume a valid
      RCU-protected pointer after sta_remove/sta_state returns.
      
      The alternative to this would be to synchronize_rcu() in all the
      drivers that currently rely on this behaviour (only iwlmvm) but
      that would defeat the purpose.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6a9d1b91
  10. 03 12月, 2013 1 次提交
  11. 26 11月, 2013 1 次提交
    • E
      mac80211: add min required channel definition field · 21f659bf
      Eliad Peller 提交于
      Add a new field to ieee80211_chanctx_conf to indicate
      the min required channel configuration.
      
      Tuning to a narrower channel might help reducing
      the noise level and saving some power.
      
      The min required channel definition is the max of
      all min required channel definitions of the interfaces
      bound to this channel context.
      
      In AP mode, use 20MHz when there are no connected station.
      When a new station is added/removed, calculate the new max
      bandwidth supported by any of the stations (e.g. 80MHz when
      80MHz and 40MHz stations are connected).
      
      In other cases, simply use bss_conf.chandef as the
      min required chandef.
      
      Notify drivers about changes to this field by calling
      drv_change_chanctx with a new CHANGE_MIN_WIDTH notification.
      Signed-off-by: NEliad Peller <eliad@wizery.com>
      Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      21f659bf
  12. 03 10月, 2013 1 次提交
  13. 01 10月, 2013 1 次提交
  14. 02 8月, 2013 1 次提交
  15. 16 4月, 2013 1 次提交
    • J
      mac80211: support secondary channel offset in CSA · 85220d71
      Johannes Berg 提交于
      Add support for the secondary channel offset IE in channel
      switch announcements. This is necessary for proper handling
      of CSA on HT access points.
      
      For this to work it is also necessary to convert everything
      here to use chandef structs instead of just channels. The
      driver updates aren't really correct though. In particular,
      the TI wl18xx driver update can't possibly be right since
      it just ignores the new channel width for lack of firmware
      API.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      85220d71
  16. 26 3月, 2013 1 次提交
  17. 22 3月, 2013 1 次提交
  18. 19 3月, 2013 1 次提交
  19. 11 3月, 2013 1 次提交
  20. 06 3月, 2013 1 次提交
  21. 16 2月, 2013 1 次提交
  22. 15 2月, 2013 1 次提交
  23. 12 2月, 2013 2 次提交
    • J
      mac80211: introduce beacon-only timing data · ef429dad
      Johannes Berg 提交于
      In order to be able to predict the next DTIM TBTT
      in the driver, add the ability to use timing data
      from beacons only with the new hardware flag
      IEEE80211_HW_TIMING_BEACON_ONLY and the BSS info
      value sync_dtim_count which is only valid if the
      timing data came from a beacon. The data can only
      come from a beacon, and if no beacon was received
      before association it is updated later together
      with the DTIM count notification.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      ef429dad
    • J
      mac80211: fix chandef tracing bug · 757af6fe
      Johannes Berg 提交于
      The chandef tracing writes center_freq1 twice, so
      that it is always 0 (no driver supports 80+80 yet)
      and leaves center_freq2 unset. Fix this mistake.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      757af6fe
  24. 24 1月, 2013 1 次提交
  25. 19 1月, 2013 2 次提交
  26. 18 1月, 2013 1 次提交
  27. 17 1月, 2013 1 次提交
  28. 26 11月, 2012 2 次提交
    • 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
      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
  29. 19 11月, 2012 1 次提交
  30. 10 11月, 2012 2 次提交
  31. 06 11月, 2012 1 次提交
  32. 30 10月, 2012 1 次提交
    • 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
  33. 26 10月, 2012 1 次提交
  34. 25 10月, 2012 1 次提交
  35. 17 10月, 2012 2 次提交