On Wed, 26 May 2004, Alan Stern wrote: > On Tue, 25 May 2004, Pete Zaitcev wrote: > > > On Tue, 25 May 2004 16:43:53 -0400 (EDT) > > Alan Stern <[EMAIL PROTECTED]> wrote: > > > > > P.P.S.: The hub_port_debounce() function doesn't behave as one would > > > expect from the comments at the top. I trust no one will object if I > > > rewrite it to make the routine do what it's supposed to do? > > > > Please elaborate. It took quite a bit of effort to make it work, > > the story started way in 2.1 times. It's not a function which you > > should be rewriting just because you feel like it. > > On Tue, 25 May 2004, Greg KH wrote: > > > I will object. As Pete said, that function has gone through a lot of > > testing and tweaking over time. I would trust the code, not the > > comments there. > > Okay, I won't change any code without discussion. The comments could > stand to be clarified though; would anybody mind that?
Nope. I think this are still the comments from me when I first introduced the debounce handling. Most of the original code was changed to deal with the real world issues later on as pointed out by Pete. > 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 ;-) > 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...). 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
