On 10/31/26 3:18 PM, Tom Rini wrote:
On Sat, Oct 31, 2026 at 07:38:46AM +0100, Marek Vasut wrote:
On 10/16/26 2:04 AM, Tom Rini wrote:
On Thu, Oct 15, 2026 at 11:17:28PM +0200, Marek Vasut wrote:
On 10/12/26 12:31 AM, Tom Rini wrote:
[...]
I believe the answer there is that we have flags to handle this problem
generically rather than hard-coding a call in every arch's
boot_prep_linux or similar like we had to with the old USB gadget stack.
This is shutting down host, not gadget. And I believe usb_stop() is
necessary to correctly shut down the devices on the USB bus, while the
DM_FLAG_ACTIVE_DMA flag is necessary to shut down the controller, so both
are needed.
Host or gadget isn't the point here, it's that we used to hard-code the
stop function call for the non-DM driver and now we have driver model
and flags. Everything should be able to properly unwind with flags being
set.
So what needs to be tested is whether the flags are enough to properly stop
devices downstream of the controller, or whether we need something more,
possibly equivalent of "usb stop" in the USB uclass pre_remove callback or
some such thing.
What more testing do we need at this point to see what
DM-related-unwinding that usb_stop does that isn't also covered by
adding this flag to the controllers that are missing it?
Plug two or more hubs into each other and then into the controller, then
connect at least one USB stick into each hub, start booting and see if those
devices get removed in the correct order (stick furthest from the controller
first, nearest stick one before last, controller last). This is my concern
here.
Thanks for elaborating.
Sure. Sorry for the delay.
