On Wed, Nov 06, 2002, Pete Zaitcev <[EMAIL PROTECTED]> wrote: > > From: Michal Cihar <[EMAIL PROTECTED]> > > Date: Wed, 06 Nov 2002 09:59:55 +0100 > > > I was having problems with my usb device, that failed with "hub.c: > > connect-debounce failed, port N disabled". [...] > > > Problems seems to be in clearing USB_PORT_STAT_CONNECTION flag after it > > is being read once. Don't ask me why, but thats what I find out.
What device is this? It sounds horribly broken if it clears STAT_CONNECTION when there is a device connected. > > Following patch fixes this and IMHO should break anything else (it just > > leaves debounce look if device seems to be connected). > > > --- linux-2.4.19-orig/drivers/usb/hub.c 2002-09-10 15:25:42.000000000 +0200 > > +++ linux/drivers/usb/hub.c 2002-09-11 11:12:04.000000000 +0200 > > @@ -655,6 +655,7 @@ > > } > > else > > delay_time += HUB_DEBOUNCE_STEP; > > + if (portstatus&USB_PORT_STAT_CONNECTION) return 0; > > } > > return ((portstatus&USB_PORT_STAT_CONNECTION)) ? 0 : 1; > > } > > I saw this patch floating around internally, and IIRC I was > able to ignore it until the user changed his cabling. > It defeats the purpose of the whole debouncing routine completely. > Not that the said routine makes a lot of sense otherwise. > > Interestingly, JE was up in arms against a simple 400ms delay > in this place, which always worked before. Now, someone came > with the debonce routine and lo and behold: it always delays > for the same 400ms -- the loop has no early break! So, why > don't we just restore the delay? It worked just fine in 2.2 kernel. I just wanted to make sure there was a way other than penalizing every device. Unfortunately, I have no devices that exhibit this problem, so I had to go on the word of other people. It was my understanding that this patch goes above and beyond the patch you had to catch some additionally broken devices. > The resetting of delay_time in case of change bit present > also looks bogus, because it has not high bound. Yes, I was just noticing that too. > All in all, the patch above is garbage, but the routine is > dubious on two counts and I would like the author to comment. I'll see if I have the email in my archives. I forget who originally wrote this patch. JE ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
