Re: [PATCH 1/2] iommu/fsl: Do not use iommu_group_remove_device() under ops->device_group()

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, May 16, 2023 at 07:24:20PM +0100, Robin Murphy wrote:

> My reading of the current code is that it must absolutely be relying on
> fsl_pamu_init() having run before fsl_pci_init() (they're both at
> arch_initcall level, implying an icky fragile link-order
> dependency), 

Oh, I see, so this platform device would have a group assigned.

> > index b7232c46b24481..6daf620b63a4d5 100644
> > --- a/arch/powerpc/sysdev/fsl_pci.c
> > +++ b/arch/powerpc/sysdev/fsl_pci.c
> > @@ -1353,6 +1353,7 @@ static struct platform_driver fsl_pci_driver = {
> >                  .of_match_table = pci_ids,
> >          },
> >          .probe = fsl_pci_probe,
> > +       .driver_managed_dma = true,
> >   };
> >   static int __init fsl_pci_init(void)
> > 
> > Even though it is a NOP in this case because of ordering, it still
> > would be good for documentation purposes.
> 
> ...however I think you're on to something here - if with this we can safely
> guarantee to negate any ownership problem as well, then flipping it all
> around to *always* rely on the platform device's group might be neatest of
> all.

Okay, it makes sense. I don't see anything wrong with this, the
controller has to have a liodn and thus a group created for PCI to
work.

Though looking at this driver I don't really understand how it works..
The email discussion from 2013 for merging the driver made it clear
that

 .. We can isolate the DMA access to the host based on the to the
 pci bus,device,function number.

But I can't see where in this driver the RID gets relayed into any
kind of HW programming??

When fsl_pamu_attach_device() sees a PCI device it jumps to the
controller and discards the pci device entirely for the functions it
calls? It seems to do the same thing regardless of what PCI device is
attaching? Huh?

Thanks,
Jason