> Date: Wed, 6 Nov 2002 18:24:31 -0500
> From: Johannes Erdfelt <[EMAIL PROTECTED]>
> > 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.
I happen to agree with you that we ought not to waste 400ms
if there is an other way. I was just pointing out that the
current debounce routine continues to waste those 400m.
I would understand if we had the loop written like this:
#define HUB_DEB_TOUT 400
#define HUB_DEB_STEP 30 // small enough for stable counts to make sense
connection = 0;
stable_count = 0;
for (delay_time = 0; delay_time < HUB_DEB_TOUT; delay_time += HUB_DEB_STEP) {
wait_ms(HUB_DEBOUNCE_STEP);
ret = usb_hub_port_status(hub, port, &portstatus, &portchange);
if ((portstatus & USB_PORT_STAT_CONNECTION) == connection) {
if (++stable_count == 3) /* Does not seem to bounce, proceed */
break;
} else {
stable_count = 0; /* Bitch bounces */
}
connection = portstatus & USB_PORT_STAT_CONNECTION;
if (portchange & USB_PORT_STAT_C_CONNECTION) {
usb_clear_port_feature(hub, port+1, USB_PORT_FEAT_C_CONNECTION);
}
}
But no, this is not what it does either.
-- Pete
-------------------------------------------------------
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
