On 8/27/2024 18:48, Bjorn Helgaas wrote:
From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx> After a device reset, pci_dev_wait() waits for a device to become completely ready by polling the PCI_COMMAND register. The spec envisions that software would instead poll for the device to stop responding to config reads with Completions with Request Retry Status (RRS). Polling PCI_COMMAND leads to hardware retries that are invisible to software and the backoff between software retries doesn't work correctly. Root Ports are not required to support the Configuration RRS Software Visibility feature that prevents hardware retries and makes the RRS Completions visible to software, so this series only uses it when available and falls back to PCI_COMMAND polling when it's not. This is completely untested and posted for comments. Bjorn Helgaas (3): PCI: Wait for device readiness with Configuration RRS PCI: aardvark: Correct Configuration RRS checking PCI: Rename CRS Completion Status to RRS drivers/bcma/driver_pci_host.c | 10 ++-- drivers/pci/controller/dwc/pcie-tegra194.c | 18 +++--- drivers/pci/controller/pci-aardvark.c | 64 +++++++++++----------- drivers/pci/controller/pci-xgene.c | 6 +- drivers/pci/controller/pcie-iproc.c | 18 +++--- drivers/pci/pci-bridge-emul.c | 4 +- drivers/pci/pci.c | 41 +++++++++----- drivers/pci/pci.h | 11 +++- drivers/pci/probe.c | 33 +++++------ include/linux/bcma/bcma_driver_pci.h | 2 +- include/linux/pci.h | 1 + include/uapi/linux/pci_regs.h | 6 +- 12 files changed, 117 insertions(+), 97 deletions(-)
Although this looks like a useful series, I'm sorry to say but this doesn't solve the issue that Gary and I raised. We double checked today and found that reading the vendor ID works just fine at this time.
I think that we're still better off polling PCI_PM_CTRL to "wait" for D0 after the state change from D3cold.
