1. 23 6月, 2014 7 次提交
  2. 19 5月, 2014 1 次提交
  3. 15 5月, 2014 3 次提交
  4. 14 5月, 2014 1 次提交
    • J
      mac80211: fix on-channel remain-on-channel · b4b177a5
      Johannes Berg 提交于
      Jouni reported that if a remain-on-channel was active on the
      same channel as the current operating channel, then the ROC
      would start, but any frames transmitted using mgmt-tx on the
      same channel would get delayed until after the ROC.
      
      The reason for this is that the ROC starts, but doesn't have
      any handling for "remain on the same channel", so it stops
      the interface queues. The later mgmt-tx then puts the frame
      on the interface queues (since it's on the current operating
      channel) and thus they get delayed until after the ROC.
      
      To fix this, add some logic to handle remaining on the same
      channel specially and not stop the queues etc. in this case.
      This not only fixes the bug but also improves behaviour in
      this case as data frames etc. can continue to flow.
      
      Cc: stable@vger.kernel.org
      Reported-by: NJouni Malinen <j@w1.fi>
      Tested-by: NJouni Malinen <j@w1.fi>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      b4b177a5
  5. 09 5月, 2014 1 次提交
  6. 06 5月, 2014 1 次提交
    • M
      mac80211: fix CSA tx queue stopping · 59af6928
      Michal Kazior 提交于
      It was possible for tx queues to be stuck stopped
      if AP CSA finalization failed. In that case
      neither stop_ap nor do_stop woke the queues up.
      This means it was impossible to perform tx at all
      until driver was reloaded or a successful CSA was
      performed later.
      
      It was possible to solve this in a simpler manner
      however this is more robust and future proof
      (having multi-vif CSA in mind).
      
      New sdata->csa_block_tx is introduced to keep
      track of which interfaces requested tx to be
      blocked for CSA. This is required because mac80211
      stops all tx queues for that purpose. This means
      queues must be awoken only when last tx-blocking
      CSA interface is finished.
      
      It is still possible to have tx queues stopped
      after CSA failure but as soon as offending
      interfaces are stopped from userspace (stop_ap or
      ifdown) tx queues are woken up properly.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      59af6928
  7. 05 5月, 2014 1 次提交
  8. 25 4月, 2014 5 次提交
  9. 09 4月, 2014 3 次提交
  10. 20 3月, 2014 1 次提交
    • J
      mac80211: fix suspend vs. authentication race · 1a1cb744
      Johannes Berg 提交于
      Since Stanislaw's patch removing the quiescing code, mac80211 had
      a race regarding suspend vs. authentication: as cfg80211 doesn't
      track authentication attempts, it can't abort them. Therefore the
      attempts may be kept running while suspending, which can lead to
      all kinds of issues, in at least some cases causing an error in
      iwlmvm firmware.
      
      Fix this by aborting the authentication attempt when suspending.
      
      Cc: stable@vger.kernel.org
      Fixes: 12e7f517 ("mac80211: cleanup generic suspend/resume procedures")
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      1a1cb744
  11. 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
  12. 13 2月, 2014 1 次提交
    • J
      mac80211: add NAPI support back · 06d181a8
      Johannes Berg 提交于
      NAPI was originally added to mac80211 a long time ago (by John in
      commit 4e6cbfd0 in July 2010), but then removed years later
      (by Stanislaw in commit 30c97120 in February 2013). No driver
      ever used it, so that was fine.
      
      Now I'm adding support for NAPI to our driver, so add some code
      to mac80211 again  to support NAPI. John was originally wrapping
      some (but not nearly all NAPI-related functions), but that doesn't
      scale very well with the number of functions that are there, some
      of which are even only inlines. Thus, instead of doing that, let
      the drivers manage the NAPI struct, except for napi_add() which is
      needed so mac80211 knows how to call napi_gro_receive().
      
      Also remove some no longer needed definitions that were left when
      NAPI support was removed.
      Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Reviewed-by: NEyal Shapira <eyal@wizery.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      06d181a8
  13. 05 2月, 2014 4 次提交
  14. 07 1月, 2014 1 次提交
  15. 19 12月, 2013 2 次提交
  16. 18 12月, 2013 1 次提交
  17. 16 12月, 2013 5 次提交
  18. 02 12月, 2013 1 次提交