1. 18 12月, 2014 2 次提交
  2. 17 12月, 2014 1 次提交
    • J
      cfg80211: allow wiphy specific regdomain management · b0d7aa59
      Jonathan Doron 提交于
      Add a new regulatory flag that allows a driver to manage regdomain
      changes/updates for its own wiphy.
      A self-managed wiphys only employs regulatory information obtained from
      the FW and driver and does not use other cfg80211 sources like
      beacon-hints, country-code IEs and hints from other devices on the same
      system. Conversely, a self-managed wiphy does not share its regulatory
      hints with other devices in the system. If a system contains several
      devices, one or more of which are self-managed, there might be
      contradictory regulatory settings between them. Usage of flag is
      generally discouraged. Only use it if the FW/driver is incompatible
      with non-locally originated hints.
      
      A new API lets the driver send a complete regdomain, to be applied on
      its wiphy only.
      
      After a wiphy-specific regdomain change takes place, usermode will get
      a new type of change notification. The regulatory core also takes care
      enforce regulatory restrictions, in case some interfaces are on
      forbidden channels.
      Signed-off-by: NJonathan Doron <jonathanx.doron@intel.com>
      Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com>
      Reviewed-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      b0d7aa59
  3. 27 11月, 2014 1 次提交
  4. 26 11月, 2014 1 次提交
  5. 20 11月, 2014 3 次提交
  6. 10 11月, 2014 1 次提交
    • L
      cfg80211: add channel switch started notification · f8d7552e
      Luciano Coelho 提交于
      Add a new NL80211_CH_SWITCH_STARTED_NOTIFY message that can be sent to
      the userspace when a channel switch process has started.  This allows
      userspace to take action, for instance, by requesting other interfaces
      to switch channel as necessary.
      
      This patch introduces a function that allows the drivers to send this
      notification.  It should be used when the driver starts processing a
      channel switch initiated by a remote device (eg. when a STA receives a
      CSA from the AP) and when it successfully starts a userspace-triggered
      channel switch (eg. when hostapd triggers a channel swith in the AP).
      Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f8d7552e
  7. 04 11月, 2014 1 次提交
    • R
      cfg80211: 802.11p OCB mode handling · 6e0bd6c3
      Rostislav Lisovy 提交于
      This patch adds new iface type (NL80211_IFTYPE_OCB) representing
      the OCB (Outside the Context of a BSS) mode.
      When establishing a connection to the network a cfg80211_join_ocb
      function is called (particular nl80211_command is added as well).
      A mandatory parameters during the ocb_join operation are 'center
      frequency' and 'channel width (5/10 MHz)'.
      
      Changes done in mac80211 are minimal possible required to avoid
      many warnings (warning: enumeration value 'NL80211_IFTYPE_OCB'
      not handled in switch) during compilation. Full functionality
      (where needed) is added in the following patch.
      Signed-off-by: NRostislav Lisovy <rostislav.lisovy@fel.cvut.cz>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6e0bd6c3
  8. 27 10月, 2014 2 次提交
  9. 22 10月, 2014 1 次提交
    • J
      cfg80211: make WMM TSPEC support flag an nl80211 feature flag · 723e73ac
      Johannes Berg 提交于
      During the review of the corresponding wpa_supplicant patches we
      noticed that the only way for it to detect that this functionality
      is supported currently is to check for the command support. This
      can be misleading though, as the command was also designed to, in
      the future, support pure 802.11 TSPECs.
      
      Expose the WMM-TSPEC feature flag to nl80211 so later we can also
      expose an 802.11-TSPEC feature flag (if needed) to differentiate
      the two cases.
      
      Note: this change isn't needed in 3.18 as there's no driver there
      yet that supports the functionality at all.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      723e73ac
  10. 20 10月, 2014 2 次提交
  11. 09 10月, 2014 1 次提交
  12. 11 9月, 2014 4 次提交
  13. 05 9月, 2014 3 次提交
  14. 26 8月, 2014 3 次提交
    • J
      cfg80211: allow passing frame type to cfg80211_inform_bss() · 5bc8c1f2
      Johannes Berg 提交于
      When using the cfg80211_inform_bss[_width]() functions drivers
      cannot currently indicate whether the data was received in a
      beacon or probe response. Fix that by passing a new enum that
      indicates such (or unknown).
      
      For good measure, use it in ath6kl.
      
      Acked-by: Kalle Valo <kvalo@qca.qualcomm.com> [ath6kl]
      Acked-by: Arend van Spriel <arend@broadcom.com> [brcmfmac]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      5bc8c1f2
    • J
      cfg80211: clarify BSS probe response vs. beacon data · 0e227084
      Johannes Berg 提交于
      There are a few possible cases of where BSS data came from:
       1) only a beacon has been received
       2) only a probe response has been received
       3) the driver didn't report what it received (this happens when
          using cfg80211_inform_bss[_width]())
       4) both probe response and beacon data has been received
      
      Unfortunately, in the userspace API, a few things weren't there:
       a) there was no way to differentiate cases 1) and 4) above
          without comparing the data of the IEs
       b) the TSF was always from the last frame, instead of being
          exposed for beacon/probe response separately like IEs
      
      Fix this by
         i) exporting a new flag attribute that indicates whether or
            not probe response data has been received - this addresses (a)
        ii) exporting a BEACON_TSF attribute that holds the beacon's TSF
            if a beacon has been received
       iii) not exporting the beacon attributes in case (3) above as that
            would just lead userspace into thinking the data actually came
            from a beacon when that isn't clear
      
      To implement this, track inside the IEs struct whether or not it
      (definitely) came from a beacon.
      
      Reported-by: William Seto
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      0e227084
    • V
      cfg80211: remove @gfp parameter from cfg80211_rx_mgmt() · 970fdfa8
      Vladimir Kondratiev 提交于
      In the cfg80211_rx_mgmt(), parameter @gfp was used for the memory allocation.
      But, memory get allocated under spin_lock_bh(), this implies atomic context.
      So, one can't use GFP_KERNEL, only variants with no __GFP_WAIT. Actually, in all
      occurrences GFP_ATOMIC is used (wil6210 use GFP_KERNEL by mistake),
      and it should be this way or warning triggered in the memory allocation code.
      
      Remove @gfp parameter as no actual choice exist, and use hard coded
      GFP_ATOMIC for memory allocation.
      Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      970fdfa8
  15. 26 6月, 2014 1 次提交
  16. 23 6月, 2014 2 次提交
  17. 22 5月, 2014 1 次提交
    • E
      cfg80211: allow RSSI compensation · 67af9811
      Emmanuel Grumbach 提交于
      Channels in 2.4GHz band overlap, this means that if we
      send a probe request on channel 1 and then move to channel
      2, we will hear the probe response on channel 2. In this
      case, the RSSI will be lower than if we had heard it on
      the channel on which it was sent (1 in this case).
      
      The firmware / low level driver can parse the channel in
      the DS IE or HT IE and compensate the RSSI so that it will
      still have a valid value even if we heard the frame on an
      adjacent channel. This can be done up to a certain offset.
      
      Add this offset as a configuration for the low level driver.
      A low level driver that can compensate the low RSSI in this
      case should assign the maximal offset for which the RSSI
      value is still valid.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      67af9811
  18. 21 5月, 2014 1 次提交
  19. 20 5月, 2014 2 次提交
  20. 19 5月, 2014 3 次提交
  21. 15 5月, 2014 2 次提交
  22. 13 5月, 2014 1 次提交
  23. 09 5月, 2014 1 次提交