Skip to content

GitLab

Switch branch/tag
  1. 30 Mar, 2015 7 commits
  3. 16 Mar, 2015 1 commit
  5. 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
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
  7. 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>
      64a8cef4
    • 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>
      3384d757
    • 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>
      98fc4386
  9. 03 Mar, 2015 5 commits
  11. 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>
      36ef906e
    • 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>
      31f909a2
  13. 22 Feb, 2015 1 commit
  15. 20 Feb, 2015 1 commit
  17. 17 Feb, 2015 7 commits
  19. 16 Feb, 2015 10 commits
  21. 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
interrupts.

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
consequences.

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>
      124cf911
  23. 14 Feb, 2015 1 commit