On Fri, Sep 11, 2026 at 10:59:23PM +0200, Marek Vasut wrote:
> 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 ?Jumping back up to this part of the thread. I believe the answer is that it is only enough once we set DM_FLAG_OS_PREPARE so that we know to find and tear this down. Without digging through all of the discussions of the other places we've used this flag to fix a problem like this over the years, I believe it's a feature not a bug of how we do things that we need this flag. -- Tom
signature.asc
Description: PGP signature
