On Thu, Apr 26, 2012 at 11:16:17AM -0400, Alan Stern wrote:
> On Thu, 26 Apr 2012, Greg KH wrote:
>
> > On Thu, Apr 26, 2012 at 10:25:41AM -0400, Alan Stern wrote:
> > > On Thu, 26 Apr 2012, Calin Demian wrote:
> > >
> > > > I don't know how, but adding the following line in function
> > > > quirk_usb_handoff_ohci makes the system work fine:
> > > >
> > > > /* reset requires max 10 us delay */
> > > > + udelay(1);
> > > > for (cnt = 30; cnt > 0; --cnt) { /* ... allow extra time */
> > > > if ((readl(base + OHCI_CMDSTATUS) & OHCI_HCR) == 0)
> > > >
> > > > I observed thad the condition in the for loop is allways true, so the
> > > > delay inside the loop is never executed.
> >
> > That implies that something is wrong with the complier here, and it
> > optimized out the loop? Are you sure that really happened?
>
> Here's the complete context:
>
> /* reset requires max 10 us delay */
> for (cnt = 30; cnt > 0; --cnt) { /* ... allow extra time */
> if ((readl(base + OHCI_CMDSTATUS) & OHCI_HCR) == 0)
> break;
> udelay(1);
> }
>
> I think Calim means that the "(readl(base + OHCI_CMDSTATUS) & OHCI_HCR)
> == 0" test succeeds on the first pass through the loop, so we break out
> early and the udelay(1) statement never gets executed.
Ok, but if the readl() succeeds, then all should be fine?
Ah, unless the hardware is really lying, but no, that would never
happen, right?
Nevermind,
greg k-h
--
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
