1. 18 Mar, 2013 3 commits
  2. 11 Mar, 2013 1 commit
  3. 07 Mar, 2013 1 commit
    • Johannes Berg's avatar
      mac80211: provide ieee80211_sta_eosp() · e943789e
      Johannes Berg authored
      The irqsafe version ieee80211_sta_eosp_irqsafe() exists, but
      drivers must not mix calls to any irqsafe/non-irqsafe function.
      Both ath9k and iwlwifi, the likely first users of this interface,
      use non-irqsafe RX/TX/TX status so must also use a non-irqsafe
      version of this function. Since no driver uses the _irqsafe()
      version, remove that.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  4. 06 Mar, 2013 3 commits
  5. 15 Feb, 2013 6 commits
    • Johannes Berg's avatar
      mac80211: stop modifying HT SMPS capability · af0ed69b
      Johannes Berg authored
      Instead of modifying the HT SMPS capability field
      for stations, track the SMPS mode explicitly in a
      new field in the station struct and use it in the
      drivers that care about it. This simplifies the
      code using it.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: add ieee80211_vif_change_bandwidth · 2c9b7359
      Johannes Berg authored
      For HT and VHT the current bandwidth can change,
      add the function ieee80211_vif_change_bandwidth()
      to take care of this. It returns a failure if the
      new bandwidth isn't compatible with the existing
      channel context, the caller has to handle that.
      When it happens, also inform the driver that the
      bandwidth changed for this virtual interface (no
      drivers would actually care today though.)
      Changing to/from HT/VHT isn't allowed though.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: handle VHT operating mode notification · 0af83d3d
      Johannes Berg authored
      Handle the operating mode notification action frame.
      When the supported streams or the bandwidth change
      let the driver and rate control algorithm know.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: track number of spatial streams · 8921d04e
      Johannes Berg authored
      With VHT, a station can change the number of spatial
      streams it can receive on the fly, not unlike spatial
      multiplexing in HT. Prepare for that by tracking the
      maximum number of spatial streams it can receive when
      the connection is established.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: stop toggling IEEE80211_HT_CAP_SUP_WIDTH_20_40 · e1a0c6b3
      Johannes Berg authored
      For VHT, many more bandwidth changes are possible. As a first
      step, stop toggling the IEEE80211_HT_CAP_SUP_WIDTH_20_40 flag
      in the HT capabilities and instead introduce a bandwidth field
      indicating the currently usable bandwidth to transmit to the
      station. Of course, make all drivers use it.
      To achieve this, make ieee80211_ht_cap_ie_to_sta_ht_cap() get
      the station as an argument, rather than the new capabilities,
      so it can set up the new bandwidth field.
      If the station is a VHT station and VHT bandwidth is in use,
      also set the bandwidth accordingly.
      Doing this allows us to get rid of the supports_40mhz flag as
      the HT capabilities now reflect the true capability instead of
      the current setting.
      While at it, also fix ieee80211_ht_cap_ie_to_sta_ht_cap() to not
      ignore HT cap overrides when MCS TX isn't supported (not that it
      really happens...)
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Simon Wunderlich's avatar
      mac80211: add radar detection command/event · 164eb02d
      Simon Wunderlich authored
      Add command to trigger radar detection in the driver/FW.
      Once radar detection is started it should continuously
      monitor for radars as long as the channel active.
      If radar is detected usermode notified with 'radar
      detected' event.
      Scanning and remain on channel functionality must be disabled
      while doing radar detection/scanning, and vice versa.
      Based on original patch by Victor Goldenshtein <victorg@ti.com>
      Signed-off-by: default avatarSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  6. 11 Feb, 2013 5 commits
  7. 04 Feb, 2013 1 commit
    • Johannes Berg's avatar
      mac80211: always allow calling ieee80211_connection_loss() · 682bd38b
      Johannes Berg authored
      With multi-channel, there's a corner case where a driver
      doesn't receive a beacon soon enough to be able to sync
      its timers with the AP. In this case, the only recovery
      (after trying again) is to disconnect from the AP. Allow
      calling ieee80211_connection_loss() for such cases. To
      make that possible, modify the work function to not rely
      on the IEEE80211_HW_CONNECTION_MONITOR flag but use new
      state kept in the interface instead.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  8. 31 Jan, 2013 3 commits
    • Johannes Berg's avatar
      mac80211: start auth/assoc timeout on frame status · 1672c0e3
      Johannes Berg authored
      When sending authentication/association frames they
      might take a bit of time to go out because we may
      have to synchronise with the AP, in particular in
      the case where it's really a P2P GO. In this case
      the 200ms fixed timeout could potentially be too
      short if the beacon interval is relatively large.
      For drivers that report TX status we can do better.
      Instead of starting the timeout directly, start it
      only when the frame status arrives. Since then the
      frame was out on the air, we can wait shorter (the
      typical response time is supposed to be 30ms, wait
      100ms.) Also, if the frame failed to be transmitted
      try again right away instead of waiting.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Emmanuel Grumbach's avatar
      mac80211: inform the driver about update of dtim_period · c65dd147
      Emmanuel Grumbach authored
      Currently, when the driver requires the DTIM period,
      mac80211 will wait to hear a beacon before association.
      This behavior is suboptimal since some drivers may be
      able to deal with knowing the DTIM period after the
      association, if they get it at all.
      To address this, notify the drivers with bss_info_changed
      with the new BSS_CHANGED_DTIM_PERIOD flag when the DTIM
      becomes known. This might be when changing to associated,
      or later when the entire association was done with only
      probe response information.
      Rename the hardware flag for the current behaviour to
      IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC to more accurately
      reflect its behaviour. IEEE80211_HW_NEED_DTIM_PERIOD is
      no longer accurate as all drivers get the DTIM period
      now, just not before association.
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      cfg80211/mac80211: support reporting wakeup reason · cd8f7cb4
      Johannes Berg authored
      When waking up from WoWLAN, it is useful to know
      what triggered the wakeup. Support reporting the
      wakeup reason(s) in cfg80211 (and a pass-through
      in mac80211) to allow userspace to know.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  9. 29 Jan, 2013 1 commit
  10. 24 Jan, 2013 1 commit
  11. 18 Jan, 2013 3 commits
  12. 16 Jan, 2013 2 commits
  13. 03 Jan, 2013 3 commits
    • Johannes Berg's avatar
      wireless: use __aligned · 1c06ef98
      Johannes Berg authored
      Use __aligned(...) instead of __attribute__((aligned(...)))
      in mac80211 and cfg80211.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: split TX aggregation stop action · 18b559d5
      Johannes Berg authored
      When TX aggregation is stopped, there are a few
      different cases:
       - connection with the peer was dropped
       - session stop was requested locally
       - session stop was requested by the peer
       - connection was dropped while a session is stopping
      The behaviour in these cases should be different, if
      the connection is dropped then the driver should drop
      all frames, otherwise the frames may continue to be
      transmitted, aggregated in the case of a locally
      requested session stop or unaggregated in the case of
      the peer requesting session stop.
      Split these different cases so that the driver can
      act accordingly; however, treat local and remote stop
      the same way and ask the driver to not send frames as
      aggregated packets any more.
      In the case of connection drop, the stop callback the
      driver is otherwise supposed to call is no longer
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: fix channel context iteration · 8a61af65
      Johannes Berg authored
      During suspend/resume channel contexts might be
      iterated even if they haven't been re-added to
      the driver, keep track of this and skip them in
      iteration. Also use the new status for sanity
      Also clarify the fact that during HW restart all
      contexts are iterated over (thanks Eliad.)
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  14. 05 Dec, 2012 1 commit
  15. 03 Dec, 2012 1 commit
  16. 30 Nov, 2012 1 commit
  17. 27 Nov, 2012 1 commit
  18. 26 Nov, 2012 3 commits