On 10/11/26 9:06 PM, Mark Kettenis wrote:
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.
ACK
