1. 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
  2. 26 10月, 2012 1 次提交
  3. 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
  4. 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
  5. 16 10月, 2012 1 次提交
  6. 10 9月, 2012 1 次提交
  7. 04 9月, 2012 1 次提交
  8. 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
  9. 04 8月, 2012 2 次提交
  10. 31 7月, 2012 3 次提交
  11. 13 7月, 2012 1 次提交
  12. 12 7月, 2012 3 次提交
  13. 29 6月, 2012 1 次提交
  14. 26 6月, 2012 2 次提交
  15. 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
  16. 20 6月, 2012 1 次提交
  17. 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
  18. 06 6月, 2012 2 次提交
  19. 05 6月, 2012 1 次提交
  20. 17 5月, 2012 1 次提交
  21. 10 5月, 2012 1 次提交
    • J
      mac80211: Convert compare_ether_addr to ether_addr_equal · b203ca39
      Joe Perches 提交于
      Use the new bool function ether_addr_equal to add
      some clarity and reduce the likelihood for misuse
      of compare_ether_addr for sorting.
      
      Done via cocci script:
      
      $ cat compare_ether_addr.cocci
      @@
      expression a,b;
      @@
      -	!compare_ether_addr(a, b)
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	compare_ether_addr(a, b)
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!ether_addr_equal(a, b) == 0
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!ether_addr_equal(a, b) != 0
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	ether_addr_equal(a, b) == 0
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	ether_addr_equal(a, b) != 0
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!!ether_addr_equal(a, b)
      +	ether_addr_equal(a, b)
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b203ca39
  22. 25 4月, 2012 2 次提交
    • A
      mac80211: Adds clean sdata helper · 94c514fe
      Andrei Emeltchenko 提交于
      Adds hepler to clean sdata ieee80211_clean_sdata similar way as
      ieee80211_setup_sdata is implemented. The function will be used by other
      interfaces later.
      Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      94c514fe
    • E
      mac80211: call ieee80211_mgd_stop() on interface stop · afa762f6
      Eliad Peller 提交于
      ieee80211_mgd_teardown() is called on netdev removal, which
      occurs after the vif was already removed from the low-level
      driver, resulting in the following warning:
      
      [ 4809.014734] ------------[ cut here ]------------
      [ 4809.019861] WARNING: at net/mac80211/driver-ops.h:12 ieee80211_bss_info_change_notify+0x200/0x2c8 [mac80211]()
      [ 4809.030388] wlan0:  Failed check-sdata-in-driver check, flags: 0x4
      [ 4809.036862] Modules linked in: wlcore_sdio(-) wl12xx wlcore mac80211 cfg80211 [last unloaded: cfg80211]
      [ 4809.046849] [<c001bd4c>] (unwind_backtrace+0x0/0x12c)
      [ 4809.055937] [<c047cf1c>] (dump_stack+0x20/0x24)
      [ 4809.065385] [<c003e334>] (warn_slowpath_common+0x5c/0x74)
      [ 4809.075589] [<c003e408>] (warn_slowpath_fmt+0x40/0x48)
      [ 4809.088291] [<bf033630>] (ieee80211_bss_info_change_notify+0x200/0x2c8 [mac80211])
      [ 4809.102844] [<bf067f84>] (ieee80211_destroy_auth_data+0x80/0xa4 [mac80211])
      [ 4809.116276] [<bf068004>] (ieee80211_mgd_teardown+0x5c/0x74 [mac80211])
      [ 4809.129331] [<bf043f18>] (ieee80211_teardown_sdata+0xb0/0xd8 [mac80211])
      [ 4809.141595] [<c03b5e58>] (rollback_registered_many+0x228/0x2f0)
      [ 4809.153056] [<c03b5f48>] (unregister_netdevice_many+0x28/0x50)
      [ 4809.165696] [<bf041ea8>] (ieee80211_remove_interfaces+0xb4/0xdc [mac80211])
      [ 4809.179151] [<bf032174>] (ieee80211_unregister_hw+0x50/0xf0 [mac80211])
      [ 4809.191043] [<bf0bebb4>] (wlcore_remove+0x5c/0x7c [wlcore])
      [ 4809.201491] [<c02c6918>] (platform_drv_remove+0x24/0x28)
      [ 4809.212029] [<c02c4d50>] (__device_release_driver+0x8c/0xcc)
      [ 4809.222738] [<c02c4e84>] (device_release_driver+0x30/0x3c)
      [ 4809.233099] [<c02c4258>] (bus_remove_device+0x10c/0x128)
      [ 4809.242620] [<c02c26f8>] (device_del+0x11c/0x17c)
      [ 4809.252150] [<c02c6de0>] (platform_device_del+0x28/0x68)
      [ 4809.263051] [<bf0df49c>] (wl1271_remove+0x3c/0x50 [wlcore_sdio])
      [ 4809.273590] [<c03806b0>] (sdio_bus_remove+0x48/0xf8)
      [ 4809.283754] [<c02c4d50>] (__device_release_driver+0x8c/0xcc)
      [ 4809.293729] [<c02c4e2c>] (driver_detach+0x9c/0xc4)
      [ 4809.303163] [<c02c3d7c>] (bus_remove_driver+0xc4/0xf4)
      [ 4809.312973] [<c02c5a98>] (driver_unregister+0x70/0x7c)
      [ 4809.323220] [<c03809c4>] (sdio_unregister_driver+0x24/0x2c)
      [ 4809.334213] [<bf0df458>] (wl1271_exit+0x14/0x1c [wlcore_sdio])
      [ 4809.344930] [<c009b1a4>] (sys_delete_module+0x228/0x2a8)
      [ 4809.354734] ---[ end trace 515290ccf5feb522 ]---
      
      Rename ieee80211_mgd_teardown() to ieee80211_mgd_stop(),
      and call it on ieee80211_do_stop().
      Signed-off-by: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      afa762f6
  23. 17 4月, 2012 1 次提交
  24. 12 4月, 2012 4 次提交
    • J
      mac80211: clean up an ieee80211_do_open error path · 4d6c36fa
      Johannes Berg 提交于
      Eliad's comment prompted me to look closer at
      the error paths in ieee80211_do_open() and I
      found one that should use the error labels.
      
      Also add a comment about the clear_bit since
      in many error cases the bit hasn't been set.
      
      Cc: Eliad Peller <eliad@wizery.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4d6c36fa
    • J
      mac80211: add improved HW queue control · 3a25a8c8
      Johannes Berg 提交于
      mac80211 currently only supports one hardware queue
      per AC. This is already problematic for off-channel
      uses since if we go off channel while the BE queue
      is full and then try to send an off-channel frame
      the frame will never go out. This will become worse
      when we support multi-channel since then a queue on
      one channel might be full, but we have to stop the
      software queue for all channels. That is obviously
      not desirable.
      
      To address this problem allow drivers to register
      more hardware queues, and allow them to map them to
      virtual interfaces. When they stop a hardware queue
      the corresponding AC software queues on the correct
      interfaces will be stopped as well. Additionally,
      there's an off-channel queue to solve that problem
      and a per-interface after-DTIM beacon queue. This
      allows drivers to manage software queues closer to
      how the hardware works.
      
      Currently, there's a limit of 16 hardware queues.
      This may or may not be sufficient, we can adjust it
      as needed.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3a25a8c8
    • J
      mac80211: add explicit monitor interface if needed · 4b6f1dd6
      Johannes Berg 提交于
      The queue mapping redesign that I'm planning to do
      will break pure injection unless we handle monitor
      interfaces explicitly. One possible option would
      be to have the driver tell mac80211 about monitor
      mode queues etc., but that would duplicate the API
      since we already need to have queue assignments
      handled per virtual interface.
      
      So in order to solve this, have a virtual monitor
      interface that is added whenever all active vifs
      are monitors. We could also use the state of one
      of the monitor interfaces, but managing that would
      be complicated, so allocate separate state.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4b6f1dd6
    • J
      mac80211: manage AP netdev carrier state · 3edaf3e6
      Johannes Berg 提交于
      The AP netdev is really only active when beaconing, so
      manage the carrier state accordingly. Also do that for
      VLAN interfaces enslaved to a given AP interface.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3edaf3e6