Re: [PATCH RFC v2 3/4] iommu: Introduce iommu_dev_reset_prepare() and iommu_dev_reset_done()

[Jason Gunthorpe <jgg@nvidia.com>]

On Mon, Jul 28, 2025 at 12:07:59PM -0700, Nicolin Chen wrote:
> On Sun, Jul 27, 2025 at 01:25:01PM -0300, Jason Gunthorpe wrote:
> > On Tue, Jul 22, 2025 at 02:58:21PM -0700, Nicolin Chen wrote:
> > > > /*
> > > >  * This is called on the dma mapping fast path so avoid locking. This
> > > >  * is racy, but we have an expectation that the driver will setup its
> > > >  * DMAs inside probe while still single threaded to avoid racing.
> > > >  */
> > > > if (dev->iommu && !READ_ONCE(dev->iommu->attach_deferred))
> > > 
> > > This triggers a build error as attach_deferred is a bit-field. So I
> > > am changing it from "u32 attach_deferred:1" to "bool" for this.
> > 
> > Bleck, that seems undesirable.
> 
> But inevitable for READ_ONCE :(

I guess drop the READ_ONCE change
 
> > > And, to keep the original logic, I think it should be:
> > > 	if (!dev->iommu || !READ_ONCE(dev->iommu->attach_deferred))
> > 
> > That doesn't seem right, if there is no iommu by the time a driver is
> > probed there never will be an iommu and this device should be running
> > in direct mode only.
> 
> Well, the current function does:
> 	if (dev->iommu && dev->iommu->attach_deferred)
> 		return __iommu_attach_device(domain, dev);
> 	return 0;
> 
> So, matching to that logic, it would be:
> 	if (!dev->iommu || !dev->iommu->attach_deferred)
> 		return 0;
> 	return __iommu_attach_device(domain, dev);
> then add guard(mutex).

Yeah Ok

Jason