Instead of fixing actual_length and setting status to 0, let's make sure
the error is propagated and we print a big scary stack trace so errors
are reported and we have a chance of fixing them.
While at that, also remove unnecessary initialization of urb variable.
Signed-off-by: Felipe Balbi <felipe.ba...@linux.intel.com>
---
drivers/usb/host/xhci-ring.c | 20 ++++++++------------
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 1e1b54d077e2..1fee418b4fb3 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1787,7 +1787,10 @@ static int xhci_td_cleanup(struct xhci_hcd *xhci, struct
xhci_td *td,
struct xhci_ring *ep_ring, int *status)
{
struct urb_priv *urb_priv;
- struct urb *urb = NULL;
+ struct device *dev;
+ struct urb *urb;
+
+ dev = xhci_to_hcd(xhci)->self.controller;
/* Clean up the endpoint's TD list */
urb = td->urb;
@@ -1796,17 +1799,10 @@ static int xhci_td_cleanup(struct xhci_hcd *xhci,
struct xhci_td *td,
/* if a bounce buffer was used to align this td then unmap it */
xhci_unmap_td_bounce_buffer(xhci, ep_ring, td);
- /* Do one last check of the actual transfer length.
- * If the host controller said we transferred more data than the buffer
- * length, urb->actual_length will be a very big number (since it's
- * unsigned). Play it safe and say we didn't transfer anything.
- */
- if (urb->actual_length > urb->transfer_buffer_length) {
- xhci_warn(xhci, "URB req %u and actual %u transfer length
mismatch\n",
- urb->transfer_buffer_length, urb->actual_length);
- urb->actual_length = 0;
- *status = 0;
- }
+ dev_WARN_ONCE(dev, urb->actual_length > urb->transfer_buffer_length,
+ "URB transfer length mismatch. Requested %u got %u\n",
+ urb->transfer_buffer_length, urb->actual_length);
+
list_del_init(&td->td_list);
/* Was this TD slated to be cancelled but completed anyway? */
if (!list_empty(&td->cancelled_td_list))
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
