Re: [PATCH v8 5/5] PCI: Suspend iommu function prior to resetting a device

[Bjorn Helgaas <helgaas@kernel.org>]

On Wed, Nov 04, 2026 at 04:03:22PM -0800, Nicolin Chen wrote:
> On Wed, Nov 04, 2026 at 05:55:00PM -0600, Bjorn Helgaas wrote:
> > On Mon, Dec 15, 2025 at 01:42:20PM -0800, Nicolin Chen wrote:
> > > @@ -4885,10 +4919,20 @@ static int pci_reset_bus_function(struct pci_dev *dev, bool probe)
> > >  		return -ENOTTY;
> > >  	}
> > >  
> > > +	rc = pci_dev_reset_iommu_prepare(dev);
> > > +	if (rc) {
> > > +		pci_err(dev, "failed to stop IOMMU for a PCI reset: %d\n", rc);
> > > +		return rc;
> > > +	}
> > 
> > Unlike the other reset functions, this one calls
> > pci_dev_reset_iommu_prepare() even when probe==true, i.e., we don't
> > want to actually perform the reset, we just want to know whether the
> > reset method might work.
> > 
> > It's at least unnecessary to call pci_dev_reset_iommu_prepare() and
> > pci_dev_reset_iommu_done() in that case, and maybe even problematic
> > because the pci_init_reset_methods() probe happens from
> > pci_init_capabilities(), which is pretty early during PCI enumeration
> > of the device.
> > 
> > I know this has already been merged as f5b16b802174 ("PCI: Suspend
> > iommu function prior to resetting a device"), and I'm not sure whether
> > we should do anything about it.  I wonder if we should just skip the
> > prepare/done when probe==true?
> 
> I've posted a fix for a few times actually. The latest one was
> posted yesterday after a split:
> https://lore.kernel.org/linux-iommu/c66d5221a8e4356316d4f614c8584a80dc9d71b6.1793729707.git.nicolinc@nvidia.com/

Well, that's embarrassing ;)

I acked the PCI patches there on the assumption that they'll go via
the IOMMU tree since the interesting bits are there.