On Wed, 10 Jul 2024, superm1@xxxxxxxxxx wrote:
From: Mario Limonciello <mario.limonciello@xxxxxxx>
A device that has gone through a reset may return a value in PCI_COMMAND
but that doesn't mean it's finished transitioning to D0. On devices that
support power management explicitly check PCI_PM_CTRL on everything but
system resume to ensure the transition happened.
Devices that don't support power management and system resume will
continue to use PCI_COMMAND.
Signed-off-by: Mario Limonciello <mario.limonciello@xxxxxxx>
---
drivers/pci/pci.c | 27 ++++++++++++++++++++-------
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 35fb1f17a589c..4ad02ad640518 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1270,21 +1270,34 @@ static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout)
* the read (except when CRS SV is enabled and the read was for the
* Vendor ID; in that case it synthesizes 0x0001 data).
*
- * Wait for the device to return a non-CRS completion. Read the
- * Command register instead of Vendor ID so we don't have to
- * contend with the CRS SV value.
+ * Wait for the device to return a non-CRS completion. On devices
+ * that support PM control and on waits that aren't part of system
+ * resume read the PM control register to ensure the device has
+ * transitioned to D0. On devices that don't support PM control,
+ * or during system resume read the command register to instead of
+ * Vendor ID so we don't have to contend with the CRS SV value.
*/
for (;;) {
- u32 id;
if (pci_dev_is_disconnected(dev)) {
pci_dbg(dev, "disconnected; not waiting\n");
return -ENOTTY;
}
- pci_read_config_dword(dev, PCI_COMMAND, &id);
- if (!PCI_POSSIBLE_ERROR(id))
- break;
+ if (dev->pm_cap && strcmp(reset_type, "resume") != 0) {
Comparing to a string makes me feel reset_type should be changed to
something that allows direct compare and those values only mapped into
string while printing it.