Hi Marek, Tom, I retested v2 on MangoPi MQ Pro using the downstream D1 port based on U-Boot v2026.10.
The boot path was U-Boot -> GRUB EFI -> Linux 7.3.1. Two USB hubs were cascaded, with one flash drive on each hub: - Near: 64GB Samsung Flash Drive FIT, attached to the first hub. - Far: 8GB USB Flash Disk, attached to the second hub. I added temporary port-path and device-identity traces. I matched the serial numbers against Linux to confirm each drive. No manual "usb stop" command was used. Relevant excerpts follow, with intermediate lines omitted: USBTRACE identity path=usb@4200000/0/1/2/3 vid=090c pid=1000 serial=5610050000154305 product="USB Flash Disk" USBTRACE done path=usb@4200000/0/1/2/3 driver=usb_mass_storage flags=4000 active=0 USBTRACE done path=usb@4200000/0/1/2 driver=usb_hub flags=4000 active=0 USBTRACE identity path=usb@4200000/0/1/3 vid=090c pid=1000 serial=0352315070000417 product="Flash Drive FIT" USBTRACE done path=usb@4200000/0/1/3 driver=usb_mass_storage flags=4000 active=0 USBTRACE done path=usb@4200000/0/1 driver=usb_hub flags=4000 active=0 USBTRACE done path=usb@4200000/0 driver=usb_hub flags=4000 active=0 USBTRACE ehci_deregister dev=usb@4200000 ret=0 USBTRACE done path=usb@4200000 driver=ehci_generic flags=4600 active=0 USBTRACE ohci_deregister dev=usb@4200400 ret=0 The farther drive was removed before the nearer drive. Children were removed before their parent hubs and the EHCI controller. Linux booted successfully, detected both drives, and reported no failed services. Both drives used EHCI. OHCI had no external devices. I lack suitable hardware to test downstream device removal through OHCI. Thanks, khaliforce On Sat, 31 Oct 2026 07:38:46 +0100, Marek Vasut <[email protected]> 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.
