PCI: xgene: Use PCI_ERROR_RESPONSE to identify config read errors

Include PCI_ERROR_RESPONSE along with 0xffffffff in the comment about
identifying config read errors. This makes checks for config read errors
easier to find. Comment change only.

Link: https://lore.kernel.org/r/388b9733bd55394581c447be9f3df42ca2c9759c.1637243717.git.naveennaidu479@gmail.com
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

diff --git a/drivers/pci/controller/pci-xgene.c b/drivers/pci/controller/pci-xgene.c
index 56d0d50..bfa5062 100644 (file)
--- a/drivers/pci/controller/pci-xgene.c
+++ b/drivers/pci/controller/pci-xgene.c
@@ -171,11 +171,11 @@ static int xgene_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
                return PCIBIOS_DEVICE_NOT_FOUND;
 
        /*
-        * The v1 controller has a bug in its Configuration Request
-        * Retry Status (CRS) logic: when CRS Software Visibility is
-        * enabled and we read the Vendor and Device ID of a non-existent
-        * device, the controller fabricates return data of 0xFFFF0001
-        * ("device exists but is not ready") instead of 0xFFFFFFFF
+        * The v1 controller has a bug in its Configuration Request Retry
+        * Status (CRS) logic: when CRS Software Visibility is enabled and
+        * we read the Vendor and Device ID of a non-existent device, the
+        * controller fabricates return data of 0xFFFF0001 ("device exists
+        * but is not ready") instead of 0xFFFFFFFF (PCI_ERROR_RESPONSE)
         * ("device does not exist").  This causes the PCI core to retry
         * the read until it times out.  Avoid this by not claiming to
         * support CRS SV.