diff options
| author | Oliver Neukum <oliver@neukum.org> | 2008-07-04 10:10:53 +0200 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@suse.de> | 2008-08-13 17:32:52 -0700 |
| commit | f0fa74634c0c686618b5318748bde233772a1a8d (patch) | |
| tree | 5a3b179bfe2918cf91910b8c13fca461ef2843a4 | |
| parent | 230ffc75b7b842db5710d30d3a2fc61f9d6f50df (diff) | |
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.txt | 7 |
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: |