> Date: Mon, 28 Sep 2026 23:34:42 +0200 > From: Marek Vasut <[email protected]> > > On 9/28/26 9:25 PM, Tom Rini wrote: > > 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. > I am not convinced this is the right fix, but I asked Mark to dig into > this, since I don't have any apple silicon hardware. Maybe they can help > here.
Sorry, I've been a bit busy over the last few weeks. I've had a few reports of spurious USB DMA activity during early boot of OpenBSD. I recently made some changes there to enable the IOMMU properly (instead using bypass mode), and just received another report that definitely points at the USB controller doing DMA when it shouldn't. I haven't been able to reproduce the issue myself, but I think there is enough evidence for U-Boot not properly disabling DMA when handing control to the OS. I think that adding DM_FLAG_ACTIVE_DMA as Tom suggested in a different USB-related thread better reflects the intent. Cheers, Mark
