02 Sep, 2014
1 commit
-
Always freeze processes when suspending and thaw processes when resuming
to prevent a race noticeable with HVM guests.This prevents a deadlock where the khubd kthread (which is designed to
be freezable) acquires a usb device lock and then tries to allocate
memory which requires the disk which hasn't been resumed yet.
Meanwhile, the xenwatch thread deadlocks waiting for the usb device
lock.Freezing processes fixes this because the khubd thread is only thawed
after the xenwatch thread finishes resuming all the devices.Signed-off-by: Ross Lagerwall
Signed-off-by: David Vrabel
Cc: stable@vger.kernel.org
03 Jul, 2014
1 commit
-
Calling xen_console_resume() in xen_suspend() causes a warning because
it locks irq_mapping_update_lock (a mutex) and this may sleep. If a
userspace process is using the evtchn device then this mutex may be
locked at the point of the stop_machine() call and
xen_console_resume() would then deadlock.Resuming the console after stop_machine() returns avoids this
deadlock.Signed-off-by: David Vrabel
Reviewed-by: Boris Ostrovsky
Cc:
13 May, 2014
1 commit
-
New architectures currently have to provide implementations of 5 different
functions: xen_arch_pre_suspend(), xen_arch_post_suspend(),
xen_arch_hvm_post_suspend(), xen_mm_pin_all(), and xen_mm_unpin_all().Refactor the suspend code to only require xen_arch_pre_suspend() and
xen_arch_post_suspend().Signed-off-by: David Vrabel
Reviewed-by: Boris Ostrovsky
16 Apr, 2014
1 commit
-
The user can launch the guest in this sequence:
xl create -p /vm.cfg [launch, but pause it]
xl shutdown latest [sets control/shutdown=poweroff]
xl unpause latest
xl console latest [and see that the guest has completely
ignored the shutdown request]In reality the guest hasn't ignored it. It registers a watch
and gets a notification that there is value. It then calls
the shutdown_handler which ends up calling orderly_shutdown.Unfortunately that is so early in the bootup that there
are no user-space. Which means that the orderly_shutdown fails.
But since the force flag was set to false it continues on without
reporting.What we really want to is to use the force when we are in the
SYSTEM_BOOTING state and not use the 'force' when SYSTEM_RUNNING.However, if we are in the running state - and the shutdown command
has been given before the user-space has been setup, there is nothing
we can do. Worst yet, we stop ignoring the 'xl shutdown' requests!As such, the other part of this patch is to only stop ignoring
the 'xl shutdown' when we are truly in the power off sequence.That means the user can do multiple 'xl shutdown' and we will try
to act on them instead of ignoring them.Fixes-Bug: http://bugs.xenproject.org/xen/bug/6
Reported-by: Alex Bligh
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: David Vrabel
18 Mar, 2014
1 commit
-
syscore->resume() callback is expected to do not enable interrupts,
it generates warning like below otherwise:[ 9386.365390] WARNING: CPU: 0 PID: 6733 at drivers/base/syscore.c:104 syscore_resume+0x9a/0xe0()
[ 9386.365403] Interrupts enabled after xen_acpi_processor_resume+0x0/0x34 [xen_acpi_processor]
...
[ 9386.365429] Call Trace:
[ 9386.365434] [] dump_stack+0x45/0x56
[ 9386.365437] [] warn_slowpath_common+0x7d/0xa0
[ 9386.365439] [] warn_slowpath_fmt+0x4c/0x50
[ 9386.365442] [] ? xen_upload_processor_pm_data+0x300/0x300 [xen_acpi_processor]
[ 9386.365443] [] syscore_resume+0x9a/0xe0
[ 9386.365445] [] suspend_devices_and_enter+0x402/0x470
[ 9386.365447] [] pm_suspend+0x178/0x260On xen_acpi_processor_resume() we call various procedures, which are
non atomic and can enable interrupts. To prevent the issue introduce
separate resume notify called after we enable interrupts on resume
and before we call other drivers resume callbacks.Signed-off-by: Stanislaw Gruszka
Signed-off-by: Konrad Rzeszutek Wilk
07 Jul, 2013
1 commit
-
Pull timer core updates from Thomas Gleixner:
"The timer changes contain:- posix timer code consolidation and fixes for odd corner cases
- sched_clock implementation moved from ARM to core code to avoid
duplication by other architectures- alarm timer updates
- clocksource and clockevents unregistration facilities
- clocksource/events support for new hardware
- precise nanoseconds RTC readout (Xen feature)
- generic support for Xen suspend/resume oddities
- the usual lot of fixes and cleanups all over the place
The parts which touch other areas (ARM/XEN) have been coordinated with
the relevant maintainers. Though this results in an handful of
trivial to solve merge conflicts, which we preferred over nasty cross
tree merge dependencies.The patches which have been committed in the last few days are bug
fixes plus the posix timer lot. The latter was in akpms queue and
next for quite some time; they just got forgotten and Frederic
collected them last minute."* 'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (59 commits)
hrtimer: Remove unused variable
hrtimers: Move SMP function call to thread context
clocksource: Reselect clocksource when watchdog validated high-res capability
posix-cpu-timers: don't account cpu timer after stopped thread runtime accounting
posix_timers: fix racy timer delta caching on task exit
posix-timers: correctly get dying task time sample in posix_cpu_timer_schedule()
selftests: add basic posix timers selftests
posix_cpu_timers: consolidate expired timers check
posix_cpu_timers: consolidate timer list cleanups
posix_cpu_timer: consolidate expiry time type
tick: Sanitize broadcast control logic
tick: Prevent uncontrolled switch to oneshot mode
tick: Make oneshot broadcast robust vs. CPU offlining
x86: xen: Sync the CMOS RTC as well as the Xen wallclock
x86: xen: Sync the wallclock when the system time is set
timekeeping: Indicate that clock was set in the pvclock gtod notifier
timekeeping: Pass flags instead of multiple bools to timekeeping_update()
xen: Remove clock_was_set() call in the resume path
hrtimers: Support resuming with two or more CPUs online (but stopped)
timer: Fix jiffies wrap behavior of round_jiffies_common()
...
29 Jun, 2013
1 commit
-
commit 359cdd3f866(xen: maintain clock offset over save/restore) added
a clock_was_set() call into the xen resume code to propagate the
system time changes. With the modified hrtimer resume code, which
makes sure that all cpus are notified this call is not longer necessary.[ tglx: Separated it from the hrtimer change ]
Signed-off-by: David Vrabel
Cc: Konrad Rzeszutek Wilk
Cc: John Stultz
Cc:
Link: http://lkml.kernel.org/r/1372329348-20841-2-git-send-email-david.vrabel@citrix.com
Signed-off-by: Thomas Gleixner
28 Jun, 2013
2 commits
-
Convert printks to pr_ (excludes printk(KERN_DEBUG...)
to be more consistent throughout the xen subsystem.Add pr_fmt with KBUILD_MODNAME or "xen:" KBUILD_MODNAME
Coalesce formats and add missing word spaces
Add missing newlines
Align arguments and reflow to 80 columns
Remove DRV_NAME from formats as pr_fmt adds the same contentThis does change some of the prefixes of these messages
but it also does make them more consistent.Signed-off-by: Joe Perches
Signed-off-by: Konrad Rzeszutek Wilk -
xen_hvm_post_suspend, xen_pre_suspend, xen_post_suspend are only used if
CONFIG_HIBERNATE_CALLBACKS is defined, resulting in:drivers/xen/manage.c:46:13: warning: ‘xen_hvm_post_suspend’ defined but not used [-Wunused-function]
drivers/xen/manage.c:52:13: warning: ‘xen_pre_suspend’ defined but not used [-Wunused-function]
drivers/xen/manage.c:59:13: warning: ‘xen_post_suspend’ defined but not used [-Wunused-function]If the kernel config is missing CONFIG_HIBERNATE_CALLBACKS.
Simply ifdef CONFIG_HIBERNATE_CALLBACKS the three functions.
Signed-off-by: Stefano Stabellini
Signed-off-by: Konrad Rzeszutek Wilk
20 Apr, 2012
1 commit
-
linux/drivers/xen/manage.c: In function 'do_suspend':
linux/drivers/xen/manage.c:160:5: warning: 'si.cancelled' may be used uninitialized in this functionSigned-off-by: Konrad Rzeszutek Wilk
30 Jan, 2012
1 commit
-
The current device suspend/resume phases during system-wide power
transitions appear to be insufficient for some platforms that want
to use the same callback routines for saving device states and
related operations during runtime suspend/resume as well as during
system suspend/resume. In principle, they could point their
.suspend_noirq() and .resume_noirq() to the same callback routines
as their .runtime_suspend() and .runtime_resume(), respectively,
but at least some of them require device interrupts to be enabled
while the code in those routines is running.It also makes sense to have device suspend-resume callbacks that will
be executed with runtime PM disabled and with device interrupts
enabled in case someone needs to run some special code in that
context during system-wide power transitions.Apart from this, .suspend_noirq() and .resume_noirq() were introduced
as a workaround for drivers using shared interrupts and failing to
prevent their interrupt handlers from accessing suspended hardware.
It appears to be better not to use them for other porposes, or we may
have to deal with some serious confusion (which seems to be happening
already).For the above reasons, introduce new device suspend/resume phases,
"late suspend" and "early resume" (and analogously for hibernation)
whose callback will be executed with runtime PM disabled and with
device interrupts enabled and whose callback pointers generally may
point to runtime suspend/resume routines.Signed-off-by: Rafael J. Wysocki
Reviewed-by: Mark Brown
Reviewed-by: Kevin Hilman
01 Nov, 2011
1 commit
-
Things like THIS_MODULE and EXPORT_SYMBOL were simply everywhere
because module.h was also everywhere. But we are fixing the latter.
So we need to call out the real users in advance.Signed-off-by: Paul Gortmaker
12 May, 2011
1 commit
-
Since suspend, resume and shutdown operations in struct sysdev_class
and struct sysdev_driver are not used any more, remove them. Also
drop sysdev_suspend(), sysdev_resume() and sysdev_shutdown() used
for executing those operations and modify all of their users
accordingly. This reduces kernel code size quite a bit and reduces
its complexity.Signed-off-by: Rafael J. Wysocki
Acked-by: Greg Kroah-Hartman
20 Apr, 2011
1 commit
-
Device suspend/resume infrastructure is used not only by the suspend
and hibernate code in kernel/power, but also by APM, Xen and the
kexec jump feature. However, commit 40dc166cb5dddbd36aa4ad11c03915ea
(PM / Core: Introduce struct syscore_ops for core subsystems PM)
failed to add syscore_suspend() and syscore_resume() calls to that
code, which generally leads to breakage when the features in question
are used.To fix this problem, add the missing syscore_suspend() and
syscore_resume() calls to arch/x86/kernel/apm_32.c, kernel/kexec.c
and drivers/xen/manage.c.Signed-off-by: Rafael J. Wysocki
Acked-by: Greg Kroah-Hartman
Acked-by: Ian Campbell
12 Apr, 2011
1 commit
-
Xen save/restore is going to use hibernate device callbacks for
quiescing devices and putting them back to normal operations and it
would need to select CONFIG_HIBERNATION for this purpose. However,
that also would cause the hibernate interfaces for user space to be
enabled, which might confuse user space, because the Xen kernels
don't support hibernation. Moreover, it would be wasteful, as it
would make the Xen kernels include a substantial amount of code that
they would never use.To address this issue introduce new power management Kconfig option
CONFIG_HIBERNATE_CALLBACKS, such that it will only select the code
that is necessary for the hibernate device callbacks to work and make
CONFIG_HIBERNATION select it. Then, Xen save/restore will be able to
select CONFIG_HIBERNATE_CALLBACKS without dragging the entire
hibernate code along with it.Signed-off-by: Rafael J. Wysocki
Tested-by: Shriram Rajagopalan
17 Mar, 2011
1 commit
-
Use PM_FREEZE, PM_THAW and PM_RESTORE power events for
suspend/resume/checkpoint functionality, instead of PM_SUSPEND
and PM_RESUME. Use of these pm events fixes the Xen Guest hangup
when taking checkpoints. When a suspend event is cancelled
(while taking checkpoints once/continuously), we use PM_THAW
instead of PM_RESUME. PM_RESTORE is used when suspend is not
cancelled. See Documentation/power/devices.txt and linux/pm.h
for more info about freeze, thaw and restore. The sequence of
pm events in a suspend-resume scenario is shown below.dpm_suspend_start(PMSG_FREEZE);
dpm_suspend_noirq(PMSG_FREEZE);
sysdev_suspend(PMSG_FREEZE);
cancelled = suspend_hypercall()
sysdev_resume();dpm_resume_noirq(cancelled ? PMSG_THAW : PMSG_RESTORE);
dpm_resume_end(cancelled ? PMSG_THAW : PMSG_RESTORE);
Acked-by: Ian Campbell
Signed-off-by: Shriram Rajagopalan
Signed-off-by: Konrad Rzeszutek Wilk
26 Feb, 2011
10 commits
-
It is now identical to xen_suspend, the differences are encapsulated
in the suspend_info struct.Signed-off-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk -
Signed-off-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk -
Signed-off-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk -
Signed-off-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk -
xen_pre_device_suspend is unused on ia64.
Signed-off-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk -
Signed-off-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk -
Will add extra fields in subsequent patches.
Signed-off-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk -
Signed-off-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk -
The PV xenbus control/shutdown node is written by the toolstack as a
request to the guest to perform a particular action (shutdown, reboot,
suspend etc). The guest is expected to acknowledge that it will
complete a request by clearing the control node.Previously it would acknowledge any request, even if it did not know
what to do with it. Specifically in the case where CONFIG_PM_SLEEP is
not enabled the kernel would acknowledge a suspend request even though
it was not actually going to do anything.Instead make the kernel only acknowledge requests if it is actually
going to do something with it. This will improve the toolstack's
ability to diagnose and deal with failures.Signed-off-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk -
Now that xenstore_ready is used correctly for PV on HVM guests too, we
don't need to delay the initialization of xen_setup_shutdown_event
anymore.Signed-off-by: Stefano Stabellini
Acked-by: Jeremy Fitzhardinge
17 Feb, 2011
1 commit
-
Otherwise we fail to properly suspend/resume all of the emulated devices.
Something between 2.6.38-rc2 and rc3 appears to have exposed this
issue, but it's always been wrong not to do this.Signed-off-by: Ian Campbell
Acked-by: Stefano Stabellini
Acked-by: Jeremy Fitzhardinge
02 Dec, 2010
1 commit
-
Signed-off-by: Stefano Stabellini
21 Aug, 2010
1 commit
-
Sysrq operations do not accept tty argument anymore so no need to pass
it to us.[Stephen Rothwell : fix build breakage in drm code
caused by sysrq using bool but not including linux/types.h][Sachin Sant : fix build breakage in s390 keyboadr
driver]Acked-by: Alan Cox
Acked-by: Jason Wessel
Acked-by: Greg Kroah-Hartman
Signed-off-by: Dmitry Torokhov
23 Jul, 2010
2 commits
-
Suspend/resume requires few different things on HVM: the suspend
hypercall is different; we don't need to save/restore memory related
settings; except the shared info page and the callback mechanism.Signed-off-by: Stefano Stabellini
Signed-off-by: Jeremy Fitzhardinge -
Add the xen pci platform device driver that is responsible
for initializing the grant table and xenbus in PV on HVM mode.
Few changes to xenbus and grant table are necessary to allow the delayed
initialization in HVM mode.
Grant table needs few additional modifications to work in HVM mode.The Xen PCI platform device raises an irq every time an event has been
delivered to us. However these interrupts are only delivered to vcpu 0.
The Xen PCI platform interrupt handler calls xen_hvm_evtchn_do_upcall
that is a little wrapper around __xen_evtchn_do_upcall, the traditional
Xen upcall handler, the very same used with traditional PV guests.When running on HVM the event channel upcall is never called while in
progress because it is a normal Linux irq handler (and we cannot switch
the irq chip wholesale to the Xen PV ones as we are running QEMU and
might have passed in PCI devices), therefore we cannot be sure that
evtchn_upcall_pending is 0 when returning.
For this reason if evtchn_upcall_pending is set by Xen we need to loop
again on the event channels set pending otherwise we might loose some
event channel deliveries.Signed-off-by: Stefano Stabellini
Signed-off-by: Sheng Yang
Signed-off-by: Jeremy Fitzhardinge
25 May, 2010
1 commit
-
Fix build error when CONFIG_MAGIC_SYSRQ is not enabled:
drivers/xen/manage.c:223: error: implicit declaration of function 'handle_sysrq'
Signed-off-by: Randy Dunlap
Acked-by: Jeremy Fitzhardinge
Cc: Chris Wright
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 May, 2010
1 commit
-
Reimplement stop_machine using cpu_stop. As cpu stoppers are
guaranteed to be available for all online cpus,
stop_machine_create/destroy() are no longer necessary and removed.With resource management and synchronization handled by cpu_stop, the
new implementation is much simpler. Asking the cpu_stop to execute
the stop_cpu() state machine on all online cpus with cpu hotplug
disabled is enough.stop_machine itself doesn't need to manage any global resources
anymore, so all per-instance information is rolled into struct
stop_machine_data and the mutex and all static data variables are
removed.The previous implementation created and destroyed RT workqueues as
necessary which made stop_machine() calls highly expensive on very
large machines. According to Dimitri Sivanich, preventing the dynamic
creation/destruction makes booting faster more than twice on very
large machines. cpu_stop resources are preallocated for all online
cpus and should have the same effect.Signed-off-by: Tejun Heo
Acked-by: Rusty Russell
Acked-by: Peter Zijlstra
Cc: Oleg Nesterov
Cc: Dimitri Sivanich
30 Mar, 2010
1 commit
-
…it slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
13 Jan, 2010
1 commit
-
In 65f63384 "xen: improve error handling in do_suspend" I said:
- xs_suspend()/xs_resume() and dpm_suspend_noirq()/dpm_resume_noirq() were not
nested in the obvious way.
and changed the ordering of the calls as so:
BEFORE AFTER
xs_suspend dpm_suspend_noirq
dpm_suspend_noirq xs_suspend
*SUSPEND* *SUSPEND*
dpm_resume_noirq dpm_resume_noirq
xs_resume xs_resume
Clearly this is not an improvement and I was talking rubbish.In particular the new ordering is susceptible to a hang if a xenstore write is
in progress at the point at which the suspend kicks in. When the suspend
process calls xs_suspend it tries to take the request_mutex but if a write is
in progress it could be looping in xenbus_xs.c:read_reply() waiting for
something to arrive on &xs_state.reply_list while holding the request_mutex
(taken in the caller of read_reply).However if we have done dpm_suspend_noirq before xs_suspend then we won't get
any more xenstore interrupts and process_msg() will never be woken up to add
anything to the reply_list.Fix this by calling xs_suspend before dpm_suspend_noirq. If dpm_suspend_noirq
fails then make sure we go through the xs_suspend_cancel() code path.Signed-off-by: Ian Campbell
Acked-by: Jeremy Fitzhardinge
Cc: Stable Kernel
04 Dec, 2009
3 commits
-
I have observed cases where the implicit stop_machine_destroy() done by
stop_machine() hangs while destroying the workqueues, specifically in
kthread_stop(). This seems to be because timer ticks are not restarted
until after stop_machine() returns.Fortunately stop_machine provides a facility to pre-create/post-destroy
the workqueues so use this to ensure that workqueues are only destroyed
after everything is really up and running again.I only actually observed this failure with 2.6.30. It seems that newer
kernels are somehow more robust against doing kthread_stop() without timer
interrupts (I tried some backports of some likely looking candidates but
did not track down the commit which added this robustness). However this
change seems like a reasonable belt&braces thing to do.Signed-off-by: Ian Campbell
Signed-off-by: Jeremy Fitzhardinge
Cc: Stable Kernel -
The existing error handling has a few issues:
- If freeze_processes() fails it exits with shutting_down = SHUTDOWN_SUSPEND.
- If dpm_suspend_noirq() fails it exits without resuming xenbus.
- If stop_machine() fails it exits without resuming xenbus or calling
dpm_resume_end().
- xs_suspend()/xs_resume() and dpm_suspend_noirq()/dpm_resume_noirq() were not
nested in the obvious way.Fix by ensuring each failure case goto's the correct label. Treat a failure of
stop_machine() as a cancelled suspend in order to follow the correct resume
path.Signed-off-by: Ian Campbell
Signed-off-by: Jeremy Fitzhardinge
Cc: Stable Kernel -
dpm_resume_noirq() takes a mutex, so it can't be called from a no-interrupt
context. Don't call it from within the stop-machine function, but just
afterwards, since we're resuming anyway, regardless of what happened.Signed-off-by: Jeremy Fitzhardinge
Cc: Stable Kernel
13 Jun, 2009
2 commits
-
This patch (as1241) renames a bunch of functions in the PM core.
Rather than go through a boring list of name changes, suffice it to
say that in the end we have a bunch of pairs of functions:device_resume_noirq dpm_resume_noirq
device_resume dpm_resume
device_complete dpm_complete
device_suspend_noirq dpm_suspend_noirq
device_suspend dpm_suspend
device_prepare dpm_preparein which device_X does the X operation on a single device and dpm_X
invokes device_X for all devices in the dpm_list.In addition, the old dpm_power_up and device_resume_noirq have been
combined into a single function (dpm_resume_noirq).Lastly, dpm_suspend_start and dpm_resume_end are the renamed versions
of the former top-level device_suspend and device_resume routines.Signed-off-by: Alan Stern
Acked-by: Magnus Damm
Signed-off-by: Rafael J. Wysocki -
Rename the functions performing "_noirq" dev_pm_ops
operations from device_power_down() and device_power_up()
to device_suspend_noirq() and device_resume_noirq().The new function names are chosen to show that the functions
are responsible for calling the _noirq() versions to finalize
the suspend/resume operation. The current function names do
not perform power down/up anymore so the names may be misleading.Global function renames:
- device_power_down() -> device_suspend_noirq()
- device_power_up() -> device_resume_noirq()Static function renames:
- suspend_device_noirq() -> __device_suspend_noirq()
- resume_device_noirq() -> __device_resume_noirq()Signed-off-by: Magnus Damm
Acked-by: Greg Kroah-Hartman
Acked-by: Len Brown
Signed-off-by: Rafael J. Wysocki
