1. 19 1月, 2013 1 次提交
  2. 03 1月, 2013 8 次提交
  3. 06 12月, 2012 1 次提交
  4. 28 11月, 2012 1 次提交
  5. 26 11月, 2012 1 次提交
    • 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
  6. 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
  7. 26 10月, 2012 1 次提交
  8. 19 10月, 2012 1 次提交
    • M
      mac80211: make client powersave independent of interface type · d012a605
      Marco Porsch 提交于
      This patch prepares mac80211 for a later implementation of mesh or
      ad-hoc powersave clients.
      The structures related to powersave (buffer, TIM map, counters) are
      moved from the AP-specific interface structure to a generic structure
      that can be embedded into any interface type.
      The functions related to powersave are prepared to allow easy
      extension with different interface types. For example with:
      
      + } else if (sta->sdata->vif.type == NL80211_IFTYPE_MESH_POINT) {
      +         ps = &sdata->u.mesh.ps;
      
      Some references to the AP's beacon structure are removed where they
      were obviously not used.
      
      The patch compiles without warning and has been briefly tested as AP
      interface with one client in PS mode.
      Signed-off-by: NMarco Porsch <marco.porsch@etit.tu-chemnitz.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d012a605
  9. 17 10月, 2012 2 次提交
    • 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
  10. 16 10月, 2012 1 次提交
  11. 10 9月, 2012 1 次提交
  12. 04 9月, 2012 1 次提交
  13. 20 8月, 2012 4 次提交
    • J
      mac80211: add IEEE80211_HW_P2P_DEV_ADDR_FOR_INTF · 6d71117a
      Johannes Berg 提交于
      Some devices like the current iwlwifi implementation
      require that the P2P interface address match the P2P
      Device address (only one P2P interface is supported.)
      Add the HW flag IEEE80211_HW_P2P_DEV_ADDR_FOR_INTF
      that allows drivers to request that P2P Interfaces
      added while a P2P Device is active get the same MAC
      address by default.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6d71117a
    • J
      mac80211: support P2P Device abstraction · f142c6b9
      Johannes Berg 提交于
      After cfg80211 got a P2P Device abstraction, add
      support to mac80211. Whether it really is supported
      or not will depend on whether or not the driver has
      support for it, but mac80211 needs to change to be
      able to support drivers that need a P2P Device.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f142c6b9
    • J
      cfg80211: add P2P Device abstraction · 98104fde
      Johannes Berg 提交于
      In order to support using a different MAC address
      for the P2P Device address we must first have a
      P2P Device abstraction that can be assigned a MAC
      address.
      
      This abstraction will also be useful to support
      offloading P2P operations to the device, e.g.
      periodic listen for discoverability.
      
      Currently, the driver is responsible for assigning
      a MAC address to the P2P Device, but this could be
      changed by allowing a MAC address to be given to
      the NEW_INTERFACE command.
      
      As it has no associated netdev, a P2P Device can
      only be identified by its wdev identifier but the
      previous patches allowed using the wdev identifier
      in various APIs, e.g. remain-on-channel.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      98104fde
    • E
      mac80211: avoid using synchronize_rcu in ieee80211_set_probe_resp · aa7a0080
      Eyal Shapira 提交于
      This could take a while (100ms+) and may delay sending assoc resp
      in AP mode with WPS or P2P GO (as setting the probe resp takes place
      there). We've encountered situations where the delay was big enough
      to cause connection problems with devices like Galaxy Nexus.
      Switch to using call_rcu with a free handler.
      
      [Arik - rework to use plain buffer and instead of skb]
      Signed-off-by: NEyal Shapira <eyal@wizery.com>
      Signed-off-by: NArik Nemtsov <arik@wizery.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      aa7a0080
  14. 04 8月, 2012 2 次提交
  15. 31 7月, 2012 3 次提交
  16. 13 7月, 2012 1 次提交
  17. 12 7月, 2012 3 次提交
  18. 29 6月, 2012 1 次提交
  19. 26 6月, 2012 2 次提交
  20. 24 6月, 2012 1 次提交
    • J
      mac80211: clean up debugging · bdcbd8e0
      Johannes Berg 提交于
      There are a few things that make the logging and
      debugging in mac80211 less useful than it should
      be right now:
       * a lot of messages should be pr_info, not pr_debug
       * wholesale use of pr_debug makes it require *both*
         Kconfig and dynamic configuration
       * there are still a lot of ifdefs
       * the style is very inconsistent, sometimes the
         sdata->name is printed in front
      
      Clean up everything, introducing new macros and
      separating out the station MLME debugging into
      a new Kconfig symbol.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      bdcbd8e0
  21. 20 6月, 2012 1 次提交
  22. 07 6月, 2012 2 次提交
    • J
      mac80211: unify SW/offload remain-on-channel · 2eb278e0
      Johannes Berg 提交于
      Redesign all the off-channel code, getting rid of
      the generic off-channel work concept, replacing
      it with a simple remain-on-channel list.
      
      This fixes a number of small issues with the ROC
      implementation:
       * offloaded remain-on-channel couldn't be queued,
         now we can queue it as well, if needed
       * in iwlwifi (the only user) offloaded ROC is
         mutually exclusive with scanning, use the new
         queue to handle that case -- I expect that it
         will later depend on a HW flag
      
      The bigger issue though is that there's a bad bug
      in the current implementation: if we get a mgmt
      TX request while HW roc is active, and this new
      request has a wait time, we actually schedule a
      software ROC instead since we can't guarantee the
      existing offloaded ROC will still be that long.
      To fix this, the queuing mechanism was needed.
      
      The queuing mechanism for offloaded ROC isn't yet
      optimal, ideally we should add API to have the HW
      extend the ROC if needed. We could add that later
      but for now use a software implementation.
      
      Overall, this unifies the behaviour between the
      offloaded and software-implemented case as much
      as possible.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2eb278e0
    • J
      mac80211: do remain-on-channel while idle · 196ac1c1
      Johannes Berg 提交于
      The IDLE handling in HW off-channel is broken right
      now since we turn off IDLE only when the off-channel
      period already started. Therefore, all drivers that
      use it today (only iwlwifi!) must support off-channel
      while idle, so playing with idle isn't needed at all.
      
      Off-channel in general, since it's no longer used for
      authentication/association, shouldn't affect PS, so
      also remove that logic.
      
      Also document a small caveat for reporting TX status
      from off-channel frames in HW remain-on-channel.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      196ac1c1