Re: Possible OHCI driver bug ?

> 
> On Wed, 24 Oct 2007, Anantha Subramanyam wrote:
> 
> >             if (tick_before (tick, ed->tick)) {   <------ this check
> > always true if ed->tick is 0x7FFF
> > skip_ed:
> >                 last = &ed->ed_next;
> >                 continue;
> >             }
> >  
> > 
> > ohci-hub.c:
> > #define tick_before(t1,t2) ((((s16)(t1))-((s16)(t2))) < 0)
> 
> Looks to me like you are right; the macro definition is messed up.  
> You could try changing it to this:
> 
> #define tick_before(t1,t2)	((s16)((t1) - (t2)) < 0)
> 
That should work, won't have access to the test system for a while
though to try that (if needed)

> 
> > Since the tick_before condition always returns true, this 
> 'ed' is never
> > removed for processing and hence the timeout. For trying 
> out the above
> > condition was changed to :
> >             if (tick == ed->tick)) {    
> > skip_ed:
> >                 last = &ed->ed_next;
> >                 continue;
> >             }
> 
> No, don't do that!  You are replacing something wrong with something 
> else even more wrong.
> 
Just curious about why this would be wrong. Thought the objective of
this test was to just ensure that the tick value at this interrupt was
later than ed->tick. Considering that tick is always increasing
sequentially wouldn't this test suffice.

Thanks

Ananth



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel