Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
Merge branch 'pm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6
* 'pm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6:
PM / Runtime: Update documentation regarding driver removal
PM: Documentation: fix typo: pm_runtime_idle_sync() doesn't exist.
+21
-5
+21
-5
Documentation/power/runtime_pm.txt
+21
-5
Documentation/power/runtime_pm.txt
···
501
501
should be used. Of course, for this purpose the device's run-time PM has to be
502
502
enabled earlier by calling pm_runtime_enable().
503
503
504
-
If the device bus type's or driver's ->probe() or ->remove() callback runs
504
+
If the device bus type's or driver's ->probe() callback runs
505
505
pm_runtime_suspend() or pm_runtime_idle() or their asynchronous counterparts,
506
506
they will fail returning -EAGAIN, because the device's usage counter is
507
-
incremented by the core before executing ->probe() and ->remove(). Still, it
508
-
may be desirable to suspend the device as soon as ->probe() or ->remove() has
509
-
finished, so the PM core uses pm_runtime_idle_sync() to invoke the
510
-
subsystem-level idle callback for the device at that time.
507
+
incremented by the driver core before executing ->probe(). Still, it may be
508
+
desirable to suspend the device as soon as ->probe() has finished, so the driver
509
+
core uses pm_runtime_put_sync() to invoke the subsystem-level idle callback for
510
+
the device at that time.
511
+
512
+
Moreover, the driver core prevents runtime PM callbacks from racing with the bus
513
+
notifier callback in __device_release_driver(), which is necessary, because the
514
+
notifier is used by some subsystems to carry out operations affecting the
515
+
runtime PM functionality. It does so by calling pm_runtime_get_sync() before
516
+
driver_sysfs_remove() and the BUS_NOTIFY_UNBIND_DRIVER notifications. This
517
+
resumes the device if it's in the suspended state and prevents it from
518
+
being suspended again while those routines are being executed.
519
+
520
+
To allow bus types and drivers to put devices into the suspended state by
521
+
calling pm_runtime_suspend() from their ->remove() routines, the driver core
522
+
executes pm_runtime_put_sync() after running the BUS_NOTIFY_UNBIND_DRIVER
523
+
notifications in __device_release_driver(). This requires bus types and
524
+
drivers to make their ->remove() callbacks avoid races with runtime PM directly,
525
+
but also it allows of more flexibility in the handling of devices during the
526
+
removal of their drivers.
511
527
512
528
The user space can effectively disallow the driver of the device to power manage
513
529
it at run time by changing the value of its /sys/devices/.../power/control