All new accounts created on Gitlab now require administrator approval. If you invite any collaborators, please let Flux staff know so they can approve the accounts.

  1. 19 Dec, 2013 1 commit
    • Johannes Berg's avatar
      mac80211: fix iflist_mtx/mtx locking in radar detection · 34a3740d
      Johannes Berg authored
      The scan code creates an iflist_mtx -> mtx locking dependency,
      and a few other places, notably radar detection, were creating
      the opposite dependency, causing lockdep to complain. As scan
      and radar detection are mutually exclusive, the deadlock can't
      really happen in practice, but it's still bad form.
      
      A similar issue exists in the monitor mode code, but this is
      only used by channel-context drivers right now and those have
      to have hardware scan, so that also can't happen.
      
      Still, fix these issues by making some of the channel context
      code require the mtx to be held rather than acquiring it, thus
      allowing the monitor/radar callers to keep the iflist_mtx->mtx
      lock ordering.
      
      While at it, also fix access to the local->scanning variable
      in the radar code, and document that radar_detect_enabled is
      now properly protected by the mtx.
      
      All this would now introduce an ABBA deadlock between the DFS
      work cancelling and local->mtx, so change the locking there a
      bit to not need to use cancel_delayed_work_sync() but be able
      to just use cancel_delayed_work(). The work is also safely
      stopped/removed when the interface is stopped, so no extra
      changes are needed.
      Reported-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Tested-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      34a3740d
  2. 18 Dec, 2013 1 commit
  3. 25 Nov, 2013 2 commits
  4. 02 Oct, 2013 1 commit
  5. 01 Aug, 2013 1 commit
  6. 10 Apr, 2013 1 commit
  7. 25 Mar, 2013 2 commits
  8. 15 Feb, 2013 4 commits
  9. 11 Feb, 2013 2 commits
    • Johannes Berg's avatar
      mac80211: simplify idle handling · fd0f979a
      Johannes Berg authored
      Now that we have channel contexts, idle is (pretty
      much) equivalent to not having a channel context.
      Change the code to use this relation so that there
      no longer is a need for a lot of idle recalculate
      calls everywhere.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      fd0f979a
    • Johannes Berg's avatar
      mac80211: explicitly copy channels to VLANs where needed · 1f4ac5a6
      Johannes Berg authored
      Currently the code assigns channel contexts to VLANs
      (for use by the TX/RX code) when the AP master gets
      its channel context assigned. This works fine, but
      in the upcoming radar detection work the VLANs don't
      require a channel context (during radar detection)
      and assigning one to them anyway causes issues with
      locking and also inconsistencies -- a VLAN interface
      that is added before radar detection would get the
      channel context, while one added during it wouldn't.
      
      Fix these issues moving the channel context copying
      to a new explicit operation that will not be used
      in the radar detection code.
      Acked-by: default avatarSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      1f4ac5a6
  10. 03 Jan, 2013 2 commits
  11. 26 Nov, 2012 1 commit
    • 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
  12. 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
  13. 17 Oct, 2012 3 commits
    • Johannes Berg's avatar
      mac80211: add channel context iterator · 3448c005
      Johannes Berg authored
      Drivers may need to iterate the active channel
      contexts, export an iterator function to allow
      that. To make it possible, use RCU-safe list
      functions.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      3448c005
    • 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
    • Johannes Berg's avatar
      mac80211: use channel contexts · 55de908a
      Johannes Berg authored
      Instead of operating on a single channel only,
      use the new channel context infrastructure in
      all mac80211 code.
      
      This enables drivers that want to use the new
      channel context infrastructure to use multiple
      channels, while nothing should change for all
      the other drivers that don't support it.
      
      Right now this disables both TX power settings
      and spatial multiplexing powersave. Both need
      to be re-enabled on a channel context basis.
      
      Additionally, when channel contexts are used
      drop the connection when channel switch is
      received rather than trying to handle it. This
      will have to be improved later.
      
      [With fixes from Eliad and Emmanuel incorporated]
      Signed-off-by: default avatarEliad Peller <eliad@wizery.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      55de908a
  14. 16 Oct, 2012 3 commits
  15. 06 Sep, 2012 1 commit
  16. 05 Jun, 2012 1 commit
  17. 10 Apr, 2012 1 commit
  18. 13 Mar, 2012 1 commit
    • Paul Stewart's avatar
      mac80211: Don't let regulatory make us deaf · 3117bbdb
      Paul Stewart authored
      When regulatory information changes our HT behavior (e.g,
      when we get a country code from the AP we have just associated
      with), we should use this information to change the power with
      which we transmit, and what channels we transmit.  Sometimes
      the channel parameters we derive from regulatory information
      contradicts the parameters we used in association.  For example,
      we could have associated specifying HT40, but the regulatory
      rules we apply may forbid HT40 operation.
      
      In the situation above, we should reconfigure ourselves to
      transmit in HT20 only, however it makes no sense for us to
      disable receive in HT40, since if we associated with these
      parameters, the AP has every reason to expect we can and
      will receive packets this way.  The code in mac80211 does
      not have the capability of sending the appropriate action
      frames to signal a change in HT behaviour so the AP has
      no clue we can no longer receive frames encoded this way.
      In some broken AP implementations, this can leave us
      effectively deaf if the AP never retries in lower HT rates.
      
      This change breaks up the channel_type parameter in the
      ieee80211_enable_ht function into a separate receive and
      transmit part.  It honors the channel flags set by regulatory
      in order to configure the rate control algorithm, but uses
      the capability flags to configure the channel on the radio,
      since these were used in association to set the AP's transmit
      rate.
      Signed-off-by: default avatarPaul Stewart <pstew@chromium.org>
      Cc: Sam Leffler <sleffler@chromium.org>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Reviewed-by: default avatarLuis R Rodriguez <mcgrof@frijolero.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3117bbdb
  19. 24 Jan, 2012 1 commit
  20. 14 Mar, 2011 1 commit
  21. 16 Sep, 2010 1 commit
  22. 28 May, 2010 1 commit
  23. 07 May, 2010 2 commits
    • Johannes Berg's avatar
      mac80211: improve HT channel handling · 0aaffa9b
      Johannes Berg authored
      Currently, when one interface switches HT mode,
      all others will follow along. This is clearly
      undesirable, since the new one might switch to
      no-HT while another one is operating in HT.
      
      Address this issue by keeping track of the HT
      mode per interface, and allowing only changes
      that are compatible, i.e. switching into HT40+
      is not possible when another interface is in
      HT40-, in that case the second one needs to
      fall back to HT20.
      
      Also, to allow drivers to know what's going on,
      store the per-interface HT mode (channel type)
      in the virtual interface's bss_conf.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0aaffa9b
    • Johannes Berg's avatar
      cfg80211/mac80211: better channel handling · f444de05
      Johannes Berg authored
      Currently (all tested with hwsim) you can do stupid
      things like setting up an AP on a certain channel,
      then adding another virtual interface and making
      that associate on another channel -- this will make
      the beaconing to move channel but obviously without
      the necessary IEs data update.
      
      In order to improve this situation, first make the
      configuration APIs (cfg80211 and nl80211) aware of
      multi-channel operation -- we'll eventually need
      that in the future anyway. There's one userland API
      change and one API addition. The API change is that
      now SET_WIPHY must be called with virtual interface
      index rather than only wiphy index in order to take
      effect for that interface -- luckily all current
      users (hostapd) do that. For monitor interfaces, the
      old setting is preserved, but monitors are always
      slaved to other devices anyway so no guarantees.
      
      The second userland API change is the introduction
      of a per virtual interface SET_CHANNEL command, that
      hostapd should use going forward to make it easier
      to understand what's going on (it can automatically
      detect a kernel with this command).
      
      Other than mac80211, no existing cfg80211 drivers
      are affected by this change because they only allow
      a single virtual interface.
      
      mac80211, however, now needs to be aware that the
      channel settings are per interface now, and needs
      to disallow (for now) real multi-channel operation,
      which is another important part of this patch.
      
      One of the immediate benefits is that you can now
      start hostapd to operate on a hardware that already
      has a connection on another virtual interface, as
      long as you specify the same channel.
      
      Note that two things are left unhandled (this is an
      improvement -- not a complete fix):
      
       * different HT/no-HT modes
      
         currently you could start an HT AP and then
         connect to a non-HT network on the same channel
         which would configure the hardware for no HT;
         that can be fixed fairly easily
      
       * CSA
      
         An AP we're connected to on a virtual interface
         might indicate switching channels, and in that
         case we would follow it, regardless of how many
         other interfaces are operating; this requires
         more effort to fix but is pretty rare after all
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f444de05