1. 06 Mar, 2015 2 commits
    • Ilan peer's avatar
      cfg80211: Add API to change the indoor regulatory setting · 05050753
      Ilan peer authored
      
      
      Previously, the indoor setting configuration assumed that as
      long as a station interface is connected, the indoor environment
      setting does not change. However, this assumption is problematic
      as:
      
      - It is possible that a station interface is connected to a mobile
        AP, e.g., softAP or a P2P GO, where it is possible that both the
        station and the mobile AP move out of the indoor environment making
        the indoor setting invalid. In such a case, user space has no way to
        invalidate the setting.
      - A station interface disconnection does not necessarily imply that
        the device is no longer operating in an indoor environment, e.g.,
        it is possible that the station interface is roaming but is still
        stays indoor.
      
      To handle the above, extend the indoor configuration API to allow
      user space to indicate a change of indoor settings, and allow it to
      indicate weather it controls the indoor setting, such that:
      
      1. If the user space process explicitly indicates that it is going
         to control the indoor setting, do not clear the indoor setting
         internally, unless the socket is released. The user space process
         should use the NL80211_ATTR_SOCKET_OWNER attribute in the command
         to state that it is going to control the indoor setting.
      2. Reset the indoor setting when restoring the regulatory settings in
         case it is not owned by a user space process.
      
      Based on the above, a user space tool that continuously monitors the
      indoor settings, i.e., tracking power setting, location etc., can
      indicate environment changes to the regulatory core.
      
      It should be noted that currently user space is the only provided mechanism
      used to hint to the regulatory core over the indoor/outdoor environment --
      while the country IEs do have an environment setting this has been completely
      ignored by the regulatory core by design for a while now since country IEs
      typically can contain bogus data.
      Acked-by: default avatarLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: default avatarArikX Nemtsov <arik@wizery.com>
      Signed-off-by: default avatarIlan Peer <ilan.peer@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      05050753
    • Ilan peer's avatar
      cfg80211: Simplify the handling of regulatory indoor setting · 0c4ddcd2
      Ilan peer authored
      
      
      Directly update the indoor setting without wrapping it as
      a regulatory request, to simplify the processing.
      Acked-by: default avatarLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: default avatarIlan Peer <ilan.peer@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      0c4ddcd2
  2. 14 Jan, 2015 2 commits
  3. 07 Jan, 2015 1 commit
  4. 17 Dec, 2014 3 commits
    • Arik Nemtsov's avatar
      cfg80211: avoid intersection when applying self-managed reg · db8dfee5
      Arik Nemtsov authored
      
      
      The custom-reg handling function can currently only add flags to a given
      channel. This results in stale flags being left applied. In some cases
      a channel was disabled and even the orig_flags were changed to reflect
      this.
      
      Previously the API was designed for a single invocation before wiphy
      registration, so this didn't matter. The previous approach doesn't scale
      well to self-managed regulatory devices, particularly when a more
      permissive regdom is applied after a restrictive one.
      Signed-off-by: default avatarArik Nemtsov <arikx.nemtsov@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      db8dfee5
    • Jonathan Doron's avatar
      cfg80211: allow wiphy specific regdomain management · b0d7aa59
      Jonathan Doron authored
      
      
      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: default avatarJonathan Doron <jonathanx.doron@intel.com>
      Signed-off-by: default avatarArik Nemtsov <arikx.nemtsov@intel.com>
      Reviewed-by: default avatarLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      b0d7aa59
    • Arik Nemtsov's avatar
      cfg80211: allow usermode to query wiphy specific regdom · ad30ca2c
      Arik Nemtsov authored
      
      
      If a wiphy-idx is specified, the kernel will return the wiphy specific
      regdomain, if such exists. Otherwise return the global regdom.
      
      When no wiphy-idx is specified, return the global regdomain as well as
      all wiphy-specific regulatory domains in the system, via a new nested
      list of attributes.
      
      Add a new attribute for each wiphy-specific regdomain, for usermode to
      identify it as such.
      Signed-off-by: default avatarArik Nemtsov <arikx.nemtsov@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      ad30ca2c
  5. 12 Dec, 2014 4 commits
  6. 28 Nov, 2014 1 commit
  7. 19 Nov, 2014 2 commits
  8. 10 Nov, 2014 1 commit
  9. 05 Sep, 2014 2 commits
  10. 23 Jun, 2014 1 commit
  11. 21 May, 2014 1 commit
  12. 25 Apr, 2014 1 commit
  13. 22 Apr, 2014 2 commits
    • Luis R. Rodriguez's avatar
      cfg80211: fix processing world regdomain when non modular · 96cce12f
      Luis R. Rodriguez authored
      
      
      This allows processing of the last regulatory request when
      we determine its still pending. Without this if a regulatory
      request failed to get processed by userspace we wouldn't
      be able to re-process it later. An example situation that can
      lead to an unprocessed last_request is enabling cfg80211 to
      be built-in to the kernel, not enabling CFG80211_INTERNAL_REGDB
      and the CRDA binary not being available at the time the udev
      rule that kicks of CRDA triggers.
      
      In such a situation we want to let some cfg80211 triggers
      eventually kick CRDA for us again. Without this if the first
      cycle attempt to kick off CRDA failed we'd be stuck without
      the ability to change process any further regulatory domains.
      
      cfg80211 will trigger re-processing of the regulatory queue
      whenever schedule_work(&reg_work) is called, currently this
      happens when:
      
        * suspend / resume
        * disconnect
        * a beacon hint gets triggered (non DFS 5 GHz AP found)
        * a regulatory request gets added to the queue
      
      We don't have any specific opportunistic late boot triggers
      to address a late mount of where CRDA resides though, adding
      that should be done separately through another patch.
      Without an opportunistic fix then this fix relies at least
      one of the triggeres above to happen.
      Reported-by: default avatarSander Eikelenboom <linux@eikelenboom.it>
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      96cce12f
    • Arik Nemtsov's avatar
      cfg80211: avoid freeing last_request while in flight · c888393b
      Arik Nemtsov authored
      
      
      Avoid freeing the last request while it is being processed. This can
      happen in some cases if reg_work is kicked for some reason while the
      currently pending request is in flight.
      
      Cc: Sander Eikelenboom <linux@eikelenboom.it>
      Tested-by: default avatarEliad Peller <eliad@wizery.com>
      Tested-by: default avatarColleen Twitty <colleen@cozybit.com>
      Signed-off-by: default avatarArik Nemtsov <arik@wizery.com>
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      c888393b
  14. 11 Apr, 2014 1 commit
  15. 09 Apr, 2014 6 commits
  16. 03 Mar, 2014 1 commit
  17. 25 Feb, 2014 4 commits
  18. 21 Feb, 2014 1 commit
  19. 19 Feb, 2014 1 commit
  20. 05 Feb, 2014 1 commit
    • Janusz Dziedzic's avatar
      cfg80211: regulatory introduce maximum bandwidth calculation · 97524820
      Janusz Dziedzic authored
      
      
      In case we will get regulatory request with rule
      where max_bandwidth_khz is set to 0 handle this
      case as a special one.
      
      If max_bandwidth_khz == 0 we should calculate maximum
      available bandwidth base on all frequency contiguous rules.
      In case we need auto calculation we just have to set:
      
      country PL: DFS-ETSI
              (2402 - 2482 @ 40), (N/A, 20)
              (5170 - 5250 @ AUTO), (N/A, 20)
              (5250 - 5330 @ AUTO), (N/A, 20), DFS
              (5490 - 5710 @ 80), (N/A, 27), DFS
      
      This mean we will calculate maximum bw for rules where
      AUTO (N/A) were set, 160MHz (5330 - 5170) in example above.
      So we will get:
              (5170 - 5250 @ 160), (N/A, 20)
              (5250 - 5330 @ 160), (N/A, 20), DFS
      
      In other case:
      country FR: DFS-ETSI
              (2402 - 2482 @ 40), (N/A, 20)
              (5170 - 5250 @ AUTO), (N/A, 20)
              (5250 - 5330 @ 80), (N/A, 20), DFS
              (5490 - 5710 @ 80), (N/A, 27), DFS
      
      We will get 80MHz (5250 - 5170):
              (5170 - 5250 @ 80), (N/A, 20)
              (5250 - 5330 @ 80), (N/A, 20), DFS
      
      Base on this calculations we will set correct channel
      bandwidth flags (eg. IEEE80211_CHAN_NO_80MHZ).
      
      We don't need any changes in CRDA or internal regulatory.
      Signed-off-by: default avatarJanusz Dziedzic <janusz.dziedzic@tieto.com>
      [extend nl80211 description a bit, fix typo]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      97524820
  21. 04 Feb, 2014 2 commits