* acpi-pm:
  ACPI / PM: Export rest of the subsys PM callbacks
  ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspend
  ACPI / PM: Hold ACPI scan lock over the "freeze" sleep state
  ACPI / PM: Export acpi_target_system_state() to modules

* acpi-battery:
  ACPI / battery: wakeup the system only when necessary
  power_supply: allow power supply devices registered w/o wakeup source
  ACPI / battery: introduce support for POWER_SUPPLY_PROP_CAPACITY_LEVEL
  ACPI / battery: Accelerate battery resume callback

* pm-sleep:
  PM / hibernate: fixed typo in comment
  PM / sleep: unregister wakeup source when disabling device wakeup
  PM / sleep: Introduce command line argument for sleep state enumeration
  PM / sleep: Use valid_state() for platform-dependent sleep states only
  PM / sleep: Add state field to pm_states[] entries
  PM / sleep: Update device PM documentation to cover direct_complete
  PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily
  PM / hibernate: Fix memory corruption in resumedelay_setup()
  PM / hibernate: convert simple_strtoul to kstrtoul
  PM / hibernate: Documentation: Fix script for unswapping
  PM / hibernate: no kernel_power_off when pm_power_off NULL
  PM / hibernate: use unsigned local variables in swsusp_show_speed()

* pm-cpuidle:
  PM / suspend: Always use deepest C-state in the "freeze" sleep state
  cpuidle / menu: move repeated correction factor check to init
  cpuidle / menu: Return (-1) if there are no suitable states
  cpuidle: Combine cpuidle_enabled() with cpuidle_select()
  ARM: clps711x: Add cpuidle driver

* acpi-tables:
  ACPI: Fix conflict between customized DSDT and DSDT local copy

* acpi-general:
  ACPI: Add acpi_bus_attach_private_data() to attach data to ACPI handle

* acpi-processor:
  ACPI / processor: Fix STARTING/DYING action in acpi_cpu_soft_notify()
  ACPI / processor: Check if LAPIC is present during initialization
  ACPI / ia64: introduce variable acpi_lapic into ia64

* acpi-pad:
  ACPI / PAD: Use time_before() for time comparison
  ACPI / PAD: call schedule() when need_resched() is true

* acpi-scan:
  ACPI / scan: do not scan fixed hardware on HW-reduced platform

* acpi-hotplug:
  ACPI: add dynamic_debug support
  ACPI / notify: Clean up handling of hotplug events

* acpi-pci:
  ACPI / PCI: Stub out pci_acpi_crs_quirks() and make it x86 specific

This change makes the busy calculation using 64 bit math which prevents
overflow for large values of aperf/mperf.

Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Doug Smythies <dsmythies@telus.net>
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The PID assumes that samples are of equal time, which for a deferable
timers this is not true when the system goes idle.  This causes the
PID to take a long time to converge to the min P state and depending
on the pattern of the idle load can make the P state appear stuck.

The hold-off value of three sample times before using the scaling is
to give a grace period for applications that have high performance
requirements and spend a lot of time idle,  The poster child for this
behavior is the ffmpeg benchmark in the Phoronix test suite.

Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Changing to fixed point math throughout the busy calculation in
commit e66c1768 (Change busy calculation to use fixed point
math.) Introduced some inaccuracies by rounding the busy value at two
points in the calculation.  This change removes roundings and moves
the rounding to the output of the PID where the calculations are
complete and the value returned as an integer.

Fixes: e66c1768 (intel_pstate: Change busy calculation to use fixed point math.)
Reported-by: Doug Smythies <dsmythies@telus.net>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit fcb6a15c (intel_pstate: Take core C0 time into account for core
busy calculation) introduced a regression referenced below.  The issue
with "lockup" after suspend that this commit was addressing is now dealt
with in the suspend path.

Fixes: fcb6a15c (intel_pstate: Take core C0 time into account for core busy calculation)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=66581
Link: https://bugzilla.kernel.org/show_bug.cgi?id=75121Reported-by: Doug Smythies <dsmythies@telus.net>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Pull powerpc fix from Ben Herrenschmidt:
 "Here's just one trivial patch to wire up sys_renameat2 which I seem to
  have completely missed so far.

  (My test build scripts fwd me warnings but miss the ones generated for
  missing syscalls)"

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
  powerpc: Wire renameat2() syscall

Pull MIPS fixes from Ralf Baechle:
 "A fair number of fixes across the field.  Nothing terribly
  complicated; the one liners in below changelog should be fairly
  descriptive.

  Noteworthy is the SB1 change which the result of changes to binutils
  resulting in one big gas warning for most files being assembled as
  well as the asid_cache and branch emulation fixes which fix corruption
  or possible uninteded behaviour of kernel or application code.  The
  remainder of fixes are more platforms or subsystem specific"

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  MIPS: R46000: Fix Micro-assembler field overflow for R4600 V2
  MIPS: ptrace: Avoid smp_processor_id() in preemptible code
  MIPS: Lemote 2F: cs5536: mfgpt: use raw locks
  MIPS: SB1: Fix excessive kernel warnings.
  MIPS: RC32434: fix broken PCI resource initialization
  MIPS: malta: memory.c: Initialize the 'memsize' variable
  MIPS: Fix typo when reporting cache and ftlb errors for ImgTec cores
  MIPS: Fix inconsistancy of __NR_Linux_syscalls value
  MIPS: Fix branch emulation of branch likely instructions.
  MIPS: Fix a typo error in AUDIT_ARCH definition
  MIPS: Change type of asid_cache to unsigned long

Pull scheduler fixes from Ingo Molnar:
 "Various fixlets, mostly related to the (root-only) SCHED_DEADLINE
  policy, but also a hotplug bug fix and a fix for a NR_CPUS related
  overallocation bug causing a suspend/resume regression"

* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched: Fix hotplug vs. set_cpus_allowed_ptr()
  sched/cpupri: Replace NR_CPUS arrays
  sched/deadline: Replace NR_CPUS arrays
  sched/deadline: Restrict user params max value to 2^63 ns
  sched/deadline: Change sched_getparam() behaviour vs SCHED_DEADLINE
  sched: Disallow sched_attr::sched_policy < 0
  sched: Make sched_setattr() correctly return -EFBIG

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Fix a trivial comment typo (s/mam/map) in kernel/power/swap.c.
Signed-off-by: Niv Yehezkel <executerx@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Pull core futex/rtmutex fixes from Thomas Gleixner:
 "Three fixlets for long standing issues in the futex/rtmutex code
  unearthed by Dave Jones syscall fuzzer:

   - Add missing early deadlock detection checks in the futex code
   - Prevent user space from attaching a futex to kernel threads
   - Make the deadlock detector of rtmutex work again

  Looks large, but is more comments than code change"

* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  rtmutex: Fix deadlock detector for real
  futex: Prevent attaching to kernel threads
  futex: Add another early deadlock detection check

Pull drm fixes from Dave Airlie:
 "Mostly quiet now:

  i915:
    fixing userspace visiblie issues, all stable marked

  radeon:
    one more pll fix, two crashers, one suspend/resume regression"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/radeon: Resume fbcon last
  drm/radeon: only allocate necessary size for vm bo list
  drm/radeon: don't allow RADEON_GEM_DOMAIN_CPU for command submission
  drm/radeon: avoid crash if VM command submission isn't available
  drm/radeon: lower the ref * post PLL maximum once more
  drm/i915: Prevent negative relocation deltas from wrapping
  drm/i915: Only copy back the modified fields to userspace from execbuffer
  drm/i915: Fix dynamic allocation of physical handles

lock_parent() very much on purpose does nested locking of dentries, and
is careful to maintain the right order (lock parent first).  But because
it didn't annotate the nested locking order, lockdep thought it might be
a deadlock on d_lock, and complained.

Add the proper annotation for the inner locking of the child dentry to
make lockdep happy.

Introduced by commit 046b961b ("shrink_dentry_list(): take parent's
->d_lock earlier").
Reported-and-tested-by: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

So a few people complained that

commit 177cf92d
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Apr 1 22:14:59 2014 +0200

    drm/crtc-helpers: fix dpms on logic

which was merged into 3.15-rc1, broke resume on radeons. Strangely git
bisect lead everyone to

commit 25f397a4
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Jul 19 18:57:11 2013 +0200

    drm/crtc-helper: explicit DPMS on after modeset

which was merged long ago and actually part of 3.14.

Digging deeper I've noticed (again) that the call to
drm_helper_resume_force_mode in the radeon resume handlers was a no-op
previously because everything gets shut down on suspend. radeon does
this with explicit calls to drm_helper_connector_dpms with DPMS_OFF.
But with 177c we now force the dpms state to ON, so suddenly
resume_force_mode actually forced the crtcs back on.

This is the intention of the change after all, the problem is that
radeon resumes the fbdev console layer _before_ restoring the display,
through calling fb_set_suspend. And fbcon does an immediate ->set_par,
which in turn causes the same forced mode restore to happen.

Two concurrent modeset operations didn't lead to happiness. Fix this
by delaying the fbcon resume until the end of the readeon resum
functions.

v2: Fix up a bit of the spelling fail.

References: https://lkml.org/lkml/2014/5/29/1043
References: https://lkml.org/lkml/2014/5/2/388
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74751Tested-by: Ken Moffat <zarniwhoop@ntlworld.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Ken Moffat <zarniwhoop@ntlworld.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>

this is the next pull request for stashed up radeon fixes for 3.15. This is finally calming down with only four patches in this pull request.

* 'drm-fixes-3.15' of git://people.freedesktop.org/~deathsimple/linux:
  drm/radeon: only allocate necessary size for vm bo list
  drm/radeon: don't allow RADEON_GEM_DOMAIN_CPU for command submission
  drm/radeon: avoid crash if VM command submission isn't available
  drm/radeon: lower the ref * post PLL maximum once more

Pull input subsystem fixes from Dmitry Torokhov:
 "A couple of driver/build fixups and also redone quirk for Synaptics
  touchpads on Lenovo boxes (now using PNP IDs instead of DMI data to
  limit number of quirks)"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: synaptics - change min/max quirk table to pnp-id matching
  Input: synaptics - add a matches_pnp_id helper function
  Input: synaptics - T540p - unify with other LEN0034 models
  Input: synaptics - add min/max quirk for the ThinkPad W540
  Input: ambakmi - request a shared interrupt for AMBA KMI devices
  Input: pxa27x-keypad - fix generating scancode
  Input: atmel-wm97xx - only build for AVR32
  Input: fix ps2/serio module dependency

Pull firewire fix from Stefan Richter:
 "A regression fix for the IEEE 1394 subsystem: re-enable IRQ-based
  asynchronous request reception at addresses below 128 TB"

* tag 'firewire-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
  firewire: revert to 4 GB RDMA, fix protocols using Memory Space

Pull device-mapper fixes from Mike Snitzer:
 "A dm-cache stable fix to split discards on cache block boundaries
  because dm-cache cannot yet handle discards that span cache blocks.

  Really fix a dm-mpath LOCKDEP warning that was introduced in -rc1.

  Add a 'no_space_timeout' control to dm-thinp to restore the ability to
  queue IO indefinitely when no data space is available.  This fixes a
  change in behavior that was introduced in -rc6 where the timeout
  couldn't be disabled"

* tag 'dm-3.15-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
  dm mpath: really fix lockdep warning
  dm cache: always split discards on cache block boundaries
  dm thin: add 'no_space_timeout' dm-thin-pool module param

While I play inhouse patches with much memory pressure on qemu-kvm,
3.14 kernel was randomly crashed. The reason was kernel stack overflow.

When I investigated the problem, the callstack was a little bit deeper
by involve with reclaim functions but not direct reclaim path.

I tried to diet stack size of some functions related with alloc/reclaim
so did a hundred of byte but overflow was't disappeard so that I encounter
overflow by another deeper callstack on reclaim/allocator path.

Of course, we might sweep every sites we have found for reducing
stack usage but I'm not sure how long it saves the world(surely,
lots of developer start to add nice features which will use stack
agains) and if we consider another more complex feature in I/O layer
and/or reclaim path, it might be better to increase stack size(
meanwhile, stack usage on 64bit machine was doubled compared to 32bit
while it have sticked to 8K. Hmm, it's not a fair to me and arm64
already expaned to 16K. )

So, my stupid idea is just let's expand stack size and keep an eye
toward stack consumption on each kernel functions via stacktrace of ftrace.
For example, we can have a bar like that each funcion shouldn't exceed 200K
and emit the warning when some function consumes more in runtime.
Of course, it could make false positive but at least, it could make a
chance to think over it.

I guess this topic was discussed several time so there might be
strong reason not to increase kernel stack size on x86_64, for me not
knowing so Ccing x86_64 maintainers, other MM guys and virtio
maintainers.

Here's an example call trace using up the kernel stack:

         Depth    Size   Location    (51 entries)
         -----    ----   --------
   0)     7696      16   lookup_address
   1)     7680      16   _lookup_address_cpa.isra.3
   2)     7664      24   __change_page_attr_set_clr
   3)     7640     392   kernel_map_pages
   4)     7248     256   get_page_from_freelist
   5)     6992     352   __alloc_pages_nodemask
   6)     6640       8   alloc_pages_current
   7)     6632     168   new_slab
   8)     6464       8   __slab_alloc
   9)     6456      80   __kmalloc
  10)     6376     376   vring_add_indirect
  11)     6000     144   virtqueue_add_sgs
  12)     5856     288   __virtblk_add_req
  13)     5568      96   virtio_queue_rq
  14)     5472     128   __blk_mq_run_hw_queue
  15)     5344      16   blk_mq_run_hw_queue
  16)     5328      96   blk_mq_insert_requests
  17)     5232     112   blk_mq_flush_plug_list
  18)     5120     112   blk_flush_plug_list
  19)     5008      64   io_schedule_timeout
  20)     4944     128   mempool_alloc
  21)     4816      96   bio_alloc_bioset
  22)     4720      48   get_swap_bio
  23)     4672     160   __swap_writepage
  24)     4512      32   swap_writepage
  25)     4480     320   shrink_page_list
  26)     4160     208   shrink_inactive_list
  27)     3952     304   shrink_lruvec
  28)     3648      80   shrink_zone
  29)     3568     128   do_try_to_free_pages
  30)     3440     208   try_to_free_pages
  31)     3232     352   __alloc_pages_nodemask
  32)     2880       8   alloc_pages_current
  33)     2872     200   __page_cache_alloc
  34)     2672      80   find_or_create_page
  35)     2592      80   ext4_mb_load_buddy
  36)     2512     176   ext4_mb_regular_allocator
  37)     2336     128   ext4_mb_new_blocks
  38)     2208     256   ext4_ext_map_blocks
  39)     1952     160   ext4_map_blocks
  40)     1792     384   ext4_writepages
  41)     1408      16   do_writepages
  42)     1392      96   __writeback_single_inode
  43)     1296     176   writeback_sb_inodes
  44)     1120      80   __writeback_inodes_wb
  45)     1040     160   wb_writeback
  46)      880     208   bdi_writeback_workfn
  47)      672     144   process_one_work
  48)      528     112   worker_thread
  49)      416     240   kthread
  50)      176     176   ret_from_fork

[ Note: the problem is exacerbated by certain gcc versions that seem to
  generate much bigger stack frames due to apparently bad coalescing of
  temporaries and generating too many spills.  Rusty saw gcc-4.6.4 using
  35% more stack on the virtio path than 4.8.2 does, for example.

  Minchan not only uses such a bad gcc version (4.6.3 in his case), but
  some of the stack use is due to debugging (CONFIG_DEBUG_PAGEALLOC is
  what causes that kernel_map_pages() frame, for example). But we're
  clearly getting too close.

  The VM code also seems to have excessive stack frames partly for the
  same compiler reason, triggered by excessive inlining and lots of
  function arguments.

  We need to improve on our stack use, but in the meantime let's do this
  simple stack increase too.  Unlike most earlier reports, there is
  nothing simple that stands out as being really horribly wrong here,
  apart from the fact that the stack frames are just bigger than they
  should need to be.        - Linus ]
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Peter Anvin <hpa@zytor.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Rik van Riel <riel@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Michael S Tsirkin <mst@redhat.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: PJ Waskiewicz <pjwaskiewicz@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Pull vfs dcache livelock fix from Al Viro:
 "Fixes for livelocks in shrink_dentry_list() introduced by fixes to
  shrink list corruption; the root cause was that trylock of parent's
  ->d_lock could be disrupted by d_walk() happening on other CPUs,
  resulting in shrink_dentry_list() making no progress *and* the same
  d_walk() being called again and again for as long as
  shrink_dentry_list() doesn't get past that mess.

  The solution is to have shrink_dentry_list() treat that trylock
  failure not as 'try to do the same thing again', but 'lock them in the
  right order'"

* 'for-linus-2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  dentry_kill() doesn't need the second argument now
  dealing with the rest of shrink_dentry_list() livelock
  shrink_dentry_list(): take parent's ->d_lock earlier
  expand dentry_kill(dentry, 0) in shrink_dentry_list()
  split dentry_kill()
  lift the "already marked killed" case into shrink_dentry_list()

it's 1 in the only remaining caller.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

We have the same problem with ->d_lock order in the inner loop, where
we are dropping references to ancestors.  Same solution, basically -
instead of using dentry_kill() we use lock_parent() (introduced in the
previous commit) to get that lock in a safe way, recheck ->d_count
(in case if lock_parent() has ended up dropping and retaking ->d_lock
and somebody managed to grab a reference during that window), trylock
the inode->i_lock and use __dentry_kill() to do the rest.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

The cause of livelocks there is that we are taking ->d_lock on
dentry and its parent in the wrong order, forcing us to use
trylock on the parent's one.  d_walk() takes them in the right
order, and unfortunately it's not hard to create a situation
when shrink_dentry_list() can't make progress since trylock
keeps failing, and shrink_dcache_parent() or check_submounts_and_drop()
keeps calling d_walk() disrupting the very shrink_dentry_list() it's
waiting for.

Solution is straightforward - if that trylock fails, let's unlock
the dentry itself and take locks in the right order.  We need to
stabilize ->d_parent without holding ->d_lock, but that's doable
using RCU.  And we'd better do that in the very beginning of the
loop in shrink_dentry_list(), since the checks on refcount, etc.
would need to be redone anyway.

That deals with a half of the problem - killing dentries on the
shrink list itself.  Another one (dropping their parents) is
in the next commit.

locking parent is interesting - it would be easy to do rcu_read_lock(),
lock whatever we think is a parent, lock dentry itself and check
if the parent is still the right one.  Except that we need to check
that *before* locking the dentry, or we are risking taking ->d_lock
out of order.  Fortunately, once the D1 is locked, we can check if
D2->d_parent is equal to D1 without the need to lock D2; D2->d_parent
can start or stop pointing to D1 only under D1->d_lock, so taking
D1->d_lock is enough.  In other words, the right solution is
rcu_read_lock/lock what looks like parent right now/check if it's
still our parent/rcu_read_unlock/lock the child.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

No need to always allocate the theoretical maximum here.
Signed-off-by: Christian König <christian.koenig@amd.com>

It hangs the hardware.
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org

Signed-off-by: Christian König <christian.koenig@amd.com>
CC: stable@vger.kernel.org

Let's be conservative and use 100 here until we find something better.

Bugs: https://bugzilla.kernel.org/show_bug.cgi?id=75241Signed-off-by: Christian König <christian.koenig@amd.com>

ACPI Battery device receives notifications from firmware frequently,
and most of these notifications are some general events, like battery
remaining capacity change, etc, which should not wake the system up
if the system is in suspend/hibernate state.

This causes a problem that the system wakes up from suspend to freeze
shortly, because there is an ACPI battery notification every 10 seconds.

Fix the problem in this patch by registering ACPI battery device'
own wakeup source, and waking up the system only when the battery remaining
capacity is critical low, or lower than the alarm capacity set via _BTP.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=76221Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Currently, all the power supply devices are registered with wakeup source,
this results in that every power_supply_changed() invocation brings
the system out of suspend-to-freeze state.

This is overkill as some device drivers, e.g. ACPI battery driver,
have the ability to check the device status and wake up the system
from sleeping only when necessary.

Thus introduce a new API which allows device to be registered
w/o wakeup source.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI battery device receives notifications when
1. the remaining battery capacity becomes critical low
2. the trip point set by the _BTP (Design capacity of Warning by default)
   is reached or crossed.

So it is able to support POWER_SUPPLY_PROP_CAPACITY_LEVEL to report
        POWER_SUPPLY_CAPACITY_LEVEL_CRITICAL,
        POWER_SUPPLY_CAPACITY_LEVEL_LOW,
        POWER_SUPPLY_CAPACITY_LEVEL_NORMAL,
        POWER_SUPPLY_CAPACITY_LEVEL_FULL,
capacity levels to power supply core and user space.

Introduce support for POWER_SUPPLY_PROP_CAPACITY_LEVEL in this patch.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

When enabling a device' wakeup capability, a wakeup source
is created for the device automatically. But the wakeup source
is not unregistered when disabling the device' wakeup capability.

This results in zombie wakeup sources, after devices/drivers are unregistered.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Pull ARM fixes from Russell King:
 "The usual random collection of relatively small ARM fixes"

* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
  ARM: 8063/1: bL_switcher: fix individual online status reporting of removed CPUs
  ARM: 8064/1: fix v7-M signal return
  ARM: 8057/1: amba: Add Qualcomm vendor ID.
  ARM: 8052/1: unwind: Fix handling of "Pop r4-r[4+nnn],r14" opcode
  ARM: 8051/1: put_user: fix possible data corruption in put_user
  ARM: 8048/1: fix v7-M setup stack location