[PATCH v4 10/14] dm: usb: move bus initialization into new static function usb_init_bus()

[Simon Glass]

Hi Jerome,

On Wed, 19 Mar 2025 at 11:44, Jerome Forissier
<jerome.forissier at 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.forissier at linaro.org>
> >> Reviewed-by: Ilias Apalodimas <ilias.apalodimas at 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