1. 30 Jan, 2013 28 commits
  2. 29 Jan, 2013 1 commit
  3. 28 Jan, 2013 2 commits
  4. 25 Jan, 2013 3 commits
  5. 24 Jan, 2013 6 commits
    • Johannes Berg's avatar
      mac80211: remove redundant check · 782d2673
      Johannes Berg authored
      There's no need to have two checks for "associated"
      in ieee80211_sta_restart(), make the first one locked
      to not race (unlikely at this point during resume)
      and remove the second check.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      782d2673
    • Simon Wunderlich's avatar
      cfg80211: fix channel check in cfg80211_can_use_iftype_chan · 683d41ae
      Simon Wunderlich authored
      In commit "cfg80211: check radar interface combinations" a regression
      was introduced which might lead to NULL dereference if the argument
      chan = NULL, which might happen in IBSS/wext case (and probably
      others).
      Signed-off-by: default avatarSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      683d41ae
    • Thomas Pedersen's avatar
      mac80211: support mesh rate updates · f68d776a
      Thomas Pedersen authored
      An existing mesh station entry may change its rate
      capabilities, so call rate_control_rate_update() to notify
      the rate control.
      Signed-off-by: default avatarThomas Pedersen <thomas@cozybit.com>
      [fix compilation]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f68d776a
    • Thomas Pedersen's avatar
      mac80211: clean up mesh sta allocation warning · 296fcba3
      Thomas Pedersen authored
      This refactoring fixes a "scheduling while atomic" warning
      when allocating a mesh station entry while holding the RCU
      read lock. Fix this by creating a new function
      mesh_sta_info_get(), which correctly handles the locking
      and returns under RCU.
      
      Also move some unnecessarily #ifdefed mesh station init
      code from sta_info_alloc() to __mesh_sta_info_alloc().
      Signed-off-by: default avatarThomas Pedersen <thomas@cozybit.com>
      [change code flow to make sparse happy]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      296fcba3
    • Bing Zhao's avatar
      ieee80211: define AKM suite selectors type 5, 6 and 7 · d437c86b
      Bing Zhao authored
      Reference: IEEE 802.11-2012 8.4.2.27.3 "AKM suites"
      Signed-off-by: default avatarBing Zhao <bzhao@marvell.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      d437c86b
    • Johannes Berg's avatar
      mac80211: fix aggregation state with current drivers · 8147dc7f
      Johannes Berg authored
      For drivers that don't actually flush their queues when
      aggregation stop with the IEEE80211_AMPDU_TX_STOP_FLUSH
      or IEEE80211_AMPDU_TX_STOP_FLUSH_CONT reasons is done,
      like iwlwifi or iwlegacy, mac80211 can then transmit on
      a TID that the driver still considers busy. This happens
      in the following way:
      
       - IEEE80211_AMPDU_TX_STOP_FLUSH requested
       - driver marks TID as emptying
       - mac80211 removes tid_tx data, this can copy packets
         to the TX pending queues and also let new packets
         through to the driver
       - driver gets unexpected TX as it wasn't completely
         converted to the new API
      
      In iwlwifi, this lead to the following warning:
      
      WARNING: at drivers/net/wireless/iwlwifi/dvm/tx.c:442 iwlagn_tx_skb+0xc47/0xce0
      Tx while agg.state = 4
      Modules linked in: [...]
      Pid: 0, comm: kworker/0:0 Tainted: G        W   3.1.0 #1
      Call Trace:
       [<c1046e42>] warn_slowpath_common+0x72/0xa0
       [<c1046f13>] warn_slowpath_fmt+0x33/0x40
       [<fddffa17>] iwlagn_tx_skb+0xc47/0xce0 [iwldvm]
       [<fddfcaa3>] iwlagn_mac_tx+0x23/0x40 [iwldvm]
       [<fd8c98b6>] __ieee80211_tx+0xf6/0x3c0 [mac80211]
       [<fd8cbe00>] ieee80211_tx+0xd0/0x100 [mac80211]
       [<fd8cc176>] ieee80211_xmit+0x96/0xe0 [mac80211]
       [<fd8cc578>] ieee80211_subif_start_xmit+0x348/0xc80 [mac80211]
       [<c1445207>] dev_hard_start_xmit+0x337/0x6d0
       [<c145eee9>] sch_direct_xmit+0xa9/0x210
       [<c14462c0>] dev_queue_xmit+0x1b0/0x8e0
      
      Fortunately, solving this problem is easy as the station
      is being destroyed, so such transmit packets can only
      happen due to races. Instead of trying to close the race
      just let the race not reach the drivers by making two
      changes:
       1) remove the explicit aggregation session teardown in
          the managed mode code, the same thing will be done
          when the station is removed, in __sta_info_destroy.
       2) When aggregation stop with AGG_STOP_DESTROY_STA is
          requested, leave the tid_tx data around as stopped.
          It will be cleared and freed in cleanup_single_sta
          later, but until then any racy packets will be put
          onto the tid_tx pending queue instead of transmitted
          which is fine since the station is being removed.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      8147dc7f