mirror of
https://github.com/hathach/tinyusb.git
synced 2025-01-17 05:32:55 +08:00
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.
This commit is contained in:
parent
069e1ef84f
commit
8ad024e51b
@ -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
|
||||
|
Loading…
x
Reference in New Issue
Block a user