Jason Gunthorpe <j...@nvidia.com> writes: > On Tue, May 30, 2023 at 10:03:53PM +1000, Michael Ellerman wrote: >> Jason Gunthorpe <j...@nvidia.com> writes: >> > On Tue, May 23, 2023 at 08:26:32AM +0200, Joerg Roedel wrote: >> >> On Tue, May 16, 2023 at 09:35:25PM -0300, Jason Gunthorpe wrote: >> >> > With POWER SPAPR now having a real iommu driver and using the normal >> >> > group >> >> > lifecycle stuff fixing FSL will leave only VFIO's no-iommu support as a >> >> > user for the iommu_group_add/remove_device() calls. This will help >> >> > simplify the understanding of what the core code should be doing for >> >> > these >> >> > functions. >> >> > >> >> > Fix FSL to not need to call iommu_group_remove_device() at all. >> >> > >> >> > v2: >> >> > - Change the approach to use driver_managed_dma >> >> > - Really simplify fsl_pamu_device_group() and just put everything in >> >> > one >> >> > function >> >> > - New patch to make missing OF properties a probe failure >> >> > v1: >> >> > https://lore.kernel.org/r/0-v1-1421774b874b+167-ppc_device_group_...@nvidia.com >> >> > >> >> > Jason Gunthorpe (3): >> >> > iommu/fsl: Always allocate a group for non-pci devices >> >> > iommu/fsl: Move ENODEV to fsl_pamu_probe_device() >> >> > iommu/fsl: Use driver_managed_dma to allow VFIO to work >> >> > >> >> > arch/powerpc/sysdev/fsl_pci.c | 1 + >> >> > drivers/iommu/fsl_pamu_domain.c | 123 +++++++++----------------------- >> >> > 2 files changed, 36 insertions(+), 88 deletions(-) >> >> >> >> Any chance someone can test this on real hardware? >> > >> > There isn't even a MAINTAINERS entry for this, and the git log looks >> > pretty dead for a long time. I tried to cc people who might care, >> > but I'm not so optimistic - unless Li says something. >> ... > >> Anything else I can check easily? > > Wow Great, I think that is a Tested-by. :) Honestly booting at all is > 99% of the battle..
Great, yep consider it: Tested-by: Michael Ellerman <m...@ellerman.id.au> cheers
