I admit it might be a hardware problem. As I said in another mail, I
couldn't duplicate the problem on other computers...
If that's true than I'm sorry for bothering you.
2012/4/26 Greg KH <greg@xxxxxxxxx>:
> 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
