On Mon, 18 Feb 2002, Greg KH wrote:
> Here's the 2.4 version of the patch. Anyone have any problems with it?
>
> How about the time delay patch on top of this patch Martin?
OK, I've updated it for 2.4.18-rc2, applies after the usb_port_status
thing. Debounce delay is now 400ms, which seems to be sufficient for
different problematic devices like some bluetooth dongles. And I've
removed the low-speed special delay (RHbug #23670) because we have now
an unconditional delay of 400ms at least which should make it obsolete.
But I have no device which would really need this for serious testing
- my Logitech mouse is happy either way.
I've done some additional testing with a device doing loops of connect-
disconnect-cycles with 50ms interval forever - just to see what would
happen to khubd in an extremely noisy situation: as expected, khubd gets
livelocked in the debounce loop and no further disconnect or connect event
from other ports are reported to usbcore. Once the bad-behaving guy gets
unplugged the queued events are delivered and everything works as usual.
Johannes, Pete - if it's ok for you I'd like to suggest this could go into
early 2.4.19-pre series.
Greg, AFAICS the only change required for application to 2.5.5-pre1 is:
-static void usb_hub_port_connect_change(struct usb_device *hub, int port,
+static void usb_hub_port_connect_change(struct usb_hub *hubstate, int port,
in the 1st hunk's trailing context - so I assume it's ok not to duplicate?
Martin
----------------
--- v2.4.18-rc2-md/drivers/usb/hub.c.portsts Tue Feb 19 15:38:21 2002
+++ v2.4.18-rc2-md/drivers/usb/hub.c Tue Feb 19 17:30:46 2002
@@ -609,6 +609,49 @@
port + 1, hub->devnum, ret);
}
+/* USB 2.0 spec, 7.1.7.3 / fig 7-29:
+ *
+ * Between connect detection and reset signaling there must be a delay
+ * of 100ms at least for debounce and power-settling. The corresponding
+ * timer shall restart whenever the downstream port detects a disconnect.
+ *
+ * Apparently there are some bluetooth and irda-dongles and a number
+ * of low-speed devices which require longer delays of about 200-400ms.
+ * Not covered by the spec - but easy to deal with.
+ *
+ * This implementation uses 400ms minimum debounce timeout and checks
+ * every 10ms for transient disconnects to restart the delay.
+ */
+
+#define HUB_DEBOUNCE_TIMEOUT 400
+#define HUB_DEBOUNCE_STEP 10
+
+/* return: -1 on error, 0 on success, 1 on disconnect. */
+static int usb_hub_port_debounce(struct usb_device *hub, int port)
+{
+ int ret;
+ unsigned delay_time;
+ u16 portchange, portstatus;
+
+ for (delay_time = 0; delay_time < HUB_DEBOUNCE_TIMEOUT; /* empty */ ) {
+
+ /* wait debounce step increment */
+ wait_ms(HUB_DEBOUNCE_STEP);
+
+ ret = usb_hub_port_status(hub, port, &portstatus, &portchange);
+ if (ret < 0)
+ return -1;
+
+ if ((portchange & USB_PORT_STAT_C_CONNECTION)) {
+ usb_clear_port_feature(hub, port+1,
+USB_PORT_FEAT_C_CONNECTION);
+ delay_time = 0;
+ }
+ else
+ delay_time += HUB_DEBOUNCE_STEP;
+ }
+ return ((portstatus&USB_PORT_STAT_CONNECTION)) ? 0 : 1;
+}
+
static void usb_hub_port_connect_change(struct usb_device *hub, int port,
u16 portstatus, u16 portchange)
{
@@ -635,11 +678,10 @@
return;
}
- /* Some low speed devices have problems with the quick delay, so */
- /* be a bit pessimistic with those devices. RHbug #23670 */
- if (portstatus & USB_PORT_STAT_LOW_SPEED) {
- wait_ms(400);
- delay = HUB_LONG_RESET_TIME;
+ if (usb_hub_port_debounce(hub, port)) {
+ err("connect-debounce failed, port %d disabled", port+1);
+ usb_hub_port_disable(hub, port);
+ return;
}
down(&usb_address0_sem);
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
