On Tue, 4 Jun 2013, Ming Lei wrote:
> > Index: usb-3.9/drivers/usb/host/ehci-sched.c
> > ===================================================================
> > --- usb-3.9.orig/drivers/usb/host/ehci-sched.c
> > +++ usb-3.9/drivers/usb/host/ehci-sched.c
> > @@ -646,6 +646,10 @@ static void end_unlink_intr(struct ehci_
> > /* reschedule QH iff another request is queued */
> > if (!list_empty(&qh->qtd_list) && ehci->rh_state == EHCI_RH_RUNNING) {
> > rc = qh_schedule(ehci, qh);
> > + if (rc == 0) {
> > + qh_refresh(ehci, qh);
> > + qh_link_periodic(ehci, qh);
> > + }
>
> If one URB is just submitted during end_unlink_intr(), the qh may be scheduled
> and linked twice since intr_submit() has seen idle state of the qh already.
No, that can't happen. The only time that ehci->lock is released while
end_unlink_intr() is running is during the giveback in qh_completions.
During that time, qh->qh_state is temporarily set to
QH_STATE_COMPLETING. Therefore the qh will not be linked before this
new code runs.
Alan Stern
> I guess one interrupt URB is just submitted after starting unlink and before
> end unlinking on Oleksij's problem, this patch can addresses the problem
> but might cause issues on above case.
>
> Looks one easy fix might be updating qh as idle after calling qh_completions().
>
> Thanks,
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
