x86, early_ioremap: fix fencepost error

[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 97842deec47170dee0617d8767e5ebb5d8fa099e..9d31140e3f5bc2db17e446b426a4ecfacbbf99fc 100644 (file)
--- a/Documentation/usb/power-management.txt
+++ b/Documentation/usb/power-management.txt
@@ -278,6 +278,14 @@ optional.  The methods' jobs are quite simple:
        (although the interfaces will be in the same altsettings as
        before the suspend).
 
+If the device is disconnected or powered down while it is suspended,
+the disconnect method will be called instead of the resume or
+reset_resume method.  This is also quite likely to happen when
+waking up from hibernation, as many systems do not maintain suspend
+current to the USB host controllers during hibernation.  (It's
+possible to work around the hibernation-forces-disconnect problem by
+using the USB Persist facility.)
+
 The reset_resume method is used by the USB Persist facility (see
 Documentation/usb/persist.txt) and it can also be used under certain
 circumstances when CONFIG_USB_PERSIST is not enabled.  Currently, if a
@@ -428,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: