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 ? :)
I can confirm that normal boot does not work without the patch and works
with it, that's about as far as I've been
Also tested passing an explicit usb stop without the patch and it also
works.
