Recent contributions, including to DRM and binder, introduce 64-bit
values in their interfaces. A common motivation for this is to allow
the same ABI for 32- and 64-bit userspaces (and therefore also a shared
ABI for 32/64 hybrid userspaces). Anyhow, the developers would like to
avoid gotchas like having to use copy_from_user().
This feature is already implemented on x86-32 and the majority of other
32-bit architectures. The current list of get_user_8 hold out
architectures are: arm, avr32, blackfin, m32r, metag, microblaze,
mn10300, sh.
Credit:
My name sits rather uneasily at the top of this patch. The v1 and
v2 versions of the patch were written by Rob Clark and to produce v4
I mostly copied code from Russell King and H. Peter Anvin. However I
have mangled the patch sufficiently that *blame* is rightfully mine
even if credit should more widely shared.
Changelog:
v5: updated to use the ret macro (requested by Russell King)
v4: remove an inlined add on big endian systems (spotted by Russell King),
used __ARMEB__ rather than BIG_ENDIAN (to match rest of file),
cleared r3 on EFAULT during __get_user_8.
v3: fix a couple of checkpatch issues
v2: pass correct size to check_uaccess, and better handling of narrowing
double word read with __get_user_xb() (Russell King's suggestion)
v1: original
Change-Id: I41787d73f0844c15b6bd0424a5f83cafaba8b508
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[flex1911: backport to 3.4: use "mov pc" instruction instead of
nonexistent here "ret" macro]
Signed-off-by: Artem Borisov <dedsa2002@gmail.com>
Clean cherry pick of eb6452537b.
Add the new getrandom syscall for ARM.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Bug: http://b/29621447
Change-Id: I6d50b57f3a61fbf9102c69103b9a5b7ebf239860
(cherry picked from commit eb6452537b)
[flex1911]: backport to 3.4
Clean cherry pick of 1d9de44e268d880cbe2d0bd3be1ef0661f93fd34.
If more than one application invokes getrandom(2) before the pool
is ready, then all bar one will be stuck forever because we use
wake_up_interruptible which wakes up a single task.
This patch replaces it with wake_up_all.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Bug: http://b/29621447
Change-Id: I5dfd7abac10898802f030e0a2af7110809283328
(cherry picked from commit 1d9de44e268d880cbe2d0bd3be1ef0661f93fd34)
Almost clean cherry pick of c6e9d6f388,
includes change made by merge 0891ad829d.
The getrandom(2) system call was requested by the LibreSSL Portable
developers. It is analoguous to the getentropy(2) system call in
OpenBSD.
The rationale of this system call is to provide resiliance against
file descriptor exhaustion attacks, where the attacker consumes all
available file descriptors, forcing the use of the fallback code where
/dev/[u]random is not available. Since the fallback code is often not
well-tested, it is better to eliminate this potential failure mode
entirely.
The other feature provided by this new system call is the ability to
request randomness from the /dev/urandom entropy pool, but to block
until at least 128 bits of entropy has been accumulated in the
/dev/urandom entropy pool. Historically, the emphasis in the
/dev/urandom development has been to ensure that urandom pool is
initialized as quickly as possible after system boot, and preferably
before the init scripts start execution.
This is because changing /dev/urandom reads to block represents an
interface change that could potentially break userspace which is not
acceptable. In practice, on most x86 desktop and server systems, in
general the entropy pool can be initialized before it is needed (and
in modern kernels, we will printk a warning message if not). However,
on an embedded system, this may not be the case. And so with this new
interface, we can provide the functionality of blocking until the
urandom pool has been initialized. Any userspace program which uses
this new functionality must take care to assure that if it is used
during the boot process, that it will not cause the init scripts or
other portions of the system startup to hang indefinitely.
SYNOPSIS
#include <linux/random.h>
int getrandom(void *buf, size_t buflen, unsigned int flags);
DESCRIPTION
The system call getrandom() fills the buffer pointed to by buf
with up to buflen random bytes which can be used to seed user
space random number generators (i.e., DRBG's) or for other
cryptographic uses. It should not be used for Monte Carlo
simulations or other programs/algorithms which are doing
probabilistic sampling.
If the GRND_RANDOM flags bit is set, then draw from the
/dev/random pool instead of the /dev/urandom pool. The
/dev/random pool is limited based on the entropy that can be
obtained from environmental noise, so if there is insufficient
entropy, the requested number of bytes may not be returned.
If there is no entropy available at all, getrandom(2) will
either block, or return an error with errno set to EAGAIN if
the GRND_NONBLOCK bit is set in flags.
If the GRND_RANDOM bit is not set, then the /dev/urandom pool
will be used. Unlike using read(2) to fetch data from
/dev/urandom, if the urandom pool has not been sufficiently
initialized, getrandom(2) will block (or return -1 with the
errno set to EAGAIN if the GRND_NONBLOCK bit is set in flags).
The getentropy(2) system call in OpenBSD can be emulated using
the following function:
int getentropy(void *buf, size_t buflen)
{
int ret;
if (buflen > 256)
goto failure;
ret = getrandom(buf, buflen, 0);
if (ret < 0)
return ret;
if (ret == buflen)
return 0;
failure:
errno = EIO;
return -1;
}
RETURN VALUE
On success, the number of bytes that was filled in the buf is
returned. This may not be all the bytes requested by the
caller via buflen if insufficient entropy was present in the
/dev/random pool, or if the system call was interrupted by a
signal.
On error, -1 is returned, and errno is set appropriately.
ERRORS
EINVAL An invalid flag was passed to getrandom(2)
EFAULT buf is outside the accessible address space.
EAGAIN The requested entropy was not available, and
getentropy(2) would have blocked if the
GRND_NONBLOCK flag was not set.
EINTR While blocked waiting for entropy, the call was
interrupted by a signal handler; see the description
of how interrupted read(2) calls on "slow" devices
are handled with and without the SA_RESTART flag
in the signal(7) man page.
NOTES
For small requests (buflen <= 256) getrandom(2) will not
return EINTR when reading from the urandom pool once the
entropy pool has been initialized, and it will return all of
the bytes that have been requested. This is the recommended
way to use getrandom(2), and is designed for compatibility
with OpenBSD's getentropy() system call.
However, if you are using GRND_RANDOM, then getrandom(2) may
block until the entropy accounting determines that sufficient
environmental noise has been gathered such that getrandom(2)
will be operating as a NRBG instead of a DRBG for those people
who are working in the NIST SP 800-90 regime. Since it may
block for a long time, these guarantees do *not* apply. The
user may want to interrupt a hanging process using a signal,
so blocking until all of the requested bytes are returned
would be unfriendly.
For this reason, the user of getrandom(2) MUST always check
the return value, in case it returns some error, or if fewer
bytes than requested was returned. In the case of
!GRND_RANDOM and small request, the latter should never
happen, but the careful userspace code (and all crypto code
should be careful) should check for this anyway!
Finally, unless you are doing long-term key generation (and
perhaps not even then), you probably shouldn't be using
GRND_RANDOM. The cryptographic algorithms used for
/dev/urandom are quite conservative, and so should be
sufficient for all purposes. The disadvantage of GRND_RANDOM
is that it can block, and the increased complexity required to
deal with partially fulfilled getrandom(2) requests.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Zach Brown <zab@zabbo.net>
Bug: http://b/29621447
Change-Id: I189ba74070dd6d918b0fdf83ff30bb74ec0f7556
(cherry picked from commit 4af712e8df)
[flex1911]: backport to 3.4
Clean cherry pick of commit 4af712e8df.
The Tausworthe PRNG is initialized at late_initcall time. At that time the
entropy pool serving get_random_bytes is not filled sufficiently. This
patch adds an additional reseeding step as soon as the nonblocking pool
gets marked as initialized.
On some machines it might be possible that late_initcall gets called after
the pool has been initialized. In this situation we won't reseed again.
(A call to prandom_seed_late blocks later invocations of early reseed
attempts.)
Joint work with Daniel Borkmann.
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Bug: http://b/29621447
Change-Id: I4d20e60b5df16228f3a3699d16ed2b1dddcceb2b
(cherry picked from commit 4af712e8df)
Clean cherry pick of commmit 6d31920246.
The current Tausworthe PRNG is never reseeded with truly random data after
the first attempt in late_initcall. As this PRNG is used for some critical
random data as e.g. UDP port randomization we should try better and reseed
the PRNG once in a while with truly random data from get_random_bytes().
When we reseed with prandom_seed we now make also sure to throw the first
output away. This suffices the reseeding procedure.
The delay calculation is based on a proposal from Eric Dumazet.
Joint work with Daniel Borkmann.
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Bug: http://b/29621447
Change-Id: I990d00f4a29a56a22357cec1c17477c4721054ae
(cherry picked from commit 6d31920246)
[ Upstream commit 51c37a70aa ]
For properly initialising the Tausworthe generator [1], we have
a strict seeding requirement, that is, s1 > 1, s2 > 7, s3 > 15.
Commit 697f8d0348 ("random32: seeding improvement") introduced
a __seed() function that imposes boundary checks proposed by the
errata paper [2] to properly ensure above conditions.
However, we're off by one, as the function is implemented as:
"return (x < m) ? x + m : x;", and called with __seed(X, 1),
__seed(X, 7), __seed(X, 15). Thus, an unwanted seed of 1, 7, 15
would be possible, whereas the lower boundary should actually
be of at least 2, 8, 16, just as GSL does. Fix this, as otherwise
an initialization with an unwanted seed could have the effect
that Tausworthe's PRNG properties cannot not be ensured.
Note that this PRNG is *not* used for cryptography in the kernel.
[1] http://www.iro.umontreal.ca/~lecuyer/myftp/papers/tausme.ps
[2] http://www.iro.umontreal.ca/~lecuyer/myftp/papers/tausme2.ps
Joint work with Hannes Frederic Sowa.
Change-Id: I9c63774e7a0cd5d747469b11b8769867484f36f9
Fixes: 697f8d0348 ("random32: seeding improvement")
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: Florian Weimer <fweimer@redhat.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add functions to get the requested number of pseudo-random bytes.
The difference from get_random_bytes() is that it generates pseudo-random
numbers by prandom_u32(). It doesn't consume the entropy pool, and the
sequence is reproducible if the same rnd_state is used. So it is suitable
for generating random bytes for testing.
Change-Id: Iabb55fae5043dd7dad8ceb4537e0a8e14436231e
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Eilon Greenstein <eilong@broadcom.com>
Cc: David Laight <david.laight@aculab.com>
Cc: Michel Lespinasse <walken@google.com>
Cc: Robert Love <robert.w.love@intel.com>
Cc: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This renames all random32 functions to have 'prandom_' prefix as follows:
void prandom_seed(u32 seed); /* rename from srandom32() */
u32 prandom_u32(void); /* rename from random32() */
void prandom_seed_state(struct rnd_state *state, u64 seed);
/* rename from prandom32_seed() */
u32 prandom_u32_state(struct rnd_state *state);
/* rename from prandom32() */
The purpose of this renaming is to prevent some kernel developers from
assuming that prandom32() and random32() might imply that only
prandom32() was the one using a pseudo-random number generator by
prandom32's "p", and the result may be a very embarassing security
exposure. This concern was expressed by Theodore Ts'o.
And furthermore, I'm going to introduce new functions for getting the
requested number of pseudo-random bytes. If I continue to use both
prandom32 and random32 prefixes for these functions, the confusion
is getting worse.
As a result of this renaming, "prandom_" is the common prefix for
pseudo-random number library.
Currently, srandom32() and random32() are preserved because it is
difficult to rename too many users at once.
Change-Id: I8c4118c9356d1917048ea435f32b68e20d04b577
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Robert Love <robert.w.love@intel.com>
Cc: Michel Lespinasse <walken@google.com>
Cc: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Cc: David Laight <david.laight@aculab.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Artem Bityutskiy <dedekind1@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Eilon Greenstein <eilong@broadcom.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
binder_fd_array_object starts with a 4-byte header,
followed by a few fields that are 8 bytes when
ANDROID_BINDER_IPC_32BIT=N.
This can cause alignment issues in a 64-bit kernel
with a 32-bit userspace, as on x86_32 an 8-byte primitive
may be aligned to a 4-byte address. Pad with a __u32
to fix this.
Change-Id: I4374ed2cc3ccd3c6a1474cb7209b53ebfd91077b
Signed-off-by: Martijn Coenen <maco@android.com>
Add support for FunctionFS (ffs) to implement usb functions in userspace.
The aliases property stores the list of functions that are implemented
using functionfs.
For example:
echo "adb,mtp" > /sys/class/android_usb/android0/f_ffs/aliases
Then when the function are enabled:
echo "adb,acm" > /sys/class/android_usb/android0/functions
Internally, ffs and acm will be used.
Change-Id: I44117b183d48a5a99ddbee3ef2cf8998be74598e
Signed-off-by: Benoit Goby <benoit@android.com>
If f_fs.c and u_serial.c are combined together using #include, which has
been a common practice so far, the pr_vdebug macro is defined multiple
times. Define it only once.
Change-Id: I370ef5efb4ceb81abcc4876536220d570107cc14
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit e5248a111b upstream.
Prevent automatic system suspend from happening during system
shutdown by making try_to_suspend() check system_state and return
immediately if it is not SYSTEM_RUNNING.
This prevents the following breakage from happening (scenario from
Zhang Yanmin):
Kernel starts shutdown and calls all device driver's shutdown
callback. When a driver's shutdown is called, the last wakelock is
released and suspend-to-ram starts. However, as some driver's shut
down callbacks already shut down devices and disabled runtime pm,
the suspend-to-ram calls driver's suspend callback without noticing
that device is already off and causes crash.
Change-Id: I09261fe136713cb6bdd66e061a9e886d077324c5
[rjw: Changelog]
Signed-off-by: Liu ShuoX <shuox.liu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 426b7d5074424aab388af948ba75a5e1c8b9a702)
There is a possibility that a wakeup source event is received after
the device prepares to suspend which might cause the suspend to abort.
This patch adds the functionality of reporting the last active wakeup
source which is currently not active but caused the suspend to abort reason
via the /sys/kernel/power/last_wakeup_reason file.
Change-Id: I1760d462f497b33e425f5565cb6cff5973932ec3
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
From left to right:
1. Amount of no-wait cycles
2. Amount of timeout cycles
3. Max waiting time in ms
Change-Id: Ibc0bb1c4ea591d005cdbb095b6d21c0734d2eb8b
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
In 80% cases there is no need to wait, and in case
of timeout we continue to resume.
Change-Id: I6ae44e0ef6f7aa497f57fcd5f6e6bc83dc781852
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Suspend is aborted if the wakeup_source is pending. These wakeup sources
are checked multiple times before going to suspend. If it is found to be
pending then suspend is aborted and -EBUSY is returned. This happens at
all the places except the last time they are checked. In this case
suspend is aborted but the error is not set. Since the error is not
propogated the suspend accounting considers this as a sucessful suspend
instead of suspend abort.
Change-Id: Ib63b4ead755127eaf03e3b303aab3c782ad02ed1
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
Introduce a config item, CONFIG_DEDUCE_WAKEUP_REASONS, disabled by default.
Make CONFIG_PARTUALRESUME select it.
Change-Id: I7d831ff0a9dfe0a504824f4bc65ba55c4d92546b
Signed-off-by: Iliyan Malchev <malchev@google.com>
log_possible_wakeup_reason() and stop_logging_wakeup_reasons() can race, as the
latter can be called from process context, and both can run on separate cores.
Change-Id: I306441d0be46dd4fe58c55cdc162f9d61a28c27d
Signed-off-by: Iliyan Malchev <malchev@google.com>
This node exports five values separated by space.
From left to right:
1. Amount of suspend/resume cycles
2. Amount of suspend abort cycles
3. Total time spent in suspend/resume process
4. Total time in suspend abort process
5. Total time spent sleep in suspend state
Change-Id: Ife188fd8386dce35f95fa7ba09fbc9d7e152db62
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
The old platform suspend_again callback overrides drivers' votes, such that if
it implemented and returns false, then we do not call the partialresume
handlers. When it doesn't exists or returns true, then we also query the
registered drivers for consensus.
When a device resumes from suspend, the suspend/resume code invokes
partialresume to check to see if the set of wakeup interrupts all have matching
handlers. If this is not the case, the PM subsystem can continue to resume as
before. If all of the wakeup sources have matching handlers, then those are
invoked in turn (and can block), and if all of them reach consensus that the
reason for the wakeup can be ignored, they say so to the PM subsystem, which
goes right back into suspend.
Signed-off-by: Iliyan Malchev <malchev@google.com>
Change-Id: Iaeb9ed78c4b5fb815c6e9c701233e703f481f962
Partial resume refers to the concept of not waking up userspace when the kernel
comes out of suspend for certain types of events that we wish to discard. An
example is a network packet that can be disacarded in the kernel, or spurious
wakeup event that we wish to ignore. Partial resume allows drivers to register
callbacks, one one hand, and provides hooks into the PM's suspend/resume
mechanism, on the other.
When a device resumes from suspend, the core suspend/resume code invokes
partialresume to check to see if the set of wakeup interrupts all have
matching handlers. If this is not the case, the PM subsystem can continue to
resume as before. If all of the wakeup sources have matching handlers, then
those are invoked in turn (and can block), and if all of them reach consensus
that the reason for the wakeup can be ignored, they say so to the PM subsystem,
which goes right back into suspend. This latter support is implemented in a
separate change.
Signed-off-by: Iliyan Malchev <malchev@google.com>
Change-Id: Id50940bb22a550b413412264508d259f7121d442
The wakeup_reason driver works by having a callback log_wakeup_reason(), be
called by the resume path once for each wakeup interrupt, with the irq number
as argument. It then saves this interrupt in an array, and reports it when
requested (via /sys/kernel/wakeup_reasons/last_resume_reason) and also prints
the information out in kmsg.
This approach works, but it has the deficiency that often the reported wakeup
interrupt, while correct, is not the interrupt truly responsible for the
wakeup. The reason for this is due to chained interrupt controllers (whether
in hardware or simulated in software). It could be, for example, that the
power button is wired to a GPIO handled by a single interrupt for all GPIOs,
which interrupt then determines the GPIO and maps this to a software interrupt.
Whether this is done in software, or by chaining interrupt controllers, the end
result is that the wakeup reason will show not the interrupt associated with
the power button, but the base-GPIO interrupt instead.
This patch reworks the wakeup_sources driver such that it reports those final
interrupts we are interested in, and not the intermediate (and not the base)
ones. It does so as follows:
-- The assumption is that generic_handle_irq() is called to dispatch all
interrupts; due to this, chained interrupts result in recursive calls of
generic_handle_irq().
-- We reconstruct the chains of interrupts that originate with the base wakeup
interrupt and terminate with the interrupt we are interested in by tracing
the calls to generic_handle_irq()
-- The tracing works by maitaining a per-cpu counter that is incremented with
each call to generic_handle_irq(); that counter is reported to the
wakeup_sources driver by a pair of functions, called
log_possible_wakeup_reason_start() and log_possible_wakeup_reason_complete().
The former is called before generic_handle_irq() handles the interrupt
(thereby potentially calling itself recusively) and the latter afterward.
-- The two functions mentioned above are complemented by log_base_wake_reason()
(renamed from log_wakeup_reason()), which is used to report the base wakeup
interrupts to the wakeup_reason driver.
-- The three functions work together to build a set of trees, one per base
wakeup reason, the leaves of which correspond to the interrupts we are
interesed in; these trees can be arbitratily complex, though in reality they
most often are a single node, or a chain of two nodes. The complexity
supports arbitrarily involved interrupt dispatch.
-- On resume, we build the tree; once the tree is completed, we walk it
recursively, and print out to kmesg the (more useful) list of wakeup
sources; simiarly, we walk the tree and print the leaves when
/sys/kernel/wakeup_reasons/last_resume_reason is read.
Signed-off-by: Iliyan Malchev <malchev@google.com>
Change-Id: If8acb2951b61d2c6bcf4d011fe04d7f91057d139
Alter the signature of irq_flow_handler_t to return true for those interrupts
whose handlers were invoked, and false otherwise. Also rework the actual
handlers, handle_.*_irq, to support the new signature.
Change-Id: I8a50410c477692bbcd39a0fefdac14253602d1f5
Signed-off-by: Iliyan Malchev <malchev@google.com>
Wakeup reason is set before driver resume handlers are called.
It is cleared before driver suspend handlers are called, on
PM_SUSPEND_PREPARE.
Change-Id: I04218c9b0c115a7877e8029c73e6679ff82e0aa4
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Signed-off-by: Iliyan Malchev <malchev@google.com>
Extends the last_resume_reason to log suspend abort reason. The abort
reasons will have "Abort:" appended at the start to distinguish itself
from the resume reason.
Change-Id: Id3c62fc0cb86ca2e05a69e40de040b94f32be389
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
Signed-off-by: Iliyan Malchev <malchev@google.com>
Extends the last_resume_reason to log suspend abort reason. The abort
reasons will have "Abort:" appended at the start to distinguish itself
from the resume reason.
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
Signed-off-by: Iliyan Malchev <malchev@google.com>
Change-Id: I3207f1844e3d87c706dfc298fb10e1c648814c5f
The query results are valid until the next PM_SUSPEND_PREPARE.
Change-Id: I6bc2bd47c830262319576a001d39ac9a994916cf
Signed-off-by: Iliyan Malchev <malchev@google.com>
This node epxorts two values separated by space.
From left to right:
1. time spent in suspend/resume process
2. time spent sleep in suspend state
Change-Id: I2cb9a9408a5fd12166aaec11b935a0fd6a408c63
Ensure the array for the wakeup reason IRQs does not overflow.
Change-Id: Iddc57a3aeb1888f39d4e7b004164611803a4d37c
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
Use rcu to free objects in wakeup_source_unregister(). These objects must
be allocated through wakeup_source_register().
Replacing synchronize_rcu() with call_rcu() allows multiple calls to
wakeup_source_unregister() to be combined into a single grace period.
CRs-Fixed: 845110
Change-Id: Ib4002db042cf63abb28e6b3df6e3c70c97043bd9
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
A driver or app may repeatedly request a wakeup source while the system
is attempting to enter suspend, which may indicate a bug or at least
point out a highly active system component that is responsible for
decreased battery life on a mobile device. Even when the incidence
of suspend abort is not severe, identifying wakeup sources that
frequently abort suspend can be a useful clue for power management
analysis.
In some cases the existing stats can point out the offender where there is
an unexpectedly high activation count that stands out from the others, but
in other cases the wakeup source frequently taken just after the rest of
the system thinks its time to suspend might not stand out in the overall
stats.
It is also often useful to have information about what's been happening
recently, rather than totals of all activity for the system boot.
It's suggested to dump a line about which wakeup source
aborted suspend to aid analysis of these situations.
Change-Id: Ie40356c0755d6898737d9415a367812f17a7532e
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
When legacy wakelock code was removed in commit
f85607a715a74c65db812cd3901022888257f966, some of the code
for moving calls to sys_sync() from suspend paths into a
workqueue item had not been properly removed. Specifically,
one of the call sites to suspend_sys_sync_wait() has been
mistakenly replaced with a call to sys_sync(), which is not
necessary because the corresponding instance of
suspend_sys_sync_queue() was already replaced with
sys_sync(). Clean up the remnants of the legacy wakelock
code by removing the extraneous call to sys_sync() and
restoring some of the surrounding printk statements that
had been moved to suspend_sys_sync_queue() and subsequently
lost.
CRs-Fixed: 498669
Change-Id: Ifb2ede7808560f456c824d3d6359a4541c51b73f
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
The condition check in autosleep_store() is incorrect and prevents
/sys/power/autosleep from working as advertised. Fix that.
[rjw: Added the changelog.]
Change-Id: I231cc24fc3f245003dcf5053ff6a71eb69ffa273
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Git-commit: 040e5bf65e
Git-repo: git://codeaurora.org/kernel/msm.git
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
Add conditional compilation for touch event sysfs nodes. Otherwise,
if CONFIG_PM_SLEEP is not defined, there could be compilation errors.
Change-Id: I1ac7f284ec35eae2cfa076ef8e71c29ddc24817c
Signed-off-by: Amar Singhal <asinghal@codeaurora.org>
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
Make it possible to configure out the user space wakeup sources
garbage collector for debugging and default Android builds.
Change-Id: I85ca6caa92c8e82d863f0fa58d8861b5571c1b4a
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Arve Hjønnevåg <arve@android.com>
Git-commit: 4e585d25e1
Git-repo: git://codeaurora.org/kernel/msm.git
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
Make it possible to configure out the check against the limit of
user space wakeup sources for debugging and default Android builds.
Change-Id: I8f74d7c8391627df970d2df666938069b012e2fe
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Arve Hjønnevåg <arve@android.com>
Git-commit: c73893e2ca
Git-repo: git://codeaurora.org/kernel/msm.git
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
The config options HAS_WAKELOCK and WAKELOCK are
not needed any more since a wakeup sources-based
wakelock implementation will be used.
Change-Id: I4163f048c079ec3d10a02d9db16c3ca6fb5fd759
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
Android allows user space to manipulate wakelocks using two
sysfs file located in /sys/power/, wake_lock and wake_unlock.
Writing a wakelock name and optionally a timeout to the wake_lock
file causes the wakelock whose name was written to be acquired (it
is created before is necessary), optionally with the given timeout.
Writing the name of a wakelock to wake_unlock causes that wakelock
to be released.
Implement an analogous interface for user space using wakeup sources.
Add the /sys/power/wake_lock and /sys/power/wake_unlock files
allowing user space to create, activate and deactivate wakeup
sources, such that writing a name and optionally a timeout to
wake_lock causes the wakeup source of that name to be activated,
optionally with the given timeout. If that wakeup source doesn't
exist, it will be created and then activated. Writing a name to
wake_unlock causes the wakeup source of that name, if there is one,
to be deactivated. Wakeup sources created with the help of
wake_lock that haven't been used for more than 5 minutes are garbage
collected and destroyed. Moreover, there can be only WL_NUMBER_LIMIT
wakeup sources created with the help of wake_lock present at a time.
The data type used to track wakeup sources created by user space is
called "struct wakelock" to indicate the origins of this feature.
This version of the patch includes an rbtree manipulation fix from John Stultz.
Change-Id: Icb452cfd54362b49dcb1cff88345928a2528ad97
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NeilBrown <neilb@suse.de>
Git-commit: b86ff9820f
Git-repo: git://codeaurora.org/kernel/msm.git
[anursing@codeaurora.org: replace existing implementation, resolve
merge conflicts]
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
Android uses one wakelock statistics that is only necessary for
opportunistic sleep. Namely, the prevent_suspend_time field
accumulates the total time the given wakelock has been locked
while "automatic suspend" was enabled. Add an analogous field,
prevent_sleep_time, to wakeup sources and make it behave in a similar
way.
Change-Id: I4b9719d05da020757d7cc21ed3b52b7c32261bea
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-commit: 55850945e8
Git-repo: git://codeaurora.org/kernel/msm.git
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
Introduce a mechanism by which the kernel can trigger global
transitions to a sleep state chosen by user space if there are no
active wakeup sources.
It consists of a new sysfs attribute, /sys/power/autosleep, that
can be written one of the strings returned by reads from
/sys/power/state, an ordered workqueue and a work item carrying out
the "suspend" operations. If a string representing the system's
sleep state is written to /sys/power/autosleep, the work item
triggering transitions to that state is queued up and it requeues
itself after every execution until user space writes "off" to
/sys/power/autosleep.
That work item enables the detection of wakeup events using the
functions already defined in drivers/base/power/wakeup.c (with one
small modification) and calls either pm_suspend(), or hibernate() to
put the system into a sleep state. If a wakeup event is reported
while the transition is in progress, it will abort the transition and
the "system suspend" work item will be queued up again.
Change-Id: Ic3214de009c64feab606e93811bd442ccfc49d86
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NeilBrown <neilb@suse.de>
Git-commit: 7483b4a4d9
Git-repo: git://codeaurora.org/kernel/msm.git
[anursing@codeaurora.org: replace existing implementation, resolve
merge conflicts]
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
