Correct format of function names like the following example:
"`usb_bulk_msg` function" to "usb_bulk_msg()"
Signed-off-by: Philipp Hortmann <philipp.g.hortmann@xxxxxxxxx>
---
.../driver-api/usb/writing_usb_driver.rst | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/Documentation/driver-api/usb/writing_usb_driver.rst b/Documentation/driver-api/usb/writing_usb_driver.rst
index 1968cf5c55f6..9f4181cafc41 100644
--- a/Documentation/driver-api/usb/writing_usb_driver.rst
+++ b/Documentation/driver-api/usb/writing_usb_driver.rst
@@ -220,10 +220,10 @@ successfully or not and then returns.
This read function works a bit differently from the write function in
that we do not use an urb to transfer data from the device to the
-driver. Instead we call the :c:func:`usb_bulk_msg` function, which can be used
+driver. Instead we call usb_bulk_msg(), which can be used
to send or receive data from a device without having to create urbs and
-handle urb completion callback functions. We call the :c:func:`usb_bulk_msg`
-function, giving it a buffer into which to place any data received from
+handle urb completion callback functions. We call usb_bulk_msg(),
+giving it a buffer into which to place any data received from
the device and a timeout value. If the timeout period expires without
receiving any data from the device, the function will fail and return an
error message. This can be shown with the following code::
@@ -244,13 +244,13 @@ error message. This can be shown with the following code::
}
-The :c:func:`usb_bulk_msg` function can be very useful for doing single reads
+usb_bulk_msg() can be very useful for doing single reads
or writes to a device; however, if you need to read or write constantly to
a device, it is recommended to set up your own urbs and submit them to
the USB subsystem. The template uses urbs for read and write.
When the user program releases the file handle that it has been using to
-talk to the device, the release function in the driver is called. In
+talk to the device, skel_release() in the driver is called. In
this function we decrement our private usage count and wait for possible
pending writes::
@@ -262,9 +262,8 @@ One of the more difficult problems that USB drivers must be able to
handle smoothly is the fact that the USB device may be removed from the
system at any point in time, even if a program is currently talking to
it. It needs to be able to shut down any current reads and writes and
-notify the user-space programs that the device is no longer there. The
-following code (function ``skel_delete``) is an example of how to do
-this::
+notify the user-space programs that the device is no longer there.
+skel_delete() is an example of how to do this::
static void skel_delete(struct kref *kref)
{
@@ -283,8 +282,8 @@ is initialized and set to false. For every read, write and other
functions that expect a device to be present, the driver first checks
this flag to see if the device is still present. If not, a ``-ENODEV``
error is returned to the user-space program. When the device is
-disconnected, the ``skel_disconnect`` function is called. It sets
-``disconnected`` to true and cleans up.
+disconnected, skel_disconnect() is called. It sets ``disconnected``
+to true and cleans up.
Isochronous Data
================
--
2.25.1
