Re: [RFC PATCH 0/3] PCI: Use Configuration RRS to wait for device ready

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux