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? 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.
