1. 04 11月, 2014 2 次提交
  2. 22 10月, 2014 1 次提交
  3. 09 10月, 2014 3 次提交
  4. 05 9月, 2014 1 次提交
  5. 25 6月, 2014 2 次提交
  6. 23 6月, 2014 1 次提交
  7. 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
  8. 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
  9. 09 5月, 2014 1 次提交
  10. 09 4月, 2014 1 次提交
  11. 20 2月, 2014 1 次提交
  12. 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
  13. 03 12月, 2013 1 次提交
  14. 01 10月, 2013 1 次提交
  15. 02 8月, 2013 1 次提交
  16. 29 5月, 2013 1 次提交
  17. 19 3月, 2013 3 次提交
  18. 11 3月, 2013 1 次提交
  19. 06 3月, 2013 1 次提交
  20. 15 2月, 2013 1 次提交
  21. 12 2月, 2013 1 次提交
  22. 24 1月, 2013 2 次提交
  23. 19 1月, 2013 1 次提交
    • J
      mac80211: allow drivers to access IPv6 information · a65240c1
      Johannes Berg 提交于
      To be able to implement NS response offloading (in
      regular operation or while in WoWLAN) drivers need
      to know the IPv6 addresses assigned to interfaces.
      Implement an IPv6 notifier in mac80211 to call the
      driver when addresses change.
      
      Unlike for IPv4, implement it as a callback rather
      than as a list in the BSS configuration, that is
      more flexible.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      a65240c1
  24. 18 1月, 2013 1 次提交
  25. 03 1月, 2013 3 次提交
  26. 26 11月, 2012 1 次提交
    • 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
  27. 21 11月, 2012 1 次提交
  28. 19 11月, 2012 2 次提交
  29. 10 11月, 2012 1 次提交
  30. 26 10月, 2012 1 次提交