1. 22 Jan, 2015 26 commits
  2. 20 Jan, 2015 1 commit
  3. 19 Jan, 2015 2 commits
    • Emmanuel Grumbach's avatar
      mac80211: delete the assoc/auth timer upon suspend · c1e140bf
      Emmanuel Grumbach authored
      While suspending, we destroy the authentication /
      association that might be taking place. While doing so, we
      forgot to delete the timer which can be firing after
      local->suspended is already set, producing the warning below.
      
      Fix that by deleting the timer.
      
      [66722.825487] WARNING: CPU: 2 PID: 5612 at net/mac80211/util.c:755 ieee80211_can_queue_work.isra.18+0x32/0x40 [mac80211]()
      [66722.825487] queueing ieee80211 work while going to suspend
      [66722.825529] CPU: 2 PID: 5612 Comm: kworker/u16:69 Tainted: G        W  O  3.16.1+ #24
      [66722.825537] Workqueue: events_unbound async_run_entry_fn
      [66722.825545] Call Trace:
      [66722.825552]  <IRQ>  [<ffffffff817edbb2>] dump_stack+0x4d/0x66
      [66722.825556]  [<ffffffff81075cad>] warn_slowpath_common+0x7d/0xa0
      [66722.825572]  [<ffffffffa06b5b90>] ? ieee80211_sta_bcn_mon_timer+0x50/0x50 [mac80211]
      [66722.825573]  [<ffffffff81075d1c>] warn_slowpath_fmt+0x4c/0x50
      [66722.825586]  [<ffffffffa06977a2>] ieee80211_can_queue_work.isra.18+0x32/0x40 [mac80211]
      [66722.825598]  [<ffffffffa06977d5>] ieee80211_queue_work+0x25/0x50 [mac80211]
      [66722.825611]  [<ffffffffa06b5bac>] ieee80211_sta_timer+0x1c/0x20 [mac80211]
      [66722.825614]  [<ffffffff8108655a>] call_timer_fn+0x8a/0x300
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      c1e140bf
    • Johannes Berg's avatar
      Revert "wireless: Support of IFLA_INFO_KIND rtnl attribute" · 6e9f3fa4
      Johannes Berg authored
      This reverts commit ba1debdf.
      
      Oliver reported that it breaks network-manager, for some reason with
      this patch NM decides that the device isn't wireless but "generic"
      (ethernet), sees no carrier (as expected with wifi) and fails to do
      anything else with it.
      
      Revert this to unbreak userspace.
      Reported-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Tested-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      6e9f3fa4
  4. 18 Jan, 2015 1 commit
    • Emmanuel Grumbach's avatar
      iwlwifi: mvm: abort scheduled scan upon RFKILL · 90ea15c1
      Emmanuel Grumbach authored
      When we have an active scheduled scan, and the RFKILL
      interrupt kicks in, the stack will cancel the scheduled
      scan as part of the down flow. But cancelling scheduled
      scan usually implies sending a command to the firwmare
      which has been killed as part of the RFKILL interrupt
      handling.
      Because of that, we returned an error to mac80211 when
      it asked to stop the scheduled scan and didn't notify the
      end of the scheduled scan. Besides a fat warning, this led
      to a situation in which cfg80211 would refuse any new scan
      request.
      
      To disentangle this, fake that the scheduled scan has been
      stopped without sending the command to the firwmare, return
      0 after having properly let cfg80211 know that the scan
      has been cancelled.
      
      This is basically the same as:
      commit 9b520d84
      Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
      Date:   Tue Nov 4 15:54:11 2014 +0200
      
          iwlwifi: mvm: abort scan upon RFKILL
      
          This code existed but not for all the different FW APIs
          we support.
          Fix this.
      
      but for the scheduled scan case.
      
      Link: http://permalink.gmane.org/gmane.linux.kernel.wireless.general/133232Reported-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      90ea15c1
  5. 16 Jan, 2015 2 commits
  6. 15 Jan, 2015 3 commits
    • Johannes Berg's avatar
      cfg80211: change bandwidth reporting to explicit field · b51f3bee
      Johannes Berg authored
      For some reason, we made the bandwidth separate flags, which
      is rather confusing - a single rate cannot have different
      bandwidths at the same time.
      
      Change this to no longer be flags but use a separate field
      for the bandwidth ('bw') instead.
      
      While at it, add support for 5 and 10 MHz rates - these are
      reported as regular legacy rates with their real bitrate,
      but tagged as 5/10 now to make it easier to distinguish them.
      
      In the nl80211 API, the flags are preserved, but the code
      now can also clearly only set a single one of the flags.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      b51f3bee
    • Johannes Berg's avatar
      cfg80211: remove 80+80 MHz rate reporting · 97d910d0
      Johannes Berg authored
      These rates are treated the same as 160 MHz in the spec, so
      it makes no sense to distinguish them. As no driver uses them
      yet, this is also not a problem, just remove them.
      
      In the userspace API the field remains reserved to preserve
      API and ABI.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      97d910d0
    • Johannes Berg's avatar
      mac80211: remove 80+80 MHz rate reporting · f89903d5
      Johannes Berg authored
      These rates are treated the same as 160 MHz in the spec,
      so it makes no sense to distinguish them. As no driver
      uses them yet, this is also not a problem, just remove
      them.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f89903d5
  7. 14 Jan, 2015 5 commits