From: Stanislav Spassov <stanspas@amazon.com>
To: <linux-pci@vger.kernel.org>
Cc: "Stanislav Spassov" <stanspas@amazon.de>,
linux-acpi@vger.kernel.org, "Bjorn Helgaas" <bhelgaas@google.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Jan H . Schönherr" <jschoenh@amazon.de>,
"Jonathan Corbet" <corbet@lwn.net>,
"Ashok Raj" <ashok.raj@intel.com>,
"Alex Williamson" <alex.williamson@redhat.com>,
"Sinan Kaya" <okaya@kernel.org>,
"Rajat Jain" <rajatja@google.com>,
"kbuild test robot" <lkp@intel.com>
Subject: [PATCH v3 17/17] PCI: Lower PCIE_RESET_READY_POLL_MS from 1m to 1s
Date: Tue, 3 Mar 2020 14:28:52 +0100 [thread overview]
Message-ID: <20200303132852.13184-18-stanspas@amazon.com> (raw)
In-Reply-To: <20200303132852.13184-1-stanspas@amazon.com>
From: Stanislav Spassov <stanspas@amazon.de>
PCI Express Base specification r5.0 (May 22, 2019), sec 6.6.1 mentions
on more than one occasion that the appropriate waiting time before
deeming a device broken if it is not able to return Successful
Completion for valid Configuration Requests is 1 second after a
Conventional Reset (which should be the lengthiest of resets).
For devices that take longer than 1s to complete initialization, quirks
can override the waiting time via the reset_ready_poll_ms field in
struct pci_dev.
Note: This timeout is used in pci_dev_wait for the polling that happens
after we have already waited for the required post-reset times mandated
by the spec. All devices are expected to be responsive to Configuration
Requests at that point. "Completing initialization" here means that the
device is not only responsive, but actually returns Successful
Completions rather than CRS Completions (or any other error).
Signed-off-by: Stanislav Spassov <stanspas@amazon.de>
---
drivers/pci/pci.h | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index d8043d4dbe2f..1c6722b5c3ee 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -113,8 +113,11 @@ int pci_bus_error_reset(struct pci_dev *dev);
/* D0/D1->D2 and D2->D0 delay */
#define PCI_PM_D2_DELAY 200
-/* Time to wait after a reset for device to become responsive */
-#define PCIE_RESET_READY_POLL_MS 60000
+/*
+ * Time to wait (in addition to the delays above) for a device to start
+ * returning Successful Completions before OS can deem it broken
+ */
+#define PCIE_RESET_READY_POLL_MS 1000
/**
* struct pci_platform_pm_ops - Firmware PM callbacks
--
2.25.1
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
prev parent reply other threads:[~2020-03-03 13:31 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-03 13:28 [PATCH v3 00/17] Improve PCI device post-reset readiness polling Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 01/17] PCI: Fall back to slot/bus reset if softer methods timeout Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 02/17] PCI: Remove unused PCI_PM_BUS_WAIT Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 03/17] PCI: Use pci_bridge_wait_for_secondary_bus after SBR Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 04/17] PCI: Do not override delay for D0->D3hot transition Stanislav Spassov
2020-03-03 18:57 ` Rafael J. Wysocki
2020-03-07 10:58 ` Spassov, Stanislav
2020-03-03 13:28 ` [PATCH v3 05/17] PCI: Fix handling of _DSM 8 (avoiding reset delays) Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 06/17] PCI: Fix us->ms conversion in pci_acpi_optimize_delay Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 07/17] PCI: Clean up and document PM/reset delays Stanislav Spassov
2020-03-03 19:03 ` Rafael J. Wysocki
2020-03-07 11:30 ` Spassov, Stanislav
2020-03-03 13:28 ` [PATCH v3 08/17] PCI: Add more delay overrides to struct pci_dev Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 09/17] PCI: Generalize pci_bus_max_d3cold_delay to pci_bus_max_delay Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 10/17] PCI: Use correct delay in pci_bridge_wait_for_secondary_bus Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 11/17] PCI: Refactor pci_dev_wait to remove timeout parameter Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 12/17] PCI: Refactor pci_dev_wait to take pci_init_event Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 13/17] PCI: Cache CRS Software Visibiliy in struct pci_dev Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 14/17] PCI: Introduce per-device reset_ready_poll override Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 15/17] PCI: Refactor polling loop out of pci_dev_wait Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 16/17] PCI: Add CRS handling to pci_dev_wait() Stanislav Spassov
2020-03-05 17:56 ` Raj, Ashok
2020-03-06 18:07 ` Spassov, Stanislav
2020-03-03 13:28 ` Stanislav Spassov [this message]
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=20200303132852.13184-18-stanspas@amazon.com \
--to=stanspas@amazon.com \
--cc=akpm@linux-foundation.org \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=bhelgaas@google.com \
--cc=corbet@lwn.net \
--cc=jschoenh@amazon.de \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lkp@intel.com \
--cc=okaya@kernel.org \
--cc=rajatja@google.com \
--cc=stanspas@amazon.de \
--cc=tglx@linutronix.de \
/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).