1                        Power Management for USB
   3                 Alan Stern <>
   5                            October 5, 2007
   9        What is Power Management?
  10        -------------------------
  12Power Management (PM) is the practice of saving energy by suspending
  13parts of a computer system when they aren't being used.  While a
  14component is "suspended" it is in a nonfunctional low-power state; it
  15might even be turned off completely.  A suspended component can be
  16"resumed" (returned to a functional full-power state) when the kernel
  17needs to use it.  (There also are forms of PM in which components are
  18placed in a less functional but still usable state instead of being
  19suspended; an example would be reducing the CPU's clock rate.  This
  20document will not discuss those other forms.)
  22When the parts being suspended include the CPU and most of the rest of
  23the system, we speak of it as a "system suspend".  When a particular
  24device is turned off while the system as a whole remains running, we
  25call it a "dynamic suspend" (also known as a "runtime suspend" or
  26"selective suspend").  This document concentrates mostly on how
  27dynamic PM is implemented in the USB subsystem, although system PM is
  28covered to some extent (see Documentation/power/*.txt for more
  29information about system PM).
  31Note: Dynamic PM support for USB is present only if the kernel was
  32built with CONFIG_USB_SUSPEND enabled.  System PM support is present
  33only if the kernel was built with CONFIG_SUSPEND or CONFIG_HIBERNATION
  37        What is Remote Wakeup?
  38        ----------------------
  40When a device has been suspended, it generally doesn't resume until
  41the computer tells it to.  Likewise, if the entire computer has been
  42suspended, it generally doesn't resume until the user tells it to, say
  43by pressing a power button or opening the cover.
  45However some devices have the capability of resuming by themselves, or
  46asking the kernel to resume them, or even telling the entire computer
  47to resume.  This capability goes by several names such as "Wake On
  48LAN"; we will refer to it generically as "remote wakeup".  When a
  49device is enabled for remote wakeup and it is suspended, it may resume
  50itself (or send a request to be resumed) in response to some external
  51event.  Examples include a suspended keyboard resuming when a key is
  52pressed, or a suspended USB hub resuming when a device is plugged in.
  55        When is a USB device idle?
  56        --------------------------
  58A device is idle whenever the kernel thinks it's not busy doing
  59anything important and thus is a candidate for being suspended.  The
  60exact definition depends on the device's driver; drivers are allowed
  61to declare that a device isn't idle even when there's no actual
  62communication taking place.  (For example, a hub isn't considered idle
  63unless all the devices plugged into that hub are already suspended.)
  64In addition, a device isn't considered idle so long as a program keeps
  65its usbfs file open, whether or not any I/O is going on.
  67If a USB device has no driver, its usbfs file isn't open, and it isn't
  68being accessed through sysfs, then it definitely is idle.
  71        Forms of dynamic PM
  72        -------------------
  74Dynamic suspends can occur in two ways: manual and automatic.
  75"Manual" means that the user has told the kernel to suspend a device,
  76whereas "automatic" means that the kernel has decided all by itself to
  77suspend a device.  Automatic suspend is called "autosuspend" for
  78short.  In general, a device won't be autosuspended unless it has been
  79idle for some minimum period of time, the so-called idle-delay time.
  81Of course, nothing the kernel does on its own initiative should
  82prevent the computer or its devices from working properly.  If a
  83device has been autosuspended and a program tries to use it, the
  84kernel will automatically resume the device (autoresume).  For the
  85same reason, an autosuspended device will usually have remote wakeup
  86enabled, if the device supports remote wakeup.
  88It is worth mentioning that many USB drivers don't support
  89autosuspend.  In fact, at the time of this writing (Linux 2.6.23) the
  90only drivers which do support it are the hub driver, kaweth, asix,
  91usblp, usblcd, and usb-skeleton (which doesn't count).  If a
  92non-supporting driver is bound to a device, the device won't be
  93autosuspended.  In effect, the kernel pretends the device is never
  96We can categorize power management events in two broad classes:
  97external and internal.  External events are those triggered by some
  98agent outside the USB stack: system suspend/resume (triggered by
  99userspace), manual dynamic suspend/resume (also triggered by
 100userspace), and remote wakeup (triggered by the device).  Internal
 101events are those triggered within the USB stack: autosuspend and
 105        The user interface for dynamic PM
 106        ---------------------------------
 108The user interface for controlling dynamic PM is located in the power/
 109subdirectory of each USB device's sysfs directory, that is, in
 110/sys/bus/usb/devices/.../power/ where "..." is the device's ID.  The
 111relevant attribute files are: wakeup, level, and autosuspend.
 113        power/wakeup
 115                This file is empty if the device does not support
 116                remote wakeup.  Otherwise the file contains either the
 117                word "enabled" or the word "disabled", and you can
 118                write those words to the file.  The setting determines
 119                whether or not remote wakeup will be enabled when the
 120                device is next suspended.  (If the setting is changed
 121                while the device is suspended, the change won't take
 122                effect until the following suspend.)
 124        power/level
 126                This file contains one of three words: "on", "auto",
 127                or "suspend".  You can write those words to the file
 128                to change the device's setting.
 130                "on" means that the device should be resumed and
 131                autosuspend is not allowed.  (Of course, system
 132                suspends are still allowed.)
 134                "auto" is the normal state in which the kernel is
 135                allowed to autosuspend and autoresume the device.
 137                "suspend" means that the device should remain
 138                suspended, and autoresume is not allowed.  (But remote
 139                wakeup may still be allowed, since it is controlled
 140                separately by the power/wakeup attribute.)
 142        power/autosuspend
 144                This file contains an integer value, which is the
 145                number of seconds the device should remain idle before
 146                the kernel will autosuspend it (the idle-delay time).
 147                The default is 2.  0 means to autosuspend as soon as
 148                the device becomes idle, and -1 means never to
 149                autosuspend.  You can write a number to the file to
 150                change the autosuspend idle-delay time.
 152Writing "-1" to power/autosuspend and writing "on" to power/level do
 153essentially the same thing -- they both prevent the device from being
 154autosuspended.  Yes, this is a redundancy in the API.
 156(In 2.6.21 writing "0" to power/autosuspend would prevent the device
 157from being autosuspended; the behavior was changed in 2.6.22.  The
 158power/autosuspend attribute did not exist prior to 2.6.21, and the
 159power/level attribute did not exist prior to 2.6.22.)
 162        Changing the default idle-delay time
 163        ------------------------------------
 165The default autosuspend idle-delay time is controlled by a module
 166parameter in usbcore.  You can specify the value when usbcore is
 167loaded.  For example, to set it to 5 seconds instead of 2 you would
 170        modprobe usbcore autosuspend=5
 172Equivalently, you could add to /etc/modprobe.conf a line saying:
 174        options usbcore autosuspend=5
 176Some distributions load the usbcore module very early during the boot
 177process, by means of a program or script running from an initramfs
 178image.  To alter the parameter value you would have to rebuild that
 181If usbcore is compiled into the kernel rather than built as a loadable
 182module, you can add
 184        usbcore.autosuspend=5
 186to the kernel's boot command line.
 188Finally, the parameter value can be changed while the system is
 189running.  If you do:
 191        echo 5 >/sys/module/usbcore/parameters/autosuspend
 193then each new USB device will have its autosuspend idle-delay
 194initialized to 5.  (The idle-delay values for already existing devices
 195will not be affected.)
 197Setting the initial default idle-delay to -1 will prevent any
 198autosuspend of any USB device.  This is a simple alternative to
 199disabling CONFIG_USB_SUSPEND and rebuilding the kernel, and it has the
 200added benefit of allowing you to enable autosuspend for selected
 204        Warnings
 205        --------
 207The USB specification states that all USB devices must support power
 208management.  Nevertheless, the sad fact is that many devices do not
 209support it very well.  You can suspend them all right, but when you
 210try to resume them they disconnect themselves from the USB bus or
 211they stop working entirely.  This seems to be especially prevalent
 212among printers and scanners, but plenty of other types of device have
 213the same deficiency.
 215For this reason, by default the kernel disables autosuspend (the
 216power/level attribute is initialized to "on") for all devices other
 217than hubs.  Hubs, at least, appear to be reasonably well-behaved in
 218this regard.
 220(In 2.6.21 and 2.6.22 this wasn't the case.  Autosuspend was enabled
 221by default for almost all USB devices.  A number of people experienced
 222problems as a result.)
 224This means that non-hub devices won't be autosuspended unless the user
 225or a program explicitly enables it.  As of this writing there aren't
 226any widespread programs which will do this; we hope that in the near
 227future device managers such as HAL will take on this added
 228responsibility.  In the meantime you can always carry out the
 229necessary operations by hand or add them to a udev script.  You can
 230also change the idle-delay time; 2 seconds is not the best choice for
 231every device.
 233Sometimes it turns out that even when a device does work okay with
 234autosuspend there are still problems.  For example, there are
 235experimental patches adding autosuspend support to the usbhid driver,
 236which manages keyboards and mice, among other things.  Tests with a
 237number of keyboards showed that typing on a suspended keyboard, while
 238causing the keyboard to do a remote wakeup all right, would
 239nonetheless frequently result in lost keystrokes.  Tests with mice
 240showed that some of them would issue a remote-wakeup request in
 241response to button presses but not to motion, and some in response to
 244The kernel will not prevent you from enabling autosuspend on devices
 245that can't handle it.  It is even possible in theory to damage a
 246device by suspending it at the wrong time -- for example, suspending a
 247USB hard disk might cause it to spin down without parking the heads.
 248(Highly unlikely, but possible.)  Take care.
 251        The driver interface for Power Management
 252        -----------------------------------------
 254The requirements for a USB driver to support external power management
 255are pretty modest; the driver need only define
 257        .suspend
 258        .resume
 259        .reset_resume
 261methods in its usb_driver structure, and the reset_resume method is
 262optional.  The methods' jobs are quite simple:
 264        The suspend method is called to warn the driver that the
 265        device is going to be suspended.  If the driver returns a
 266        negative error code, the suspend will be aborted.  Normally
 267        the driver will return 0, in which case it must cancel all
 268        outstanding URBs (usb_kill_urb()) and not submit any more.
 270        The resume method is called to tell the driver that the
 271        device has been resumed and the driver can return to normal
 272        operation.  URBs may once more be submitted.
 274        The reset_resume method is called to tell the driver that
 275        the device has been resumed and it also has been reset.
 276        The driver should redo any necessary device initialization,
 277        since the device has probably lost most or all of its state
 278        (although the interfaces will be in the same altsettings as
 279        before the suspend).
 281If the device is disconnected or powered down while it is suspended,
 282the disconnect method will be called instead of the resume or
 283reset_resume method.  This is also quite likely to happen when
 284waking up from hibernation, as many systems do not maintain suspend
 285current to the USB host controllers during hibernation.  (It's
 286possible to work around the hibernation-forces-disconnect problem by
 287using the USB Persist facility.)
 289The reset_resume method is used by the USB Persist facility (see
 290Documentation/usb/persist.txt) and it can also be used under certain
 291circumstances when CONFIG_USB_PERSIST is not enabled.  Currently, if a
 292device is reset during a resume and the driver does not have a
 293reset_resume method, the driver won't receive any notification about
 294the resume.  Later kernels will call the driver's disconnect method;
 2952.6.23 doesn't do this.
 297USB drivers are bound to interfaces, so their suspend and resume
 298methods get called when the interfaces are suspended or resumed.  In
 299principle one might want to suspend some interfaces on a device (i.e.,
 300force the drivers for those interface to stop all activity) without
 301suspending the other interfaces.  The USB core doesn't allow this; all
 302interfaces are suspended when the device itself is suspended and all
 303interfaces are resumed when the device is resumed.  It isn't possible
 304to suspend or resume some but not all of a device's interfaces.  The
 305closest you can come is to unbind the interfaces' drivers.
 308        The driver interface for autosuspend and autoresume
 309        ---------------------------------------------------
 311To support autosuspend and autoresume, a driver should implement all
 312three of the methods listed above.  In addition, a driver indicates
 313that it supports autosuspend by setting the .supports_autosuspend flag
 314in its usb_driver structure.  It is then responsible for informing the
 315USB core whenever one of its interfaces becomes busy or idle.  The
 316driver does so by calling these three functions:
 318        int  usb_autopm_get_interface(struct usb_interface *intf);
 319        void usb_autopm_put_interface(struct usb_interface *intf);
 320        int  usb_autopm_set_interface(struct usb_interface *intf);
 322The functions work by maintaining a counter in the usb_interface
 323structure.  When intf->pm_usage_count is > 0 then the interface is
 324deemed to be busy, and the kernel will not autosuspend the interface's
 325device.  When intf->pm_usage_count is <= 0 then the interface is
 326considered to be idle, and the kernel may autosuspend the device.
 328(There is a similar pm_usage_count field in struct usb_device,
 329associated with the device itself rather than any of its interfaces.
 330This field is used only by the USB core.)
 332The driver owns intf->pm_usage_count; it can modify the value however
 333and whenever it likes.  A nice aspect of the usb_autopm_* routines is
 334that the changes they make are protected by the usb_device structure's
 335PM mutex (udev->pm_mutex); however drivers may change pm_usage_count
 336without holding the mutex.
 338        usb_autopm_get_interface() increments pm_usage_count and
 339        attempts an autoresume if the new value is > 0 and the
 340        device is suspended.
 342        usb_autopm_put_interface() decrements pm_usage_count and
 343        attempts an autosuspend if the new value is <= 0 and the
 344        device isn't suspended.
 346        usb_autopm_set_interface() leaves pm_usage_count alone.
 347        It attempts an autoresume if the value is > 0 and the device
 348        is suspended, and it attempts an autosuspend if the value is
 349        <= 0 and the device isn't suspended.
 351There also are a couple of utility routines drivers can use:
 353        usb_autopm_enable() sets pm_usage_cnt to 0 and then calls
 354        usb_autopm_set_interface(), which will attempt an autosuspend.
 356        usb_autopm_disable() sets pm_usage_cnt to 1 and then calls
 357        usb_autopm_set_interface(), which will attempt an autoresume.
 359The conventional usage pattern is that a driver calls
 360usb_autopm_get_interface() in its open routine and
 361usb_autopm_put_interface() in its close or release routine.  But
 362other patterns are possible.
 364The autosuspend attempts mentioned above will often fail for one
 365reason or another.  For example, the power/level attribute might be
 366set to "on", or another interface in the same device might not be
 367idle.  This is perfectly normal.  If the reason for failure was that
 368the device hasn't been idle for long enough, a delayed workqueue
 369routine is automatically set up to carry out the operation when the
 370autosuspend idle-delay has expired.
 372Autoresume attempts also can fail.  This will happen if power/level is
 373set to "suspend" or if the device doesn't manage to resume properly.
 374Unlike autosuspend, there's no delay for an autoresume.
 377        Other parts of the driver interface
 378        -----------------------------------
 380Sometimes a driver needs to make sure that remote wakeup is enabled
 381during autosuspend.  For example, there's not much point
 382autosuspending a keyboard if the user can't cause the keyboard to do a
 383remote wakeup by typing on it.  If the driver sets
 384intf->needs_remote_wakeup to 1, the kernel won't autosuspend the
 385device if remote wakeup isn't available or has been disabled through
 386the power/wakeup attribute.  (If the device is already autosuspended,
 387though, setting this flag won't cause the kernel to autoresume it.
 388Normally a driver would set this flag in its probe method, at which
 389time the device is guaranteed not to be autosuspended.)
 391The usb_autopm_* routines have to run in a sleepable process context;
 392they must not be called from an interrupt handler or while holding a
 393spinlock.  In fact, the entire autosuspend mechanism is not well geared
 394toward interrupt-driven operation.  However there is one thing a
 395driver can do in an interrupt handler:
 397        usb_mark_last_busy(struct usb_device *udev);
 399This sets udev->last_busy to the current time.  udev->last_busy is the
 400field used for idle-delay calculations; updating it will cause any
 401pending autosuspend to be moved back.  The usb_autopm_* routines will
 402also set the last_busy field to the current time.
 404Calling urb_mark_last_busy() from within an URB completion handler is
 405subject to races: The kernel may have just finished deciding the
 406device has been idle for long enough but not yet gotten around to
 407calling the driver's suspend method.  The driver would have to be
 408responsible for synchronizing its suspend method with its URB
 409completion handler and causing the autosuspend to fail with -EBUSY if
 410an URB had completed too recently.
 412External suspend calls should never be allowed to fail in this way,
 413only autosuspend calls.  The driver can tell them apart by checking
 414udev->auto_pm; this flag will be set to 1 for internal PM events
 415(autosuspend or autoresume) and 0 for external PM events.
 417Many of the ingredients in the autosuspend framework are oriented
 418towards interfaces: The usb_interface structure contains the
 419pm_usage_cnt field, and the usb_autopm_* routines take an interface
 420pointer as their argument.  But somewhat confusingly, a few of the
 421pieces (usb_mark_last_busy() and udev->auto_pm) use the usb_device
 422structure instead.  Drivers need to keep this straight; they can call
 423interface_to_usbdev() to find the device structure for a given
 427        Locking requirements
 428        --------------------
 430All three suspend/resume methods are always called while holding the
 431usb_device's PM mutex.  For external events -- but not necessarily for
 432autosuspend or autoresume -- the device semaphore (udev->dev.sem) will
 433also be held.  This implies that external suspend/resume events are
 434mutually exclusive with calls to probe, disconnect, pre_reset, and
 435post_reset; the USB core guarantees that this is true of internal
 436suspend/resume events as well.
 438If a driver wants to block all suspend/resume calls during some
 439critical section, it can simply acquire udev->pm_mutex. Note that
 440calls to resume may be triggered indirectly. Block IO due to memory
 441allocations can make the vm subsystem resume a device. Thus while
 442holding this lock you must not allocate memory with GFP_KERNEL or
 445Alternatively, if the critical section might call some of the
 446usb_autopm_* routines, the driver can avoid deadlock by doing:
 448        down(&udev->dev.sem);
 449        rc = usb_autopm_get_interface(intf);
 451and at the end of the critical section:
 453        if (!rc)
 454                usb_autopm_put_interface(intf);
 455        up(&udev->dev.sem);
 457Holding the device semaphore will block all external PM calls, and the
 458usb_autopm_get_interface() will prevent any internal PM calls, even if
 459it fails.  (Exercise: Why?)
 461The rules for locking order are:
 463        Never acquire any device semaphore while holding any PM mutex.
 465        Never acquire udev->pm_mutex while holding the PM mutex for
 466        a device that isn't a descendant of udev.
 468In other words, PM mutexes should only be acquired going up the device
 469tree, and they should be acquired only after locking all the device
 470semaphores you need to hold.  These rules don't matter to drivers very
 471much; they usually affect just the USB core.
 473Still, drivers do need to be careful.  For example, many drivers use a
 474private mutex to synchronize their normal I/O activities with their
 475disconnect method.  Now if the driver supports autosuspend then it
 476must call usb_autopm_put_interface() from somewhere -- maybe from its
 477close method.  It should make the call while holding the private mutex,
 478since a driver shouldn't call any of the usb_autopm_* functions for an
 479interface from which it has been unbound.
 481But the usb_autpm_* routines always acquire the device's PM mutex, and
 482consequently the locking order has to be: private mutex first, PM
 483mutex second.  Since the suspend method is always called with the PM
 484mutex held, it mustn't try to acquire the private mutex.  It has to
 485synchronize with the driver's I/O activities in some other way.
 488        Interaction between dynamic PM and system PM
 489        --------------------------------------------
 491Dynamic power management and system power management can interact in
 492a couple of ways.
 494Firstly, a device may already be manually suspended or autosuspended
 495when a system suspend occurs.  Since system suspends are supposed to
 496be as transparent as possible, the device should remain suspended
 497following the system resume.  The 2.6.23 kernel obeys this principle
 498for manually suspended devices but not for autosuspended devices; they
 499do get resumed when the system wakes up.  (Presumably they will be
 500autosuspended again after their idle-delay time expires.)  In later
 501kernels this behavior will be fixed.
 503(There is an exception.  If a device would undergo a reset-resume
 504instead of a normal resume, and the device is enabled for remote
 505wakeup, then the reset-resume takes place even if the device was
 506already suspended when the system suspend began.  The justification is
 507that a reset-resume is a kind of remote-wakeup event.  Or to put it
 508another way, a device which needs a reset won't be able to generate
 509normal remote-wakeup signals, so it ought to be resumed immediately.)
 511Secondly, a dynamic power-management event may occur as a system
 512suspend is underway.  The window for this is short, since system
 513suspends don't take long (a few seconds usually), but it can happen.
 514For example, a suspended device may send a remote-wakeup signal while
 515the system is suspending.  The remote wakeup may succeed, which would
 516cause the system suspend to abort.  If the remote wakeup doesn't
 517succeed, it may still remain active and thus cause the system to
 518resume as soon as the system suspend is complete.  Or the remote
 519wakeup may fail and get lost.  Which outcome occurs depends on timing
 520and on the hardware and firmware design.
 522More interestingly, a device might undergo a manual resume or
 523autoresume during system suspend.  With current kernels this shouldn't
 524happen, because manual resumes must be initiated by userspace and
 525autoresumes happen in response to I/O requests, but all user processes
 526and I/O should be quiescent during a system suspend -- thanks to the
 527freezer.  However there are plans to do away with the freezer, which
 528would mean these things would become possible.  If and when this comes
 529about, the USB core will carefully arrange matters so that either type
 530of resume will block until the entire system has resumed.
 531 kindly hosted by Redpill Linpro AS, provider of Linux consulting and operations services since 1995.