hubs this facility is always enabled and their device
directories will not contain this file.
- For more information, see Documentation/usb/persist.txt.
+ For more information, see Documentation/driver-api/usb/persist.rst.
What: /sys/bus/usb/devices/.../power/autosuspend
Date: March 2007
+.. _usb-urb:
+
USB Request Block (URB)
~~~~~~~~~~~~~~~~~~~~~~~
structure and through the completion handler of URBs a driver submits.
Only the former are in the scope of this document. These two kinds of
callbacks are completely independent of each other. Information on the
-completion callback can be found in Documentation/usb/URB.txt.
+completion callback can be found in :ref:`usb-urb`.
The callbacks defined in the driver structure are:
The ioctl interface (2) should be used only if you have a very good
reason. Sysfs is preferred these days. The PM callbacks are covered
-separately in Documentation/usb/power-management.txt.
+separately in :ref:`usb-power-management`.
Calling conventions
===================
+.. _usb-error-codes:
+
USB Error codes
~~~~~~~~~~~~~~~
+.. _usb-persist:
+
USB device persistence during system suspend
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
+:ref:`usb-persist`) and it can also be used under certain
circumstances when ``CONFIG_USB_PERSIST`` is not enabled. Currently, if a
device is reset during a resume and the driver does not have a
``reset_resume`` method, the driver won't receive any notification about
Unless noted otherwise, the ioctl requests described here will update
the modification time on the usbfs file to which they are applied
(unless they fail). A return of zero indicates success; otherwise, a
-standard USB error code is returned. (These are documented in
-``Documentation/usb/error-codes.txt`` in your kernel sources.)
+standard USB error code is returned (These are documented in
+:ref:`usb-error-codes`).
Each of these files multiplexes access to several I/O streams, one per
endpoint. Each device has one control endpoint (endpoint zero) which
before suspending; then remount them after resuming.
There is a work-around for this problem. For more information, see
-Documentation/usb/persist.txt.
+Documentation/driver-api/usb/persist.rst.
Q: Can I suspend-to-disk using a swap partition under LVM?
* disconnect. In the interval before the hub driver starts disconnect
* processing, devices may receive such fault reports for every request.
*
- * See <https://www.kernel.org/doc/Documentation/usb/error-codes.txt>
+ * See <https://www.kernel.org/doc/Documentation/driver-api/usb/error-codes.rst>
*/
static void hdm_read_completion(struct urb *urb)
{
unplugged, causing any mounted filesystems to be lost. The
persist feature can still be enabled for individual devices
through the power/persist sysfs node. See
- Documentation/usb/persist.txt for more info.
+ Documentation/driver-api/usb/persist.rst for more info.
If you have any questions about this, say Y here, only say N
if you know exactly what you are doing.