Re: [PATCH v11 4/9] PCI: Add additional checks for flr reset

Farhan Ali
2026-03-25T18:40:29Z

On 3/25/2026 9:25 AM, Alex Williamson wrote:
> On Tue, 24 Mar 2026 17:49:36 -0500
> Bjorn Helgaas <helgaas@kernel.org> wrote:
>
>> On Mon, Mar 16, 2026 at 12:15:39PM -0700, Farhan Ali wrote:
>>> If a device is in an error state, then any reads of device registers can
>>> return error value. Add additional checks to validate if a device is in an
>>> error state before doing an flr reset.
>> s/flr/FLR/ (also in subject)
>>
>> Also please extend the subject to say something specific about the
>> "additional checks". E.g.,
>>
>> PCI: Fail FLR when config space inaccessible
>>
>>> Cc: stable@vger.kernel.org
>>> Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
>>> Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
>>> Signed-off-by: Farhan Ali <alifm@linux.ibm.com>
>>> ---
>>> drivers/pci/pci.c | 7 +++++++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>> index 373421f4b9d8..8e4d924f4e88 100644
>>> --- a/drivers/pci/pci.c
>>> +++ b/drivers/pci/pci.c
>>> @@ -4371,12 +4371,19 @@ EXPORT_SYMBOL_GPL(pcie_flr);
>>> */
>>> int pcie_reset_flr(struct pci_dev *dev, bool probe)
>>> {
>>> + u32 reg;
>>> +
>>> if (dev->dev_flags & PCI_DEV_FLAGS_NO_FLR_RESET)
>>> return -ENOTTY;
>>>
>>> if (!(dev->devcap & PCI_EXP_DEVCAP_FLR))
>>> return -ENOTTY;
>>>
>>> + if (pcie_capability_read_dword(dev, PCI_EXP_DEVCAP, &reg)) {
>>> + pci_warn(dev, "Device unable to do an FLR\n");
>>> + return -ENOTTY;
>>> + }
>> I guess the point of this is to detect devices that are inaccessible?
>> The same sort of thing as in pci_dev_save_and_disable() from patch
>> 3/9? But we use "dev->error_state == pci_channel_io_perm_failure"
>> instead?
>>
>> No matter what we do, this has the same race as in patch 3/9. And I
>> think using dev->error_state also depends on AER being enabled, which
>> cuts out many PCIe devices.
>>
>> I think using the same exact code as in pci_dev_save_and_disable()
>> would be more straightforward. And also the same sort of wording in
>> the message, e.g., "Device config space inaccessible; unable to FLR"
>> or similar. I foresee many of these messages in my future, and it
>> will be helpful to have a specific clue about why FLR failed :)
> I think pci_af_flr() and pci_pm_reset() are all subject to this as
> well, some of the device specific resets too. Maybe we need a common
> helper with a string provided so we can differentiate the callers, even
> if we don't make all the conversions in this series. Thanks,
>
> Alex

Yeah I was planning on implementing a common function in the next
revision. Will include a string parameter to differentiate the callers.
And yeah I prefer not to update pci_af_flr() or pci_pm_reset() as part
of this series since I don't have the devices to test those paths.

Thanks

Farhan