Host: Add support for multi-level usb hubs

[Ryzee119]

Describe the PR

• Add support for multiple levels of USB hubs in the usb host stack. For your consideration Hathach 😄

To get this working reliably I had to relax the assert on failed port_status control transfer. Currently with multiple hubs it may perform a control xfer if the ctrl buffer is busy.

Additional context

1. Developed on imxrt (Teensy41) with EHCI.
2. Tested with 3 USB hubs levels, combination of low speed and full speed devices. (HID devices) Not tested with Bulk or Iso but this is not expected to be different from upstream.
3. Quite susceptible to 5V rail supply issues. So an externally powered usb hub is recommended.

Known issues

1. If you unplug a downstream hub, it will hit this assert which makes sense and can easily be fixed by relaxing this assert to a TU_VERIFY, but not included in this PR. I think this assert is quite strict as is, but will leave for feedback.
   

   tinyusb/src/host/hub.c

   Line 324 in f4efb51

   TU_ASSERT(result == XFER_RESULT_SUCCESS);

May help to review on a per commit basis.

Below is a working log of 2 daisy chained usb hubs, with 3 usb drives connected. One drive in the first hub, 2 in the 2nd hub.
After enumeration of all 5 devices, I unplug the root hub so you can see all downstream devices disconnected successfully.
multihub-log.txt

Thanks for this great USB stack 🚀

[Ryzee119]

I can hit issues if we disconnect a device from a hub when we are enumerating another device, the hub status control transfer will begin, then we'll assert in enumeration due to a busy control buffer.

I think there's a few conflicts with hub, enumerating and control buffers to be resolved still for this to be very resilient.

[hathach]

Superb ! thank you very much for your effort and patience. I have tested with mcb1800 (same chipidea controller as imxrt) and it works like a charm. The recursive call to process unplugged hub device is working but not a great approach in long term IMHO. I make an commit to add FIXME to this and also make an issue for reminder as well. Thanks again for your work.

PS: finally I could hide the fact that I am lazy to support this :)
PSS: #1511 is created

[hathach]

indeed, for compatibility, usbh only carry 1 control transfer at a time since unlike ehci most custom host is rather limited. Currently there is no control queue and when the control is busy, usbh simply return false for try-again.

[hathach]

an recursive call in limited MCU can cause stack overflow. Though I am ok with this initial support. In long run, we should find an way to un-roll the recursive chain. After all, the device loop is rather small (4-10) only.