Re: [PATCH v5 03/18] PCI: Propagate FLR return values to callers

[Jason Gunthorpe]

On Thu, Aug 27, 2026 at 02:18:08PM -0700, Nicolin Chen wrote:
> On Thu, Aug 27, 2026 at 05:31:31PM -0300, Jason Gunthorpe wrote:
> > > [ ... 24 lines skipped ... ]
> > > Since these quirks have always returned success, escalating
> > > would be a new and harmful behavior: the next method is typically the plain
> > > "flr" method, which would re-run the same FLR without the extra steps the
> > > quirk wraps around its pcie_flr() call. Add quirk_flr_err() converting that
> > > -ENOTTY to -ETIMEDOUT, so the cascade still stops at the quirk as before.
> > > The early "not applicable" -ENOTTY returns are left intact, and they still
> > > ask the caller to try the next method.
> > 
> > This seems like a very suspect AI conclusion to me.
> > 
> > I think I'd drop this patch
> > 
> > > Convert it at the quirk level rather than in pcie_flr() or pci_dev_wait(),
> > > because those also serve the native "flr"/"af_flr"/"pm" methods, where the
> > > -ENOTTY on timeout is deliberate per commit 91295d79d658 ("PCI: Handle FLR
> > > failure and allow other reset types"): a timed-out native FLR escalates to
> > > a stronger reset (e.g. bus reset), which skips no workaround there and may
> > > recover the device. Converting in the core would also change the value seen
> > > by every direct pcie_flr() caller.
> > > 
> > > This is not a bug fix, since these functions have always returned success
> > > and the propagated values are only consumed by incoming work.
> > 
> > In what way? The quirks flows always succeed and it can keep always
> > succeeding. If anyone finds this problematic they can properly
> > propogate the error.
> > 
> > Squashing the error just for quirks makes little sense.
> 
> PATCH-5 forwards the return values to pci_dev_reset_iommu_done(),
> so IOMMU can keep a device blocked on a nonzero result. Dropping
> this patch would leave the three VF quirks here always reporting
> success, reopening the stale-ATC issue this series is fixing for
> them.

Sure its fine, I bet this HW doesn't even have ATC and if it does
someone can properly fix the quirk and test it that way if they ever
hit a problem.

It doesn't make sense to touch this code and make it worse, the right
answer is to propagate the error code directly.

Jason