On Wed, 26 May 2004, Alan Stern wrote: > Maybe you were checking connect-status-change only, and not also checking > connect-status. I don't see how checking both bits could hurt. If the > connect-status-change bit is being activated then you don't want to claim > the connection is debounced. > > The only possible way this 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.
Well, can we always trust the way how hubs report connect status and changes? I think there is a race in the hub controller when detecting port connection changes in parallel to ep0 status requests. To me it's not clear from the usb specs whether there are timing requirements wrt. port status requests. It's just speculation but what if we read the port status faster than expected by the hub leading to some inconsistency? Another race is due to the window between the point where the hub drivers sees the connect-status-change bit set and the corresponding clear-port-feature takes effect. If there is another bounce in this window, we will not get another status change indication in the next request, but the status might be changed (or not, if fast bounce+rebounce) regardless. Martin ------------------------------------------------------- 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
