Messages in this thread | | | Date | Mon, 16 Jan 2023 12:33:44 -0400 | From | Jason Gunthorpe <> | Subject | Re: [PATCH v5 0/5] iommu: Retire detach_dev callback |
| |
On Mon, Jan 16, 2023 at 05:24:56PM +0100, Marek Szyprowski wrote:
> > The iommu core calls the driver's detach_dev domain op callback only when > > a device is finished assigning to user space and > > iommu_group_release_dma_owner() is called to return the device to the > > kernel, where iommu core wants to set the default domain to the device but > > the driver didn't provide one. The code looks like: > > > > /* > > * New drivers should support default domains and so the detach_dev() op > > * will never be called. Otherwise the NULL domain represents some > > * platform specific behavior. > > */ > > if (!new_domain) { > > if (WARN_ON(!group->domain->ops->detach_dev)) > > return -EINVAL; > > __iommu_group_for_each_dev(group, group->domain, > > iommu_group_do_detach_device); > > group->domain = NULL; > > return 0; > > } > > > > In other words, if the iommu driver provides default domains, the > > .detach_dev callback will never be called; Otherwise, the .detach_dev > > callback is actually called to return control back to the platform DMA > > ops, other than detaching the domain from device. > > > > This series cleanups this by: > > > > - If the IOMMU driver provides default domains, remove .detach_dev > > callback. > > - Adds a new set_platform_dma iommu op. Any IOMMU driver that doesn't > > provide default domain should implement set_platform_dma callback > > instead. > > - Retire .detach_dev callback. > > > > This series originates from various discussion in the community. Thanks > > to Jason, Robin and all others for their ideas. > > I wonder how to handle the ARM 32bit case, which doesn't use the default > domain solution. Today, once this patchset has been merged to > linux-next, I've noticed that it broke booting of ARM 32bit Exynos based > boards.
It is supposed to work, can you help debug what went wrong?
Jason
| |