1. 24 10月, 2014 2 次提交
  2. 10 10月, 2014 1 次提交
  3. 08 9月, 2014 1 次提交
    • S
      mac80211: support DTPC IE (from Cisco Client eXtensions) · c8d65917
      Steinar H. Gunderson 提交于
      Linux already supports 802.11h, where the access point can tell the
      client to reduce its transmission power. However, 802.11h is only
      defined for 5 GHz, where the need for this is much smaller than on
      2.4 GHz.
      
      Cisco has their own solution, called DTPC (Dynamic Transmit Power
      Control). Cisco APs on a controller sometimes but not always send
      802.11h; they always send DTPC, even on 2.4 GHz. This patch adds support
      for parsing and honoring the DTPC IE in addition to the 802.11h
      element (they do not always contain the same limits, so both must
      be honored); the format is not documented, but very simple.
      
      Tested (on top of wireless.git and on 3.16.1) against a Cisco Aironet
      1142 joined to a Cisco 2504 WLC, by setting various transmit power
      levels for the given access points and observing the results.
      The Wireshark 802.11 dissector agrees with the interpretation of the
      element, except for negative numbers, which seem to never happen
      anyway.
      Signed-off-by: NSteinar H. Gunderson <sgunderson@bigfoot.com>
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      c8d65917
  4. 05 9月, 2014 1 次提交
  5. 21 7月, 2014 1 次提交
  6. 26 6月, 2014 2 次提交
  7. 25 6月, 2014 1 次提交
  8. 23 6月, 2014 4 次提交
  9. 09 5月, 2014 1 次提交
  10. 05 5月, 2014 1 次提交
  11. 28 4月, 2014 2 次提交
  12. 25 4月, 2014 1 次提交
  13. 09 4月, 2014 4 次提交
  14. 20 2月, 2014 1 次提交
    • J
      mac80211: fix station wakeup powersave race · e3685e03
      Johannes Berg 提交于
      Consider the following (relatively unlikely) scenario:
       1) station goes to sleep while frames are buffered in driver
       2) driver blocks wakeup (until no more frames are buffered)
       3) station wakes up again
       4) driver unblocks wakeup
      
      In this case, the current mac80211 code will do the following:
       1) WLAN_STA_PS_STA set
       2) WLAN_STA_PS_DRIVER set
       3) - nothing -
       4) WLAN_STA_PS_DRIVER cleared
      
      As a result, no frames will be delivered to the client, even
      though it is awake, until it sends another frame to us that
      triggers ieee80211_sta_ps_deliver_wakeup() in sta_ps_end().
      
      Since we now take the PS spinlock, we can fix this while at
      the same time removing the complexity with the pending skb
      queue function. This was broken since my commit 50a9432d
      ("mac80211: fix powersaving clients races") due to removing
      the clearing of WLAN_STA_PS_STA in the RX path.
      
      While at it, fix a cleanup path issue when a station is
      removed while the driver is still blocking its wakeup.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      e3685e03
  15. 11 2月, 2014 1 次提交
  16. 06 2月, 2014 1 次提交
  17. 05 2月, 2014 3 次提交
  18. 07 1月, 2014 1 次提交
  19. 19 12月, 2013 2 次提交
    • F
      a7022e65
    • J
      mac80211: fix iflist_mtx/mtx locking in radar detection · 34a3740d
      Johannes Berg 提交于
      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: NKalle Valo <kvalo@qca.qualcomm.com>
      Tested-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      34a3740d
  20. 18 12月, 2013 1 次提交
  21. 16 12月, 2013 1 次提交
  22. 03 12月, 2013 1 次提交
    • J
      nl80211: vendor command support · ad7e718c
      Johannes Berg 提交于
      Add support for vendor-specific commands to nl80211. This is
      intended to be used for really vendor-specific functionality
      that can't be implemented in a generic fashion for any reason.
      It's *NOT* intended to be used for any normal/generic feature
      or any optimisations that could be implemented across drivers.
      
      Currently, only vendor commands (with replies) are supported,
      no dump operations or vendor-specific notifications.
      
      Also add a function wdev_to_ieee80211_vif() to mac80211 which
      is needed for mac80211-based drivers wanting to implement any
      vendor commands.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      ad7e718c
  23. 26 11月, 2013 4 次提交
  24. 25 11月, 2013 2 次提交