Le sam. 26 sept. 2026 à 00:20, Marek Vasut <[email protected]> a écrit : > > On 9/26/26 5:35 AM, Romain Beauxis wrote: > > Le mer. 16 sept. 2026 à 23:47, Marek Vasut <[email protected]> a > > écrit : > >> > >> On 9/16/26 9:24 PM, Romain Beauxis wrote: > >>> Le sam. 12 sept. 2026 à 22:04, Marek Vasut <[email protected]> a > >>> écrit : > >>>> > >>>> On 9/11/26 10:32 PM, Romain Beauxis wrote: > >>>>> Neither bootm nor EFI ExitBootServices() stops USB controllers > >>>>> explicitly. Both only remove devices whose driver sets > >>>>> DM_FLAG_ACTIVE_DMA or DM_FLAG_OS_PREPARE. xhci-dwc3 sets neither, so a > >>>>> controller brought up by "usb start", e.g. from preboot for a USB > >>>>> keyboard, is handed to the OS still running. > >>>>> > >>>>> Set DM_FLAG_OS_PREPARE so that xhci_dwc3_remove() runs at handoff. > > This > >>>>> is the path "usb stop" already takes: the xHCI is reset, its PHYs are > >>>>> shut down and its clocks and resets are released. Child devices such > > as > >>>>> hubs, storage and keyboards are removed first, and a controller > > already > >>>>> stopped by "usb stop" is skipped. xhci-pci has done the same since > >>>>> commit e3bbc1f74e05 ("usb: xhci-pci: Add DM_FLAG_OS_PREPARE flag"), as > >>>>> have ohci-da8xx and the cdns3 wrappers. > >>>>> > >>>>> On Apple silicon machines the running controller is user visible: > > Linux > >>>>> does not enumerate a USB device attached to a Type-C port at boot > > until > >>>>> it is unplugged and plugged back in. > >>>> > >>>> boot/bootm.c bootm_final() does call dm_remove_devices_active() , is > >>>> that not sufficient to tear the controllers down before booting Linux ? > >>> > >>> Any idea how to test this? > >> > >> Add a printf() into the controller and uclass .remove/.unbind callbacks ? > > :) > > > > Ok I can try that but I'm not sure if your question covers a part that's > > been untested. What I did confirm: > > * Stock u-boot: kernel does not pick up the USB device on boot > > * With explicit usb stop: kernel does pick up the USB device on boot > > * With proposed patch: kernel does pick up the USB device on boot > > > > Is your question related to a different scenario that has not been covered > > yet? > boot/bootm.c bootm_final() does call dm_remove_devices_active() , that > should be enough to shut the controller down. Why is it not enough ?
No idea. I'm barely above user level here. Trying to help with reporting and proposing a patch based on what other drivers seems to be doing. > What does "the USB device" and "pick up" mean here, does the controller > fail to enumerate devices attached to it when Linux boots ? Could the > problem be related to some clock or some such instead ? Sorry for the confusion here. I have a hard drive connected to the USB hub that I want to mount at startup. It fails to enumerate when booting using the stock u-boot but enumerates with the two solutions posted above. Also enumerates when unplugged/plugged back. I'm happy to help test to find the right root cause for this issue but I'm relying on the machine for my daily use so I would appreciate as much details as possible to the part of the code that should be debugged so I can give you/y'all as much details in one shot. Thanks! -- Romain
