1. 12 8月, 2013 1 次提交
  2. 02 8月, 2013 1 次提交
  3. 22 4月, 2013 1 次提交
  4. 06 3月, 2013 2 次提交
    • S
      cfg80211/mac80211: disconnect on suspend · 81256969
      Stanislaw Gruszka 提交于
      If possible that after suspend, cfg80211 will receive request to
      disconnect what require action on interface that was removed during
      suspend.
      
      Problem can manifest itself by various warnings similar to below one:
      
      WARNING: at net/mac80211/driver-ops.h:12 ieee80211_bss_info_change_notify+0x2f9/0x300 [mac80211]()
      wlan0:  Failed check-sdata-in-driver check, flags: 0x4
      Call Trace:
       [<c043e0b3>] warn_slowpath_fmt+0x33/0x40
       [<f83707c9>] ieee80211_bss_info_change_notify+0x2f9/0x300 [mac80211]
       [<f83a660a>] ieee80211_recalc_ps_vif+0x2a/0x30 [mac80211]
       [<f83a6706>] ieee80211_set_disassoc+0xf6/0x500 [mac80211]
       [<f83a9441>] ieee80211_mgd_deauth+0x1f1/0x280 [mac80211]
       [<f8381b36>] ieee80211_deauth+0x16/0x20 [mac80211]
       [<f8261e70>] cfg80211_mlme_down+0x70/0xc0 [cfg80211]
       [<f8264de1>] __cfg80211_disconnect+0x1b1/0x1d0 [cfg80211]
      
      To fix the problem disconnect from any associated network before
      suspend. User space is responsible to establish connection again
      after resume. This basically need to be done by user space anyway,
      because associated stations can go away during suspend (for example
      NetworkManager disconnects on suspend and connect on resume by default).
      
      Patch also handle situation when driver refuse to suspend with wowlan
      configured and try to suspend again without it.
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      81256969
    • J
      cfg80211: Extend support for IEEE 802.11r Fast BSS Transition · 355199e0
      Jouni Malinen 提交于
      Add NL80211_CMD_UPDATE_FT_IES to support update of FT IEs to the WLAN
      driver and NL80211_CMD_FT_EVENT to send FT events from the WLAN driver.
      This will carry the target AP's MAC address along with the relevant
      Information Elements. This event is used to report received FT IEs
      (MDIE, FTIE, RSN IE, TIE, RICIE). These changes allow FT to be supported
      with drivers that use an internal SME instead of user space option (like
      FT implementation in wpa_supplicant with mac80211-based drivers).
      Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      355199e0
  5. 26 1月, 2013 1 次提交
  6. 26 11月, 2012 2 次提交
    • J
      cfg80211: pass a channel definition struct · 683b6d3b
      Johannes Berg 提交于
      Instead of passing a channel pointer and channel type
      to all functions and driver methods, pass a new channel
      definition struct. Right now, this struct contains just
      the control channel and channel type, but for VHT this
      will change.
      
      Also, add a small inline cfg80211_get_chandef_type() so
      that drivers don't need to use the _type field of the
      new structure all the time, which will change.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      683b6d3b
    • J
      cfg80211: remove remain-on-channel channel type · 42d97a59
      Johannes Berg 提交于
      As mwifiex (and mac80211 in the software case) are the
      only drivers actually implementing remain-on-channel
      with channel type, userspace can't be relying on it.
      This is the case, as it's used only for P2P operations
      right now.
      
      Rather than adding a flag to tell userspace whether or
      not it can actually rely on it, simplify all the code
      by removing the ability to use different channel types.
      Leave only the validation of the attribute, so that if
      we extend it again later (with the needed capability
      flag), it can't break userspace sending invalid data.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      42d97a59
  7. 30 10月, 2012 1 次提交
    • J
      cfg80211: allow per interface TX power setting · c8442118
      Johannes Berg 提交于
      The TX power setting is currently per wiphy (hardware
      device) but with multi-channel capabilities that doesn't
      make much sense any more.
      
      Allow drivers (and mac80211) to advertise support for
      per-interface TX power configuration. When the TX power
      is configured for the wiphy, the wdev will be NULL and
      the driver can still handle that, but when a wdev is
      given the TX power can be set only for that wdev now.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      c8442118
  8. 24 10月, 2012 1 次提交
  9. 18 10月, 2012 2 次提交