This patch removes the reference to the driver API file for USB error
codes.
Signed-off-by: Christian Gromm <christian.gr...@microchip.com>
Reported-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
v2:
removed copied USB error code section
drivers/staging/most/usb/usb.c | 97 ------------------------------------------
1 file changed, 97 deletions(-)
diff --git a/drivers/staging/most/usb/usb.c b/drivers/staging/most/usb/usb.c
index 85d4fa0..dbb6003 100644
--- 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)
{
--
2.7.4
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
