alu-t-boost and hotplugs: use mod_delayed_work_on
Staging: android: binder: Ratelimit binder debug messages

Ratelimit the binder debug messages, since they can get spammy and
flood the entire kernel log.

In some cases, enabling serial console with a spammy binder error can
cause a watchdog panic (and we don't have reports of this happening
with serial console disabled).

Signed-off-by: Chris Fries <cfries@motorola.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
nl80211: add scan width to bss and scan request structs

To allow scanning and working with 5 MHz and 10 MHz BSS, extend the
inform bss commands and add wrappers to take 5 and 10 MHz bss into
account.

Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Chet Lanctot <clanctot@codeaurora.org>
Signed-off-by: Amarnath Hullur Subramanyam <amarnath@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cfg80211: clarify BSS probe response vs. beacon data

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: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Chet Lanctot <clanctot@codeaurora.org>
[amarnath@codeaurora.org: Only picked up the change in nl80211.h for the user
 space code to remain same. Other changes are not applicable for this version
 of the kernel]
Signed-off-by: Amarnath Hullur Subramanyam <amarnath@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Removed CONFIG_MSM_RUN_QUEUE_STATS_USE_CPU_UTIL
Removed useless config
Removed get_work_pwq unwind backtrace warning.