Merge branches 'topic/fix/misc' and 'topic/fix/asoc' into for-linus

[linux-2.6-omap-h63xx.git] / Documentation / usb / power-management.txt

diff --git a/Documentation/usb/power-management.txt b/Documentation/usb/power-management.txt
index b2fc4d4a99177be7bd48dce560d1f28417c60aa9..e48ea1d510105212cfbc8ee7c264636341f16f59 100644 (file)
--- a/Documentation/usb/power-management.txt
+++ b/Documentation/usb/power-management.txt
@@ -350,12 +350,12 @@ without holding the mutex.
 
 There also are a couple of utility routines drivers can use:
 
-       usb_autopm_enable() sets pm_usage_cnt to 1 and then calls
-       usb_autopm_set_interface(), which will attempt an autoresume.
-
-       usb_autopm_disable() sets pm_usage_cnt to 0 and then calls
+       usb_autopm_enable() sets pm_usage_cnt to 0 and then calls
        usb_autopm_set_interface(), which will attempt an autosuspend.
 
+       usb_autopm_disable() sets pm_usage_cnt to 1 and then calls
+       usb_autopm_set_interface(), which will attempt an autoresume.
+
 The conventional usage pattern is that a driver calls
 usb_autopm_get_interface() in its open routine and
 usb_autopm_put_interface() in its close or release routine.  But
@@ -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: