Hi Jerome, On Wed, 19 Mar 2025 at 11:44, Jerome Forissier <jerome.foriss...@linaro.org> wrote: > > Hello Marek, > > On 3/18/25 13:20, Marek Vasut wrote: > > On 3/18/25 11:46 AM, Jerome Forissier wrote: > >> To prepare for the introduction of threads in the USB initialization > >> sequence, move code out of usb_init() into a new helper function: > >> usb_init_bus(). No functional change. > >> > >> Signed-off-by: Jerome Forissier <jerome.foriss...@linaro.org> > >> Reviewed-by: Ilias Apalodimas <ilias.apalodi...@linaro.org> > >> --- > >> drivers/usb/host/usb-uclass.c | 88 +++++++++++++++++++---------------- > >> 1 file changed, 48 insertions(+), 40 deletions(-) > >> > >> diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c > >> index bfec303e7af..cc803241461 100644 > >> --- a/drivers/usb/host/usb-uclass.c > >> +++ b/drivers/usb/host/usb-uclass.c > >> @@ -287,9 +287,55 @@ static int usb_probe_companion(struct udevice *bus) > >> return 0; > >> } > >> +static int controllers_initialized; > > I'm afraid this won't work, you will have to track the controllers in a > > list somehow, because it is possible to unbind DM devices even using the > > 'unbind' command from U-Boot command line. > > > > Also, why not simply track the controller state using DM in the first place? > > I'll keep controllers_initialized local to usb_init() and use device_active() > in the second uclass_foreach_dev() loop.
Could you please take a bit of a look at collecting the USB-scanning state into a struct? We should be able to call it using iteration: struct usb_iter iter; usb_iter_init(&iter); usb_iter_process() It could collect all the devices it finds into an alist and then the caller can take a look. The reason I am keen on this is that it will potentially allow removal of the time delays in the USB stack, so we can deal with sticks which take longer to respond. I may have this wrong, but it seems that the primary delay is in usb_urb_submit(). So what we really need is an usb_urb_async() which enqueues the urb and then another method to poll it. That would perhaps allow much faster USB since all devices would be scanning in parallel, including individual devices on the same hub. Turning the USB stack 'inside out' is how I've made bootstd work. I means that devices which are found can be reported as they are found and we can potentially wait a long time for the long-tail devices, while still returning immediately to the cmdline so the user can continue. Regards, Simon