On Wed, 26 May 2004, Martin Diehl wrote: > On Wed, 26 May 2004, Alan Stern wrote: > > > I think it wouldn't hurt to change two aspects of this routine. The first > > is simple: Nils Faerber has requested that the HUB_DEBOUNCE_TIMEOUT value > > be increased from 400 ms to 1500 ms. That wouldn't affect normal stable > > connections but it would give slightly flaky devices a better chance of > > connecting properly. > > IMHO this should be safe without surprise. I'm just wondering how long it > might take to enumerate a tree of such flaky guys - maybe the hub driver > might start to enumerate different ports in parallel ;-)
People have talked about doing that. I'm sure it won't happen for quite a while... Anyway, a machine will most likely have only one such flaky device attached. > > The second is to treat connect-change status properly -- make it reset the > > stable_count value back to 0. The way it is now, if the connection status > > is unstable and drops & returns within a 25 ms period, the routine won't > > realize that anything has happened. > > This might break! While I agree your suggestion sounds right, I'm a bit > worried: I need to look it up, but IIRC my original approach _was_ to > check the hub connect status _change_ bit being inactive for 100 ms. If > my memory didn't left me this failed with some devices for some reason. I > don't remember the details and it was somebody else who made the changes > because I have no such flaky device. Maybe Pete knows better - but given > the history of this issue I would be very careful changing the way how > connection status detection works (kind of...). 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. 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
