1. 12 Apr, 2016 1 commit
  2. 05 Apr, 2016 1 commit
  3. 14 Jan, 2016 1 commit
  4. 04 Dec, 2015 1 commit
  5. 03 Nov, 2015 1 commit
  6. 14 Oct, 2015 1 commit
  7. 22 Sep, 2015 2 commits
  8. 06 May, 2015 1 commit
  9. 07 Apr, 2015 1 commit
  10. 01 Apr, 2015 1 commit
    • Felix Fietkau's avatar
      mac80211: add an intermediate software queue implementation · ba8c3d6f
      Felix Fietkau authored
      This allows drivers to request per-vif and per-sta-tid queues from which
      they can pull frames. This makes it easier to keep the hardware queues
      short, and to improve fairness between clients and vifs.
      The task of scheduling packet transmission is left up to the driver -
      queueing is controlled by mac80211. Drivers can only dequeue packets by
      calling ieee80211_tx_dequeue. This makes it possible to add active queue
      management later without changing drivers using this code.
      This can also be used as a starting point to implement A-MSDU
      aggregation in a way that does not add artificially induced latency.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      [resolved minor context conflict, minor changes, endian annotations]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  11. 30 Mar, 2015 1 commit
  12. 08 Jan, 2015 1 commit
    • Johannes Berg's avatar
      mac80211: allow drivers to provide most station statistics · 2b9a7e1b
      Johannes Berg authored
      In many cases, drivers can filter things like beacons that will
      skew statistics reported by mac80211. To get correct statistics
      in these cases, call drivers to obtain statistics and let them
      override all values, filling values from mac80211 if the driver
      didn't provide them. Not all of them make sense for the driver
      to fill, so some are still always done by mac80211.
      Note that this doesn't currently allow a driver to say "I know
      this value is wrong, don't report it at all", or to sum it up
      with a mac80211 value (as could be useful for "dropped misc"),
      that can be added if it turns out to be needed.
      This also gets rid of the get_rssi() method as is can now be
      implemented using sta_statistics().
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  13. 26 Nov, 2014 1 commit
  14. 19 Nov, 2014 4 commits
  15. 10 Nov, 2014 1 commit
  16. 04 Nov, 2014 2 commits
  17. 09 Oct, 2014 4 commits
  18. 05 Sep, 2014 1 commit
  19. 23 Jun, 2014 1 commit
  20. 26 May, 2014 1 commit
    • Luciano Coelho's avatar
      mac80211: add a single-transaction driver op to switch contexts · 1a5f0c13
      Luciano Coelho authored
      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: default avatarLuciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  21. 21 May, 2014 1 commit
    • Antonio Quartulli's avatar
      mac80211: export the expected throughput · cca674d4
      Antonio Quartulli authored
      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
      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: default avatarAntonio Quartulli <antonio@open-mesh.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  22. 09 May, 2014 1 commit
    • Eliad Peller's avatar
      mac80211: fix vif name tracing · f9ac71bf
      Eliad Peller authored
      If sdata doesn't have a valid dev (e.g. in case of monitor
      vif), the vif_name field was initialized with (a length of)
      some short string, but later was set to a different,
      potentially larger one.
      This resulted in out-of-bounds write, which usually
      appeared as garbage in the trace log.
      Simply trace sdata->name, as it should always have the
      correct name for both cases.
      Signed-off-by: default avatarEliad Peller <eliadx.peller@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  23. 06 Jan, 2014 1 commit
  24. 18 Dec, 2013 1 commit
  25. 16 Dec, 2013 1 commit
    • Johannes Berg's avatar
      mac80211: add pre-RCU-sync sta removal driver operation · 6a9d1b91
      Johannes Berg authored
      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: default avatarJohannes Berg <johannes.berg@intel.com>
  26. 03 Dec, 2013 1 commit
  27. 25 Nov, 2013 1 commit
    • Eliad Peller's avatar
      mac80211: add min required channel definition field · 21f659bf
      Eliad Peller authored
      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: default avatarEliad Peller <eliad@wizery.com>
      Reviewed-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  28. 02 Oct, 2013 1 commit
  29. 01 Oct, 2013 1 commit
  30. 01 Aug, 2013 1 commit
  31. 16 Apr, 2013 1 commit
    • Johannes Berg's avatar
      mac80211: support secondary channel offset in CSA · 85220d71
      Johannes Berg authored
      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
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  32. 25 Mar, 2013 1 commit