1. 18 Dec, 2013 1 commit
  2. 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>
      6a9d1b91
  3. 03 Dec, 2013 1 commit
  4. 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>
      21f659bf
  5. 02 Oct, 2013 1 commit
  6. 01 Oct, 2013 1 commit
  7. 01 Aug, 2013 1 commit
  8. 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
      API.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      85220d71
  9. 25 Mar, 2013 1 commit
  10. 22 Mar, 2013 1 commit
  11. 18 Mar, 2013 1 commit
  12. 11 Mar, 2013 1 commit
  13. 06 Mar, 2013 1 commit
  14. 15 Feb, 2013 2 commits
  15. 11 Feb, 2013 2 commits
    • Johannes Berg's avatar
      mac80211: introduce beacon-only timing data · ef429dad
      Johannes Berg authored
      
      
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      ef429dad
    • Johannes Berg's avatar
      mac80211: fix chandef tracing bug · 757af6fe
      Johannes Berg authored
      
      
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      757af6fe
  16. 24 Jan, 2013 1 commit
  17. 18 Jan, 2013 3 commits
  18. 16 Jan, 2013 1 commit
  19. 26 Nov, 2012 2 commits
    • Johannes Berg's avatar
      mac80211: convert to channel definition struct · 4bf88530
      Johannes Berg authored
      
      
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      4bf88530
    • Johannes Berg's avatar
      cfg80211: remove remain-on-channel channel type · 42d97a59
      Johannes Berg authored
      
      
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      42d97a59
  20. 19 Nov, 2012 1 commit
  21. 09 Nov, 2012 2 commits
  22. 06 Nov, 2012 1 commit
  23. 30 Oct, 2012 1 commit
    • Johannes Berg's avatar
      mac80211: handle TX power per virtual interface · 1ea6f9c0
      Johannes Berg authored
      
      
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      1ea6f9c0
  24. 26 Oct, 2012 1 commit
  25. 25 Oct, 2012 1 commit
  26. 17 Oct, 2012 1 commit
    • Johannes Berg's avatar
      mac80211: track needed RX chains for channel contexts · 04ecd257
      Johannes Berg authored
      
      
      On each channel that the device is operating on, it
      may need to listen using one or more chains depending
      on the SMPS settings of the interfaces using it. The
      previous channel context changes completely removed
      this ability (before, it was available as the SMPS
      mode).
      
      Add per-context tracking of the required static and
      dynamic RX chains and notify the driver on changes.
      To achieve this, track the chains and SMPS mode used
      on each virtual interface and update the channel
      context whenever this changes.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      04ecd257
  27. 16 Oct, 2012 1 commit
  28. 20 Aug, 2012 2 commits
  29. 12 Jul, 2012 1 commit
    • Johannes Berg's avatar
      mac80211: add time synchronisation with BSS for assoc · 8c358bcd
      Johannes Berg authored
      
      
      Some drivers (iwlegacy, iwlwifi and rt2x00) today use the
      bss_conf.last_tsf value. By itself though that value is
      completely worthless since it may be ancient. What really
      is needed is synchronisation between some device time and
      the TSF.
      
      To clarify this, rename bss_conf.last_tsf to sync_tsf and
      add sync_device_ts which is obtained from rx_status which
      gets a new field device_timestamp for this purpose. This
      is intentionally not using the mactime field since that
      is used for other things and in IBSS is expected to sync
      with the IBSS's TSF which isn't necessarily true for the
      device timestamp.
      
      Also, since we have the information and it's useful even
      before the connection has been established, give all the
      timing details to the driver before authenticating.
      Reviewed-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      8c358bcd
  30. 03 Jul, 2012 1 commit
  31. 24 Jun, 2012 2 commits
  32. 21 Jun, 2012 1 commit