staging: most: usb: remove reference to USB error codes

This patch removes the reference to the driver API file for USB error
codes.

Signed-off-by: Christian Gromm <christian.gromm@microchip.com>
Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/1589534465-7423-3-git-send-email-christian.gromm@microchip.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

diff --git a/drivers/staging/most/usb/usb.c b/drivers/staging/most/usb/usb.c
index 85d4fa0..dbb6003 100644 (file)
--- a/drivers/staging/most/usb/usb.c
+++ b/drivers/staging/most/usb/usb.c
@@ -382,103 +382,6 @@ static void hdm_write_completion(struct urb *urb)
  * padding bytes -if necessary- and calls the completion function.
  *
  * Context: interrupt!
- *
- * **************************************************************************
- *                   Error codes returned by in urb->status
- *                   or in iso_frame_desc[n].status (for ISO)
- * *************************************************************************
- *
- * USB device drivers may only test urb status values in completion handlers.
- * This is because otherwise there would be a race between HCDs updating
- * these values on one CPU, and device drivers testing them on another CPU.
- *
- * A transfer's actual_length may be positive even when an error has been
- * reported.  That's because transfers often involve several packets, so that
- * one or more packets could finish before an error stops further endpoint I/O.
- *
- * For isochronous URBs, the urb status value is non-zero only if the URB is
- * unlinked, the device is removed, the host controller is disabled or the total
- * transferred length is less than the requested length and the URB_SHORT_NOT_OK
- * flag is set.  Completion handlers for isochronous URBs should only see
- * urb->status set to zero, -ENOENT, -ECONNRESET, -ESHUTDOWN, or -EREMOTEIO.
- * Individual frame descriptor status fields may report more status codes.
- *
- *
- * 0                   Transfer completed successfully
- *
- * -ENOENT             URB was synchronously unlinked by usb_unlink_urb
- *
- * -EINPROGRESS                URB still pending, no results yet
- *                     (That is, if drivers see this it's a bug.)
- *
- * -EPROTO (*, **)     a) bitstuff error
- *                     b) no response packet received within the
- *                        prescribed bus turn-around time
- *                     c) unknown USB error
- *
- * -EILSEQ (*, **)     a) CRC mismatch
- *                     b) no response packet received within the
- *                        prescribed bus turn-around time
- *                     c) unknown USB error
- *
- *                     Note that often the controller hardware does not
- *                     distinguish among cases a), b), and c), so a
- *                     driver cannot tell whether there was a protocol
- *                     error, a failure to respond (often caused by
- *                     device disconnect), or some other fault.
- *
- * -ETIME (**)         No response packet received within the prescribed
- *                     bus turn-around time.  This error may instead be
- *                     reported as -EPROTO or -EILSEQ.
- *
- * -ETIMEDOUT          Synchronous USB message functions use this code
- *                     to indicate timeout expired before the transfer
- *                     completed, and no other error was reported by HC.
- *
- * -EPIPE (**)         Endpoint stalled.  For non-control endpoints,
- *                     reset this status with usb_clear_halt().
- *
- * -ECOMM              During an IN transfer, the host controller
- *                     received data from an endpoint faster than it
- *                     could be written to system memory
- *
- * -ENOSR              During an OUT transfer, the host controller
- *                     could not retrieve data from system memory fast
- *                     enough to keep up with the USB data rate
- *
- * -EOVERFLOW (*)      The amount of data returned by the endpoint was
- *                     greater than either the max packet size of the
- *                     endpoint or the remaining buffer size.  "Babble".
- *
- * -EREMOTEIO          The data read from the endpoint did not fill the
- *                     specified buffer, and URB_SHORT_NOT_OK was set in
- *                     urb->transfer_flags.
- *
- * -ENODEV             Device was removed.  Often preceded by a burst of
- *                     other errors, since the hub driver doesn't detect
- *                     device removal events immediately.
- *
- * -EXDEV              ISO transfer only partially completed
- *                     (only set in iso_frame_desc[n].status, not urb->status)
- *
- * -EINVAL             ISO madness, if this happens: Log off and go home
- *
- * -ECONNRESET         URB was asynchronously unlinked by usb_unlink_urb
- *
- * -ESHUTDOWN          The device or host controller has been disabled due
- *                     to some problem that could not be worked around,
- *                     such as a physical disconnect.
- *
- *
- * (*) Error codes like -EPROTO, -EILSEQ and -EOVERFLOW normally indicate
- * hardware problems such as bad devices (including firmware) or cables.
- *
- * (**) This is also one of several codes that different kinds of host
- * controller use to indicate a transfer has failed because of device
- * 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/driver-api/usb/error-codes.rst>
  */
 static void hdm_read_completion(struct urb *urb)
 {