driver-api/usb/power-management.rst

34 parts of a computer system when they aren't being used.  While a
69 When a device has been suspended, it generally doesn't resume until
71 suspended, it generally doesn't resume until the user tells it to, say
90 to declare that a device isn't idle even when there's no actual
91 communication taking place.  (For example, a hub isn't considered idle
93 In addition, a device isn't considered idle so long as a program keeps
96 If a USB device has no driver, its usbfs file isn't open, and it isn't
105 won't be autosuspended unless it has been idle for some minimum period
115 It is worth mentioning that many USB drivers don't support
118 usblp, usblcd, and usb-skeleton (which doesn't count).  If a
119 non-supporting driver is bound to a device, the device won't be
156 		while the device is suspended, the change won't take
258 (In 2.6.21 and 2.6.22 this wasn't the case.  Autosuspend was enabled
262 This means that non-hub devices won't be autosuspended unless the user
263 or a program explicitly enables it.  As of this writing there aren't
287 that can't handle it.  It is even possible in theory to damage a
334 ``reset_resume`` method, the driver won't receive any notification about
336 2.6.23 doesn't do this.
342 suspending the other interfaces.  The USB core doesn't allow this; all
344 interfaces are resumed when the device is resumed.  It isn't possible
416 the device hasn't been idle for long enough, a timer is scheduled to
443 autosuspending a keyboard if the user can't cause the keyboard to do a
445 ``intf->needs_remote_wakeup`` to 1, the kernel won't autosuspend the
446 device if remote wakeup isn't available.  (If the device is already
447 autosuspended, though, setting this flag won't cause the kernel to
514 suspends don't take long (a few seconds usually), but it can happen.
517 cause the system suspend to abort.  If the remote wakeup doesn't