On Wed, 26 May 2004, Pete Zaitcev wrote: > On Wed, 26 May 2004 15:07:46 -0400 (EDT) > Alan Stern <[EMAIL PROTECTED]> wrote: > > > The only possible way this [checking both S and C bits --P3] > > could cause something that was working to break > > would be if the connect-status-change bit keeps flickering even for a > > stable debounced connection. But if that were to happen, then the current > > code would view it as signalling another connect-change event -- so things > > wouldn't work regardless. > > This logics seems sold when we consider how hub_events() operates > and besides I do not remember the precise failure scenario anymore. > However... what is that exactly you are trying to fix here?
Mainly to fix the comments :-) But also, as long as the connect-status-change information is available (even if not 100% reliable) I think we should use it. It does close a loophole in the driver -- transient disconnects lasting less than 25 ms currently do not reset the timer as they should. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
