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. -- Tom
signature.asc
Description: PGP signature
