diff options
author | Naveen Naidu <naveennaidu479@gmail.com> | 2021-11-18 19:33:26 +0530 |
---|---|---|
committer | Bjorn Helgaas <bhelgaas@google.com> | 2021-11-18 14:12:57 -0600 |
commit | fa52b6447ce1cc0157c89dac7762f1693deeb10e (patch) | |
tree | 21b89ed676e47cf141e603a574372634add9edfd /drivers/pci/pci.c | |
parent | ba25d181caaa230107531ed440c3163fc814d4b1 (diff) | |
download | linux-next-fa52b6447ce1cc0157c89dac7762f1693deeb10e.tar.gz |
PCI/ERR: Use PCI_POSSIBLE_ERROR() to check config reads
When config pci_ops.read() can detect failed PCI transactions, the data
returned to the CPU is PCI_ERROR_RESPONSE (~0 or 0xffffffff).
Obviously a successful PCI config read may *also* return that data if a
config register happens to contain ~0, so it doesn't definitively indicate
an error unless we know the register cannot contain ~0.
Use PCI_POSSIBLE_ERROR() to check the response we get when we read data
from hardware. This unifies PCI error response checking and makes error
checks consistent and easier to find.
Link: https://lore.kernel.org/r/f4d18d470cb90f9cb52ea155b01528ba2e76e8d6.1637243717.git.naveennaidu479@gmail.com
Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Diffstat (limited to 'drivers/pci/pci.c')
-rw-r--r-- | drivers/pci/pci.c | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 3d2fb394986a..bc82699ed105 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -1115,7 +1115,7 @@ static int pci_raw_set_power_state(struct pci_dev *dev, pci_power_t state) return -EIO; pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pmcsr); - if (pmcsr == (u16) ~0) { + if (PCI_POSSIBLE_ERROR(pmcsr)) { pci_err(dev, "can't change power state from %s to %s (config space inaccessible)\n", pci_power_name(dev->current_state), pci_power_name(state)); @@ -1271,16 +1271,16 @@ static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout) * After reset, the device should not silently discard config * requests, but it may still indicate that it needs more time by * responding to them with CRS completions. The Root Port will - * generally synthesize ~0 data to complete the read (except when - * CRS SV is enabled and the read was for the Vendor ID; in that - * case it synthesizes 0x0001 data). + * generally synthesize ~0 (PCI_ERROR_RESPONSE) data to complete + * 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. */ pci_read_config_dword(dev, PCI_COMMAND, &id); - while (id == ~0) { + while (PCI_POSSIBLE_ERROR(id)) { if (delay > timeout) { pci_warn(dev, "not ready %dms after %s; giving up\n", delay - 1, reset_type); |