From: Sinan Kaya <okaya@codeaurora.org>
To: linux-pci@vger.kernel.org, timur@codeaurora.org,
alex.williamson@redhat.com
Cc: linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Sinan Kaya <okaya@codeaurora.org>,
Bjorn Helgaas <bhelgaas@google.com>,
linux-kernel@vger.kernel.org
Subject: [PATCH 3/5] PCI: make pci_flr_wait() generic and rename to pci_dev_wait()
Date: Sat, 23 Sep 2017 20:16:56 -0400 [thread overview]
Message-ID: <1506212218-29103-3-git-send-email-okaya@codeaurora.org> (raw)
In-Reply-To: <1506212218-29103-1-git-send-email-okaya@codeaurora.org>
Rev 3.1 Sec 2.3.1 Request Handling Rules:
Valid reset conditions after which a device is permitted to return CRS
are:
* Cold, Warm, and Hot Resets,
* FLR
* A reset initiated in response to a D3hot to D0 uninitialized
Try to reuse FLR implementation towards other reset types.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/pci/pci.c | 45 ++++++++++++++++++++++++++++-----------------
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 27ec45d..fd4a3b6 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3820,20 +3820,14 @@ int pci_wait_for_pending_transaction(struct pci_dev *dev)
}
EXPORT_SYMBOL(pci_wait_for_pending_transaction);
-static int pci_flr_wait(struct pci_dev *dev)
+static int pci_dev_wait(struct pci_dev *dev, char *reset_type,
+ int initial_wait, int timeout)
{
- int delay = 1, timeout = 60000;
+ int delay = 1;
u32 id;
/*
- * Per PCIe r3.1, sec 6.6.2, a device must complete an FLR within
- * 100ms, but may silently discard requests while the FLR is in
- * progress. Wait 100ms before trying to access the device.
- */
- msleep(100);
-
- /*
- * After 100ms, the device should not silently discard config
+ * 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
@@ -3847,14 +3841,14 @@ static int pci_flr_wait(struct pci_dev *dev)
pci_read_config_dword(dev, PCI_COMMAND, &id);
while (id == ~0) {
if (delay > timeout) {
- dev_warn(&dev->dev, "not ready %dms after FLR; giving up\n",
- 100 + delay - 1);
+ dev_warn(&dev->dev, "not ready %dms after %s; giving up\n",
+ initial_wait + delay - 1, reset_type);
return -ENOTTY;
}
if (delay > 1000)
- dev_info(&dev->dev, "not ready %dms after FLR; waiting\n",
- 100 + delay - 1);
+ dev_info(&dev->dev, "not ready %dms after %s; waiting\n",
+ initial_wait + delay - 1, reset_type);
msleep(delay);
delay *= 2;
@@ -3862,7 +3856,8 @@ static int pci_flr_wait(struct pci_dev *dev)
}
if (delay > 1000)
- dev_info(&dev->dev, "ready %dms after FLR\n", 100 + delay - 1);
+ dev_info(&dev->dev, "ready %dms after %s\n",
+ initial_wait + delay - 1, reset_type);
return 0;
}
@@ -3899,7 +3894,15 @@ int pcie_flr(struct pci_dev *dev)
dev_err(&dev->dev, "timed out waiting for pending transaction; performing function level reset anyway\n");
pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_BCR_FLR);
- return pci_flr_wait(dev);
+
+ /*
+ * Per PCIe r3.1, sec 6.6.2, a device must complete an FLR within
+ * 100ms, but may silently discard requests while the FLR is in
+ * progress. Wait 100ms before trying to access the device.
+ */
+ msleep(100);
+
+ return pci_dev_wait(dev, "FLR", 100, 60000);
}
EXPORT_SYMBOL_GPL(pcie_flr);
@@ -3932,7 +3935,15 @@ static int pci_af_flr(struct pci_dev *dev, int probe)
dev_err(&dev->dev, "timed out waiting for pending transaction; performing AF function level reset anyway\n");
pci_write_config_byte(dev, pos + PCI_AF_CTRL, PCI_AF_CTRL_FLR);
- return pci_flr_wait(dev);
+
+ /*
+ * Per PCIe r3.1, sec 6.6.2, a device must complete an FLR within
+ * 100ms, but may silently discard requests while the FLR is in
+ * progress. Wait 100ms before trying to access the device.
+ */
+ msleep(100);
+
+ return pci_dev_wait(dev, "AF_FLR", 100, 60000);
}
/**
--
1.9.1
WARNING: multiple messages have this Message-ID (diff)
From: okaya@codeaurora.org (Sinan Kaya)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/5] PCI: make pci_flr_wait() generic and rename to pci_dev_wait()
Date: Sat, 23 Sep 2017 20:16:56 -0400 [thread overview]
Message-ID: <1506212218-29103-3-git-send-email-okaya@codeaurora.org> (raw)
In-Reply-To: <1506212218-29103-1-git-send-email-okaya@codeaurora.org>
Rev 3.1 Sec 2.3.1 Request Handling Rules:
Valid reset conditions after which a device is permitted to return CRS
are:
* Cold, Warm, and Hot Resets,
* FLR
* A reset initiated in response to a D3hot to D0 uninitialized
Try to reuse FLR implementation towards other reset types.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/pci/pci.c | 45 ++++++++++++++++++++++++++++-----------------
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 27ec45d..fd4a3b6 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3820,20 +3820,14 @@ int pci_wait_for_pending_transaction(struct pci_dev *dev)
}
EXPORT_SYMBOL(pci_wait_for_pending_transaction);
-static int pci_flr_wait(struct pci_dev *dev)
+static int pci_dev_wait(struct pci_dev *dev, char *reset_type,
+ int initial_wait, int timeout)
{
- int delay = 1, timeout = 60000;
+ int delay = 1;
u32 id;
/*
- * Per PCIe r3.1, sec 6.6.2, a device must complete an FLR within
- * 100ms, but may silently discard requests while the FLR is in
- * progress. Wait 100ms before trying to access the device.
- */
- msleep(100);
-
- /*
- * After 100ms, the device should not silently discard config
+ * 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
@@ -3847,14 +3841,14 @@ static int pci_flr_wait(struct pci_dev *dev)
pci_read_config_dword(dev, PCI_COMMAND, &id);
while (id == ~0) {
if (delay > timeout) {
- dev_warn(&dev->dev, "not ready %dms after FLR; giving up\n",
- 100 + delay - 1);
+ dev_warn(&dev->dev, "not ready %dms after %s; giving up\n",
+ initial_wait + delay - 1, reset_type);
return -ENOTTY;
}
if (delay > 1000)
- dev_info(&dev->dev, "not ready %dms after FLR; waiting\n",
- 100 + delay - 1);
+ dev_info(&dev->dev, "not ready %dms after %s; waiting\n",
+ initial_wait + delay - 1, reset_type);
msleep(delay);
delay *= 2;
@@ -3862,7 +3856,8 @@ static int pci_flr_wait(struct pci_dev *dev)
}
if (delay > 1000)
- dev_info(&dev->dev, "ready %dms after FLR\n", 100 + delay - 1);
+ dev_info(&dev->dev, "ready %dms after %s\n",
+ initial_wait + delay - 1, reset_type);
return 0;
}
@@ -3899,7 +3894,15 @@ int pcie_flr(struct pci_dev *dev)
dev_err(&dev->dev, "timed out waiting for pending transaction; performing function level reset anyway\n");
pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_BCR_FLR);
- return pci_flr_wait(dev);
+
+ /*
+ * Per PCIe r3.1, sec 6.6.2, a device must complete an FLR within
+ * 100ms, but may silently discard requests while the FLR is in
+ * progress. Wait 100ms before trying to access the device.
+ */
+ msleep(100);
+
+ return pci_dev_wait(dev, "FLR", 100, 60000);
}
EXPORT_SYMBOL_GPL(pcie_flr);
@@ -3932,7 +3935,15 @@ static int pci_af_flr(struct pci_dev *dev, int probe)
dev_err(&dev->dev, "timed out waiting for pending transaction; performing AF function level reset anyway\n");
pci_write_config_byte(dev, pos + PCI_AF_CTRL, PCI_AF_CTRL_FLR);
- return pci_flr_wait(dev);
+
+ /*
+ * Per PCIe r3.1, sec 6.6.2, a device must complete an FLR within
+ * 100ms, but may silently discard requests while the FLR is in
+ * progress. Wait 100ms before trying to access the device.
+ */
+ msleep(100);
+
+ return pci_dev_wait(dev, "AF_FLR", 100, 60000);
}
/**
--
1.9.1
next prev parent reply other threads:[~2017-09-24 0:16 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-24 0:16 [PATCH 1/5] PCI: protect restore with device lock to be consistent Sinan Kaya
2017-09-24 0:16 ` Sinan Kaya
2017-09-24 0:16 ` Sinan Kaya
2017-09-24 0:16 ` [PATCH 2/5] PCI: handle FLR failure and allow other reset types Sinan Kaya
2017-09-24 0:16 ` Sinan Kaya
2017-09-24 0:16 ` Sinan Kaya
2017-10-11 21:00 ` Bjorn Helgaas
2017-10-11 21:00 ` Bjorn Helgaas
2017-10-11 21:00 ` Bjorn Helgaas
2017-10-12 16:42 ` Sinan Kaya
2017-10-12 16:42 ` Sinan Kaya
2017-09-24 0:16 ` Sinan Kaya [this message]
2017-09-24 0:16 ` [PATCH 3/5] PCI: make pci_flr_wait() generic and rename to pci_dev_wait() Sinan Kaya
2017-09-24 13:08 ` Christoph Hellwig
2017-09-24 13:08 ` Christoph Hellwig
2017-09-24 13:08 ` Christoph Hellwig
2017-09-25 0:30 ` Sinan Kaya
2017-09-25 0:30 ` Sinan Kaya
2017-09-25 0:30 ` Sinan Kaya
2017-09-24 0:16 ` [PATCH 4/5] PCI: wait device ready after pci_pm_reset() Sinan Kaya
2017-09-24 0:16 ` Sinan Kaya
2017-09-24 0:16 ` Sinan Kaya
2017-10-11 22:06 ` Bjorn Helgaas
2017-10-11 22:06 ` Bjorn Helgaas
2017-10-11 22:06 ` Bjorn Helgaas
2017-10-12 16:48 ` Sinan Kaya
2017-10-12 16:48 ` Sinan Kaya
2017-10-16 12:51 ` Sinan Kaya
2017-10-16 12:51 ` Sinan Kaya
2017-09-24 0:16 ` [PATCH 5/5] PCI: add device wait after slot and bus reset Sinan Kaya
2017-09-24 0:16 ` Sinan Kaya
2017-09-24 0:20 ` Sinan Kaya
2017-09-24 0:20 ` Sinan Kaya
2017-10-11 22:08 ` [PATCH 1/5] PCI: protect restore with device lock to be consistent Bjorn Helgaas
2017-10-11 22:08 ` Bjorn Helgaas
2017-10-12 16:39 ` Sinan Kaya
2017-10-12 16:39 ` 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=1506212218-29103-3-git-send-email-okaya@codeaurora.org \
--to=okaya@codeaurora.org \
--cc=alex.williamson@redhat.com \
--cc=bhelgaas@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=timur@codeaurora.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.