Browse Source

docs-rst: fix usb cross-references

As some USB documentation files got moved, adjust their
cross-references to their new place.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Mauro Carvalho Chehab 8 years ago
parent
commit
e1c3e6e1ca

+ 1 - 1
Documentation/ABI/stable/sysfs-bus-usb

@@ -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

+ 2 - 0
Documentation/driver-api/usb/URB.rst

@@ -1,3 +1,5 @@
+.. _usb-urb:
+
 USB Request Block (URB)
 USB Request Block (URB)
 ~~~~~~~~~~~~~~~~~~~~~~~
 ~~~~~~~~~~~~~~~~~~~~~~~
 
 

+ 2 - 2
Documentation/driver-api/usb/callbacks.rst

@@ -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:
 
 
 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
 ===================
 ===================

+ 2 - 0
Documentation/driver-api/usb/error-codes.rst

@@ -1,3 +1,5 @@
+.. _usb-error-codes:
+
 USB Error codes
 USB Error codes
 ~~~~~~~~~~~~~~~
 ~~~~~~~~~~~~~~~
 
 

+ 2 - 0
Documentation/driver-api/usb/persist.rst

@@ -1,3 +1,5 @@
+.. _usb-persist:
+
 USB device persistence during system suspend
 USB device persistence during system suspend
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 

+ 1 - 1
Documentation/driver-api/usb/power-management.rst

@@ -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

+ 2 - 2
Documentation/driver-api/usb/usb.rst

@@ -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
-``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
 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

+ 1 - 1
Documentation/power/swsusp.txt

@@ -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?
 
 

+ 1 - 1
drivers/staging/most/hdm-usb/hdm_usb.c

@@ -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)
 {
 {

+ 1 - 1
drivers/usb/core/Kconfig

@@ -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.