On Friday 01 February 2008, Greg Kroah-Hartman wrote:
> From: Marcin Slusarz <[EMAIL PROTECTED]>
>
> fix warning:
> drivers/usb/host/ehci-hcd.c:832:8: warning: symbol 'status' shadows an
> earlier one
> drivers/usb/host/ehci-hcd.c:790:71: originally declared here
>
> Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
I was wondering why my "sparse" patch didn't get merged, and this
patch explains why! :)
However, see the following.
========= CUT HERE
The previous fix for a "sparse" warning in ehci_urb_dequeue() was
incorrect. After rescheduling interrupt transfers it returned the
URB's completion status, not status for the dequeue operation itself.
This patch resolves that issue, cleans up the code in the reschedule
path, and shrinks the object code by a dozen bytes.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/usb/host/ehci-hcd.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
--- g26.orig/drivers/usb/host/ehci-hcd.c 2008-02-02 02:00:51.000000000
-0800
+++ g26/drivers/usb/host/ehci-hcd.c 2008-02-02 02:29:19.000000000 -0800
@@ -833,18 +833,18 @@ static int ehci_urb_dequeue(struct usb_h
/* reschedule QH iff another request is queued */
if (!list_empty (&qh->qtd_list)
&& HC_IS_RUNNING (hcd->state)) {
- int schedule_status;
+ rc = qh_schedule(ehci, qh);
- schedule_status = qh_schedule (ehci, qh);
- spin_unlock_irqrestore (&ehci->lock, flags);
-
- if (schedule_status != 0) {
- // shouldn't happen often, but ...
- // FIXME kill those tds' urbs
- err ("can't reschedule qh %p, err %d",
- qh, schedule_status);
- }
- return status;
+ /* An error here likely indicates handshake failure
+ * or no space left in the schedule. Neither fault
+ * should happen often ...
+ *
+ * FIXME kill the now-dysfunctional queued urbs
+ */
+ if (rc != 0)
+ ehci_err(ehci,
+ "can't reschedule qh %p, err %d",
+ qh, rc);
}
break;
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
