Re: [PATCH v3 3/3] iommu/arm-smmu-v3: Fix ATS state tracking via ats_prepared gate

[Jason Gunthorpe <jgg@ziepe.ca>]

On Fri, May 22, 2026 at 04:14:01PM +0000, Pranjal Shrivastava wrote:
> > 
> > Though really pci_enable_ats is not working the way we want, writing
> > the enable register can't actually fail - it is all the sanity
> > checking for kernel bugs that is the problem here.
> > 
> > How about call pci_ats_supported() early in attach and fail, then if
> > pci_enable_ats() fails just WARN_ON and keep going, kernel bug.
> > 
> > Re-organize pci_enable_ats() so it relies on pci_ats_supported() for
> > all the sanity checks and cannot fail if supported is true.
> 
> Hmm, IIUC, the current situation says: 
> 
> pci_ats_supported ==> ATS cap check
> pci_prepare_ats ==> ATS enablement prep 
> 
> Thus, I feel if the prepare fails, we should expect enable to fail. But
> if prepare succeeds but enable didn't, that's the place we should
> WARN_ON and move on.. because we (IOMMU) did the best we could have..
> 
> With the updated variants of pci_ats_support / pci_prepare_ats (in
> patches 1 & 2), I believe we cover all the cases now..
> 
> And we plan to call prepare_ats only if (pci_ats_supported == true)
> 
> Thus, if prepare_ats failed, we fail at probe. And if probe succeeds but
> enable ATS failed, that's something the IOMMU can't help with, hence we
> WARN and move on? Does that sound good?

OK, what I really want to avoid is wrecking the attach flow. It is
designed so the failable things happen early and after a certain point
failure is no longer permitted, the enable_ats is after the point.

So it should continue to be structued like that - enable_ats
failing is a kernel bug because earlier checks preclude it..

Jason