Documentation/driver-api/usb/persist.rst

Source file repositories/reference/linux-study-clean/Documentation/driver-api/usb/persist.rst

File Facts

System
Linux kernel
Corpus path
Documentation/driver-api/usb/persist.rst
Extension
.rst
Size
7872 bytes
Lines
172
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. _usb-persist:

USB device persistence during system suspend
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

:Author: Alan Stern <stern@rowland.harvard.edu>
:Date: September 2, 2006 (Updated February 25, 2008)


What is the problem?
====================

According to the USB specification, when a USB bus is suspended the
bus must continue to supply suspend current (around 1-5 mA).  This
is so that devices can maintain their internal state and hubs can
detect connect-change events (devices being plugged in or unplugged).
The technical term is "power session".

If a USB device's power session is interrupted then the system is
required to behave as though the device has been unplugged.  It's a
conservative approach; in the absence of suspend current the computer
has no way to know what has actually happened.  Perhaps the same
device is still attached or perhaps it was removed and a different
device plugged into the port.  The system must assume the worst.

By default, Linux behaves according to the spec.  If a USB host
controller loses power during a system suspend, then when the system
wakes up all the devices attached to that controller are treated as
though they had disconnected.  This is always safe and it is the
"officially correct" thing to do.

For many sorts of devices this behavior doesn't matter in the least.
If the kernel wants to believe that your USB keyboard was unplugged
while the system was asleep and a new keyboard was plugged in when the
system woke up, who cares?  It'll still work the same when you type on
it.

Unfortunately problems _can_ arise, particularly with mass-storage
devices.  The effect is exactly the same as if the device really had
been unplugged while the system was suspended.  If you had a mounted
filesystem on the device, you're out of luck -- everything in that
filesystem is now inaccessible.  This is especially annoying if your
root filesystem was located on the device, since your system will
instantly crash.

Loss of power isn't the only mechanism to worry about.  Anything that
interrupts a power session will have the same effect.  For example,
even though suspend current may have been maintained while the system
was asleep, on many systems during the initial stages of wakeup the
firmware (i.e., the BIOS) resets the motherboard's USB host
controllers.  Result: all the power sessions are destroyed and again
it's as though you had unplugged all the USB devices.  Yes, it's
entirely the BIOS's fault, but that doesn't do _you_ any good unless
you can convince the BIOS supplier to fix the problem (lots of luck!).

On many systems the USB host controllers will get reset after a
suspend-to-RAM.  On almost all systems, no suspend current is
available during hibernation (also known as swsusp or suspend-to-disk).
You can check the kernel log after resuming to see if either of these
has happened; look for lines saying "root hub lost power or was reset".

In practice, people are forced to unmount any filesystems on a USB
device before suspending.  If the root filesystem is on a USB device,
the system can't be suspended at all.  (All right, it _can_ be
suspended -- but it will crash as soon as it wakes up, which isn't
much better.)


What is the solution?
=====================

Annotation

Implementation Notes