On Thu, 27 May 2004, Alan Stern wrote: > On Thu, 27 May 2004, Martin Diehl wrote: > > > 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? > > Races and inconsistencies shouldn't matter. If the status changes at just > about the same time as we read the status, it won't hurt anything if the > change isn't reported until the _next_ time we read the status. And even > if it is never reported at all, we'll be no worse off than we are now. > > As far as timing requirements... I don't know about any hubs in > particular, but in general a USB device is expected to be able to handle a > control request at any time, either by carrying it out or replying with > NAK or STALL. Anyway, the current code already issues the status > requests; my patch just changes the way we interpret the response.
Correct. I was just trying to imagine what might happen in case of unexpected behavior. I'm by no means objecting your patch - it's just it might be the current interpretation could be the best working which was found so far due to such issues. I just think if all devices would behave according to the specs the debounce approach would have worked in the first place and we could drop the longer timeout completely. Something must be different in real life therefore. > > 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. > > That race doesn't matter either. The code resets the counter to 0, so > even if we did know there was a connect-status-change during that window > we wouldn't have to do anything about it. Ok, you are right, we won't entirely miss the connect change. I still think when we assume 100ms stable_time this might be too early in some pathological cases (say fast disconnect-connect cycle after about 80 ms racing with clear_port_feature) but I believe these will be handled by the timeout then. Note, I was just trying to explain what I remember about the long history of this stuff - personally I don't care much since I'll always get my devices enumerated ;-) But if your patch worked as well as the existing code or even better, it'd obviously be good to have it applied. 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
