Commit e1c3e6e1 authored by Mauro Carvalho Chehab's avatar Mauro Carvalho Chehab Committed by Jonathan Corbet

docs-rst: fix usb cross-references

As some USB documentation files got moved, adjust their
cross-references to their new place.
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
parent 0cb30062
...@@ -9,7 +9,7 @@ Description: ...@@ -9,7 +9,7 @@ Description:
hubs this facility is always enabled and their device hubs this facility is always enabled and their device
directories will not contain this file. 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 What: /sys/bus/usb/devices/.../power/autosuspend
Date: March 2007 Date: March 2007
......
.. _usb-urb:
USB Request Block (URB) USB Request Block (URB)
~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~
......
...@@ -8,7 +8,7 @@ Usbcore will call into a driver through callbacks defined in the driver ...@@ -8,7 +8,7 @@ Usbcore will call into a driver through callbacks defined in the driver
structure and through the completion handler of URBs a driver submits. 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 Only the former are in the scope of this document. These two kinds of
callbacks are completely independent of each other. Information on the 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 callbacks defined in the driver structure are:
...@@ -53,7 +53,7 @@ The callbacks defined in the driver structure are: ...@@ -53,7 +53,7 @@ The callbacks defined in the driver structure are:
The ioctl interface (2) should be used only if you have a very good 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 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 Calling conventions
=================== ===================
......
.. _usb-error-codes:
USB Error codes USB Error codes
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~
......
.. _usb-persist:
USB device persistence during system suspend USB device persistence during system suspend
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
......
...@@ -328,7 +328,7 @@ possible to work around the hibernation-forces-disconnect problem by ...@@ -328,7 +328,7 @@ possible to work around the hibernation-forces-disconnect problem by
using the USB Persist facility.) using the USB Persist facility.)
The ``reset_resume`` method is used by the USB Persist facility (see 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 circumstances when ``CONFIG_USB_PERSIST`` is not enabled. Currently, if a
device is reset during a resume and the driver does not have 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 ``reset_resume`` method, the driver won't receive any notification about
......
...@@ -424,8 +424,8 @@ header. ...@@ -424,8 +424,8 @@ header.
Unless noted otherwise, the ioctl requests described here will update Unless noted otherwise, the ioctl requests described here will update
the modification time on the usbfs file to which they are applied the modification time on the usbfs file to which they are applied
(unless they fail). A return of zero indicates success; otherwise, a (unless they fail). A return of zero indicates success; otherwise, a
standard USB error code is returned. (These are documented in standard USB error code is returned (These are documented in
``Documentation/usb/error-codes.txt`` in your kernel sources.) :ref:`usb-error-codes`).
Each of these files multiplexes access to several I/O streams, one per Each of these files multiplexes access to several I/O streams, one per
endpoint. Each device has one control endpoint (endpoint zero) which endpoint. Each device has one control endpoint (endpoint zero) which
......
...@@ -406,7 +406,7 @@ Firewire, CompactFlash, MMC, external SATA, or even IDE hotplug bays) ...@@ -406,7 +406,7 @@ Firewire, CompactFlash, MMC, external SATA, or even IDE hotplug bays)
before suspending; then remount them after resuming. before suspending; then remount them after resuming.
There is a work-around for this problem. For more information, see 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? Q: Can I suspend-to-disk using a swap partition under LVM?
......
...@@ -490,7 +490,7 @@ static void hdm_write_completion(struct urb *urb) ...@@ -490,7 +490,7 @@ static void hdm_write_completion(struct urb *urb)
* disconnect. In the interval before the hub driver starts disconnect * disconnect. In the interval before the hub driver starts disconnect
* processing, devices may receive such fault reports for every request. * 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) static void hdm_read_completion(struct urb *urb)
{ {
......
...@@ -26,7 +26,7 @@ config USB_DEFAULT_PERSIST ...@@ -26,7 +26,7 @@ config USB_DEFAULT_PERSIST
unplugged, causing any mounted filesystems to be lost. The unplugged, causing any mounted filesystems to be lost. The
persist feature can still be enabled for individual devices persist feature can still be enabled for individual devices
through the power/persist sysfs node. See 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 have any questions about this, say Y here, only say N
if you know exactly what you are doing. if you know exactly what you are doing.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment