summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorOliver Neukum <oliver@neukum.org>2008-07-04 10:10:53 +0200
committerGreg Kroah-Hartman <gregkh@suse.de>2008-08-14 02:32:52 +0200
commitf0fa74634c0c686618b5318748bde233772a1a8d (patch)
tree5a3b179bfe2918cf91910b8c13fca461ef2843a4
parentUSB: cxacru: Fix printk format flag in error message (diff)
downloadlinux-f0fa74634c0c686618b5318748bde233772a1a8d.tar.xz
linux-f0fa74634c0c686618b5318748bde233772a1a8d.zip
USB: update to Documentation
this mentions a new deadlock due to advanced power management. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-rw-r--r--Documentation/usb/power-management.txt7
1 files changed, 6 insertions, 1 deletions
diff --git a/Documentation/usb/power-management.txt b/Documentation/usb/power-management.txt
index b2fc4d4a9917..9d31140e3f5b 100644
--- a/Documentation/usb/power-management.txt
+++ b/Documentation/usb/power-management.txt
@@ -436,7 +436,12 @@ post_reset; the USB core guarantees that this is true of internal
suspend/resume events as well.
If a driver wants to block all suspend/resume calls during some
-critical section, it can simply acquire udev->pm_mutex.
+critical section, it can simply acquire udev->pm_mutex. Note that
+calls to resume may be triggered indirectly. Block IO due to memory
+allocations can make the vm subsystem resume a device. Thus while
+holding this lock you must not allocate memory with GFP_KERNEL or
+GFP_NOFS.
+
Alternatively, if the critical section might call some of the
usb_autopm_* routines, the driver can avoid deadlock by doing: