Re: [PATCH v2 2/2] PCI: Don't treat ~0 as ready in pci_dev_wait() with RRS SV

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] pci: premature wait termination for VFs returning ~0 under RRS SV
--

commit 3101a5ea075ba619cd03d971d4a538bf4788ec75
Author: Alexander Gruhlke <gruhlke@mailbox.org>

PCI: Don't treat ~0 as ready in pci_dev_wait() with RRS SV

With RRS Software Visibility, pci_dev_wait() considers a device ready as
soon as reading the Vendor ID doesn't return the RRS value.  Devices
aren't required to respond with RRS while they aren't ready, so the read
may return ~0 and pci_dev_wait() stops waiting too early.

Link: https://lore.kernel.org/r/20250611101442.387378-1-hui.wang@canonical.com

> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index aa39b4dd45aea..cf429f64bce0f 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
[ ... ]
> @@ -1331,7 +1332,8 @@ static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout)
>  
>  		if (root && root->config_rrs_sv) {
>  			pci_read_config_dword(dev, PCI_VENDOR_ID, &id);
> -			if (!pci_bus_rrs_vendor_id(id))
> +			if (!pci_bus_rrs_vendor_id(id) &&
> +			    (!PCI_POSSIBLE_ERROR(id) || dev->is_virtfn))
>  				break;

[Severity: Medium]
Does this cause pci_dev_wait() to exit prematurely for Virtual Functions
(VFs) that return ~0 under Configuration RRS Software Visibility?

If a VF is not yet ready, its config space might return ~0 (for example, due
to a Request Timeout) instead of the RRS value. The dev->is_virtfn check
causes the wait loop to terminate immediately upon seeing ~0. This seems to
allow unready VFs to appear ready, defeating the reset delay.

Callers might then attempt to initialize the unready VF, leading to config
read/write failures or even triggering PCIe AERs if the unready VF later
responds with RRS to non-Vendor-ID accesses.

While VFs architecturally return ~0 for Vendor ID when they are ready, polling
PCI_COMMAND when the Vendor ID returns ~0 (as done in the non-RRS SV path
below) could resolve this without exiting prematurely.

>  		} else {
>  			pci_read_config_dword(dev, PCI_COMMAND, &id);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261011163249.18479-1-gruhlke@mailbox.org?part=2