From: okaya@codeaurora.org (Sinan Kaya)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V10 2/3] PCI: handle CRS returned by device after FLR
Date: Fri, 11 Aug 2017 12:56:35 -0400 [thread overview]
Message-ID: <1502470596-4112-2-git-send-email-okaya@codeaurora.org> (raw)
In-Reply-To: <1502470596-4112-1-git-send-email-okaya@codeaurora.org>
Sporadic reset issues have been observed with Intel 750 NVMe drive while
assigning the physical function to the guest machine. The sequence of
events observed is as follows:
- perform a Function Level Reset (FLR)
- sleep up to 1000ms total
- read ~0 from PCI_COMMAND
- warn that the device didn't return from FLR
- touch the device before it's ready
- drop register read and writes performing register settings restore
- incomplete reset operation and partial register restoration
- second time device probe fails in the guest machine as HW is left in
limbo.
An endpoint is allowed to issue Configuration Request Retry Status (CRS)
following a FLR request to indicate that it is not ready to accept new
requests. CRS is defined in PCIe r3.1, sec 2.3.1. Request Handling Rules
and CRS usage in FLR context is mentioned in PCIe r3.1, sec 6.6.2.
Function-Level Reset.
A CRS indication will only be given if the address to be read is vendor ID
register. pci_bus_read_dev_vendor_id() knows how to deal with CRS returned
0xFFFF0001 value and will continue polling until a value other than
0xFFFF0001 is returned within a given timeout.
Try to discover device presence via CRS first. If device is not found, fall
through to old behavior.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/pci/pci.c | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index af0cc34..c853551 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3821,17 +3821,36 @@ static void pci_flr_wait(struct pci_dev *dev)
{
int i = 0;
u32 id;
+ bool ret;
+
+ /*
+ * Don't touch the HW before waiting 100ms. HW has to finish
+ * within 100ms according to PCI Express Base Specification
+ * Revision 3.1 Section 6.6.2: Function-Level Reset (FLR).
+ */
+ msleep(100);
+
+ if (pci_bus_read_config_dword(dev->bus, dev->devfn, PCI_VENDOR_ID,
+ &id))
+ return;
+
+ /* See if we can find a device via CRS first. */
+ if ((id & 0xffff) == 0x0001) {
+ ret = pci_bus_wait_crs(dev->bus, dev->devfn, &id, 60000);
+ if (ret)
+ return;
+ }
do {
msleep(100);
pci_read_config_dword(dev, PCI_COMMAND, &id);
- } while (i++ < 10 && id == ~0);
+ } while (i++ < 9 && id == ~0);
if (id == ~0)
dev_warn(&dev->dev, "Failed to return from FLR\n");
else if (i > 1)
dev_info(&dev->dev, "Required additional %dms to return from FLR\n",
- (i - 1) * 100);
+ i * 100);
}
/**
--
1.9.1
next prev parent reply other threads:[~2017-08-11 16:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-11 16:56 [PATCH V10 1/3] PCI: introduce pci_bus_wait_crs() function Sinan Kaya
2017-08-11 16:56 ` Sinan Kaya [this message]
2017-08-18 21:01 ` [PATCH V10 2/3] PCI: handle CRS returned by device after FLR Bjorn Helgaas
2017-08-21 13:44 ` Sinan Kaya
2017-08-21 18:00 ` Bjorn Helgaas
2017-08-23 3:21 ` Sinan Kaya
2017-08-23 20:01 ` Bjorn Helgaas
2017-08-11 16:56 ` [PATCH V10 3/3] PCI: display not responding message while device is unreachable Sinan Kaya
2017-08-18 3:00 ` [PATCH V10 1/3] PCI: introduce pci_bus_wait_crs() function Bjorn Helgaas
2017-08-18 13:33 ` Sinan Kaya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1502470596-4112-2-git-send-email-okaya@codeaurora.org \
--to=okaya@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).