1. 30 Mar, 2015 7 commits
  2. 16 Mar, 2015 1 commit
  3. 06 Mar, 2015 1 commit
    • 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
      - 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>
  4. 04 Mar, 2015 3 commits
    • SenthilKumar Jegadeesan's avatar
      mac80211: provide station PMF configuration to driver · 64a8cef4
      SenthilKumar Jegadeesan authored
      Some device drivers offload part of aggregation including AddBA/DelBA
      negotiations to firmware. In such scenario, the PMF configuration of
      the station needs to be provided to driver to enable encryption of
      AddBA/DelBA action frames.
      Signed-off-by: default avatarSenthilKumar Jegadeesan <sjegadee@qti.qualcomm.com>
      [fix commit log, documentation]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Arik Nemtsov's avatar
      mac80211: allow iterating inactive interfaces · 3384d757
      Arik Nemtsov authored
      Sometimes the driver might want to modify private data in interfaces
      that are down. One possible use-case is cleaning up interface state
      after HW recovery. Some interfaces that were up before the recovery took
      place might be down now, but they might still be "dirty".
      Introduce a new iterate_interfaces() API and a new ACTIVE iterator flag.
      This way the internal implementation of the both active and inactive
      APIs remains the same.
      Signed-off-by: default avatarArik Nemtsov <arikx.nemtsov@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      nl80211: prohibit mixing 'any' and regular wowlan triggers · 98fc4386
      Johannes Berg authored
      If the device supports waking up on 'any' signal - i.e. it continues
      operating as usual and wakes up the host on pretty much anything that
      happens, then it makes no sense to also configure the more restricted
      WoWLAN mode where the device operates more autonomously but also in a
      more restricted fashion.
      Currently only cw2100 supports both 'any' and other triggers, but it
      seems to be broken as it doesn't configure anything to the device, so
      we can't currently get into a situation where both even can correctly
      be configured. This is about to change (Intel devices are going to
      support both and have different behaviour depending on configuration)
      so make sure the conflicting modes cannot be configured.
      (It seems that cw2100 advertises 'any' and 'disconnect' as a means of
      saying that's what it will always do, but that isn't really the way
      this API was meant to be used nor does it actually mean anything as
      'any' always implies 'disconnect' already, and the driver doesn't
      change device configuration in any way depending on the settings.)
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  5. 03 Mar, 2015 5 commits
  6. 28 Feb, 2015 2 commits
    • Johannes Berg's avatar
      wext: add checked wrappers for adding events/points to streams · 36ef906e
      Johannes Berg authored
      These checked wrappers are necessary for the next patch, which
      will use them to avoid sending out partial scan results.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Masashi Honma's avatar
      nl/mac80211: allow zero plink timeout to disable STA expiration · 31f909a2
      Masashi Honma authored
      Both wpa_supplicant and mac80211 have and inactivity timer. By default
      wpa_supplicant will be timed out in 5 minutes and mac80211's it is 30
      minutes. If wpa_supplicant uses a longer timer than mac80211, it will
      get unexpected disconnection by mac80211.
      Using 0xffffffff instead as the configured value could solve this w/o
      changing the code, but due to integer overflow in the expression used
      this doesn't work. The expression is:
      (current jiffies) > (frame Rx jiffies + NL80211_MESHCONF_PLINK_TIMEOUT * 250)
      On 32bit system, the right side would overflow and be a very small
      value if NL80211_MESHCONF_PLINK_TIMEOUT is sufficiently large,
      causing unexpectedly early disconnections.
      Instead allow disabling the inactivity timer to avoid this situation,
      by passing the (previously invalid and useless) value 0.
      Signed-off-by: default avatarMasashi Honma <masashi.honma@gmail.com>
      [reword/rewrap commit log]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  7. 22 Feb, 2015 1 commit
  8. 20 Feb, 2015 1 commit
  9. 17 Feb, 2015 7 commits
  10. 16 Feb, 2015 10 commits
  11. 15 Feb, 2015 1 commit
    • Rafael J. Wysocki's avatar
      PM / sleep: Make it possible to quiesce timers during suspend-to-idle · 124cf911
      Rafael J. Wysocki authored
      The efficiency of suspend-to-idle depends on being able to keep CPUs
      in the deepest available idle states for as much time as possible.
      Ideally, they should only be brought out of idle by system wakeup
      However, timer interrupts occurring periodically prevent that from
      happening and it is not practical to chase all of the "misbehaving"
      timers in a whack-a-mole fashion.  A much more effective approach is
      to suspend the local ticks for all CPUs and the entire timekeeping
      along the lines of what is done during full suspend, which also
      helps to keep suspend-to-idle and full suspend reasonably similar.
      The idea is to suspend the local tick on each CPU executing
      cpuidle_enter_freeze() and to make the last of them suspend the
      entire timekeeping.  That should prevent timer interrupts from
      triggering until an IO interrupt wakes up one of the CPUs.  It
      needs to be done with interrupts disabled on all of the CPUs,
      though, because otherwise the suspended clocksource might be
      accessed by an interrupt handler which might lead to fatal
      Unfortunately, the existing ->enter callbacks provided by cpuidle
      drivers generally cannot be used for implementing that, because some
      of them re-enable interrupts temporarily and some idle entry methods
      cause interrupts to be re-enabled automatically on exit.  Also some
      of these callbacks manipulate local clock event devices of the CPUs
      which really shouldn't be done after suspending their ticks.
      To overcome that difficulty, introduce a new cpuidle state callback,
      ->enter_freeze, that will be guaranteed (1) to keep interrupts
      disabled all the time (and return with interrupts disabled) and (2)
      not to touch the CPU timer devices.  Modify cpuidle_enter_freeze() to
      look for the deepest available idle state with ->enter_freeze present
      and to make the CPU execute that callback with suspended tick (and the
      last of the online CPUs to execute it with suspended timekeeping).
      Suggested-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
  12. 14 Feb, 2015 1 commit