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

[Jason Gunthorpe]

> [ ... 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.

-- 
Jason