From 8ad024e51bbc663678d8a357f91021bd39222246 Mon Sep 17 00:00:00 2001 From: Ivo Popov Date: Sun, 9 Apr 2023 19:10:01 -0400 Subject: [PATCH] Even when we get an empty "status change" interrupt from the hub, schedule another interrupt poll. During enumeration, when there are multiple devices attached to the hub as it's plugged into the Pi Pico, enumeration hangs, because we get a "status change" callback with value zero. With this patch, we retry several times on "zero" status change callbacks, until eventually we succeed. This is the cheapo hub that exhibits this behavior, but I assume it's not the only one: https://www.amazon.com/gp/product/B083RQMC7S. While debugging this, I consulted the implementation in the Linux kernel. There, hub setup explicitly checks each port individually, before starting to depend on "status change" interrupts: https://elixir.bootlin.com/linux/latest/source/drivers/usb/core/hub.c#L1133. We probably should do something like that here, but it's a much bigger change. --- src/host/hub.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/host/hub.c b/src/host/hub.c index 85bf22b3e..5b2db547d 100644 --- a/src/host/hub.c +++ b/src/host/hub.c @@ -361,6 +361,13 @@ bool hub_xfer_cb(uint8_t dev_addr, uint8_t ep_addr, xfer_result_t result, uint32 break; } } + + // The status change event was neither for the hub, nor for any of + // its ports. (For example `p_hub->status_change == 0`.) This + // shouldn't happen, but it does with some devices. Initiate the + // next interrupt poll here, because we've scheduled no other work + // whose completion can initiate it. + hub_edpt_status_xfer(dev_addr); } // NOTE: next status transfer is queued by usbh.c after handling this request