On Wed, 6 Nov 2002, Pete Zaitcev 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. > > > 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.
Right - we would just bail out there with any device just in case we see some transient STAT_CONNECTION during the debounce delay, i.e. probably way too early. OTOH the HUB_DEBOUNCE_STEP is already 100msec here which should be sufficiently long for most devices to have the connect settled. > 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. The 400ms delay was there, right - but only for low speed devices. Full and highspeed devices had no delay at all which was a clear violation of the specs. USB (see the comment on top of said function for the exact reference) grants 100ms for the device and hub to agree about the connect becoming stable. We know there are devices in the field which don't conform to this requirement. This is why the delay was increased to 400ms. It doesn't hurt that much for conforming devices and should also work around most nonconforming. As you've noticed this also ensures nothing would break if it was working with the old 400ms for lowspeed delay, because the 400ms are a lower bound now. > The resetting of delay_time in case of change bit present > also looks bogus, because it has not high bound. That's what the specs say: whenever we detect a transient disconnect before the debounce timer expires, the timer must be restarted. Right, we have no limit here. OTOH, if a devices doesn't manage to get a stable connect state after some time, it will never be useable and, even worse, likely cause considerable trouble to other devices on the bus. The obvious solution in this situation is to disconnect the device. This would both remove the offender and exit the debounce loop due to portstatus becoming stable ~STAT_CONNECTION. IIRC we discussed this with Greg at that time and he agreed with this approach. > All in all, the patch above is garbage, but the routine is > dubious on two counts and I would like the author to comment. Hereby done ;-) As for the original poster's problem, the first thing I would try is to increase the overall HUB_DEBOUNCE_TIMEOUT. Maybe this devices needs even more than 400ms. Furthermore, there are only two possibilities how the debounce routine could exit with error return: either there was a real error when trying to read the portstatus from the controlling hub or we had the debounce timeout completed (i.e. the hub reported no connection change during the last 400ms) but with the port being in disconnected state all that time. Maybe we could improve what we do in both cases: * If we fail to get the portstatus (which error?) it's probably worth to ignore the error (increment some error counter with upper bound) and simply assume there was a transient change, i.e. just go on debouncing with the timer restarted. * If we finish debouncing because the portstatus appears stable during the last HUB_DEBOUNCE_TIMEOUT but the port appears disconnected at this point we could just try another (longer) debouncing. This would also allow to shorten the normal first try to 100ms as said by the spec and let the second one catch all the slower devices - say additional 500ms or even more. This would speed up the enumeration for conforming devices and add more patience for nonconforming. OTOH, if we just replace the whole debouncing by a fixed 400ms delay (for all speeds!) we are risking to hide the symptoms: if a port doesn't report a stable connection after 400ms and we ignore this (...because there was enough waiting), we'll end up with enumeration likely running into trouble now with SetAddress or GetDescriptor requests. Martin ------------------------------------------------------- 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
