1. 25 5月, 2013 1 次提交
    • J
      cfg80211/mac80211: use cfg80211 wdev mutex in mac80211 · 8d61ffa5
      Johannes Berg 提交于
      Using separate locks in cfg80211 and mac80211 has always
      caused issues, for example having to unlock in places in
      mac80211 to call cfg80211, which even needed a framework
      to make cfg80211 calls after some functions returned etc.
      
      Additionally, I suspect some issues people have reported
      with the cfg80211 state getting confused could be due to
      such issues, when cfg80211 is asking mac80211 to change
      state but mac80211 is in the process of telling cfg80211
      that the state changed (in another way.)
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8d61ffa5
  2. 16 4月, 2013 1 次提交
  3. 08 4月, 2013 1 次提交
  4. 26 3月, 2013 1 次提交
  5. 25 3月, 2013 1 次提交
  6. 19 3月, 2013 1 次提交
  7. 11 3月, 2013 1 次提交
  8. 07 3月, 2013 1 次提交
    • J
      mac80211: provide ieee80211_sta_eosp() · e943789e
      Johannes Berg 提交于
      The irqsafe version ieee80211_sta_eosp_irqsafe() exists, but
      drivers must not mix calls to any irqsafe/non-irqsafe function.
      Both ath9k and iwlwifi, the likely first users of this interface,
      use non-irqsafe RX/TX/TX status so must also use a non-irqsafe
      version of this function. Since no driver uses the _irqsafe()
      version, remove that.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      e943789e
  9. 06 3月, 2013 3 次提交
  10. 28 2月, 2013 1 次提交
  11. 15 2月, 2013 4 次提交
  12. 12 2月, 2013 2 次提交
  13. 19 1月, 2013 2 次提交
  14. 03 1月, 2013 5 次提交
  15. 30 11月, 2012 1 次提交
  16. 27 11月, 2012 1 次提交
  17. 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
  18. 09 11月, 2012 1 次提交
  19. 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
  20. 22 10月, 2012 1 次提交
  21. 18 10月, 2012 3 次提交
  22. 17 10月, 2012 5 次提交
    • M
      ieee80211: Rename VHT cap struct · d4950281
      Mahesh Palivela 提交于
      Rename struct ieee80211_vht_capabilities to ieee80211_vht_cap
      and renamed its member vht_capabilities_info to vht_cap_info.
      Signed-off-by: NMahesh Palivela <maheshp@posedge.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d4950281
    • J
      mac80211: Allow station mode SAE to be implemented in user space · 6b8ece3a
      Jouni Malinen 提交于
      SAE uses two rounds of Authentication frames and both rounds require
      considerable calculation to be done. This commit extends the existing
      station mode authentication request to allow more control for user
      space programs to build the SAE fields and to run the authentication
      step ones. Only the second round with authentication transaction
      sequence 2 will result in moving to authenticated state.
      Signed-off-by: NJouni Malinen <j@w1.fi>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6b8ece3a
    • J
      mac80211: track needed RX chains for channel contexts · 04ecd257
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      04ecd257
    • J
      mac80211: use channel contexts · 55de908a
      Johannes Berg 提交于
      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: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      55de908a
    • J
      mac80211: track whether to use channel contexts · fe57d9f5
      Johannes Berg 提交于
      Depending on the driver, channel contexts may be used or
      not. If they are used, the driver must have support for
      hardware scan and remain-on-channel; otherwise the driver
      must not advertise support for multiple channels.
      
      Also prohibit WDS type interfaces when channel contexts
      are to be used as there's no clear definition of which
      channel they use.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      fe57d9f5