linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/1] PCI: Use pci_bridge_wait_for_secondary_bus after SBR instead of ssleep(1)
@ 2022-08-17 14:30 Yang Su
  2022-08-17 14:30 ` [PATCH 1/1] " Yang Su
  0 siblings, 1 reply; 2+ messages in thread
From: Yang Su @ 2022-08-17 14:30 UTC (permalink / raw)
  To: bhelgaas; +Cc: linux-pci, linux-kernel

In pci_reset_secondary_bus(), ssleep(1) is too long for PCIe.
So use pci_bridge_wait_for_secondary_bus after SBR.

Yang Su (1):
  PCI: Use pci_bridge_wait_for_secondary_bus after SBR instead of
    ssleep(1)

 drivers/pci/pci.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

-- 
2.19.1.6.gb485710b


^ permalink raw reply	[flat|nested] 2+ messages in thread

* [PATCH 1/1] PCI: Use pci_bridge_wait_for_secondary_bus after SBR instead of ssleep(1)
  2022-08-17 14:30 [PATCH 0/1] PCI: Use pci_bridge_wait_for_secondary_bus after SBR instead of ssleep(1) Yang Su
@ 2022-08-17 14:30 ` Yang Su
  0 siblings, 0 replies; 2+ messages in thread
From: Yang Su @ 2022-08-17 14:30 UTC (permalink / raw)
  To: bhelgaas; +Cc: linux-pci, linux-kernel

So far, pci_bridge_wait_for_secondary_bus() was only invoked by PM code
after (runtime) resume of devices, but it naturally makes sense for
handling post-SBR waiting as well.

On PCI Express, there will be cases where the new code sleeps far less
than the 1s being replaced by this patch. This should be okay, because
PCI Express Base Specification Revision 5.0 Version 1.0 (May 22, 2019)
in Section 6.6.1 "Conventional Reset" only notes 100ms as the minimum
waiting time. After this time, the OS is permitted to issue
Configuration Requests, but it is possible that the device responds
with Configuration Request Retry Status (CRS) Completions, rather than
Successful Completion. Returning CRS can go on for up to 1 second after
a Conventional Reset (such as SBR) before the OS can consider the device
broken. This additional wait is handled by pci_dev_wait. Besides,
pci_bridge_wait_for_secondary_bus() also can cover PCI and PCI-X after
device reset waiting Tpvrh + Trhfa (that is 1000ms + 100ms).

Currently, the only callchain that lands in the function modified by
this patch starts at pci_bridge_secondary_bus_reset which invokes
one out of two versions of pcibios_reset_secondary_bus that both end
with a call to pci_reset_secondary_bus.
Afterwards, pci_bridge_secondary_bus_reset always invokes pci_dev_wait
which wait for the device to return a non-CRS completion.

Signed-off-by: Stanislav Spassov <stanspas@amazon.de>
Signed-off-by: Yang Su <yang.su@linux.alibaba.com>
---
 drivers/pci/pci.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 95bc329e74c0..7c044d6e87e2 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5074,14 +5074,7 @@ void pci_reset_secondary_bus(struct pci_dev *dev)
 	ctrl &= ~PCI_BRIDGE_CTL_BUS_RESET;
 	pci_write_config_word(dev, PCI_BRIDGE_CONTROL, ctrl);
 
-	/*
-	 * Trhfa for conventional PCI is 2^25 clock cycles.
-	 * Assuming a minimum 33MHz clock this results in a 1s
-	 * delay before we can consider subordinate devices to
-	 * be re-initialized.  PCIe has some ways to shorten this,
-	 * but we don't make use of them yet.
-	 */
-	ssleep(1);
+	pci_bridge_wait_for_secondary_bus(dev);
 }
 
 void __weak pcibios_reset_secondary_bus(struct pci_dev *dev)
-- 
2.19.1.6.gb485710b


^ permalink raw reply related	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-08-17 14:30 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-17 14:30 [PATCH 0/1] PCI: Use pci_bridge_wait_for_secondary_bus after SBR instead of ssleep(1) Yang Su
2022-08-17 14:30 ` [PATCH 1/1] " Yang Su

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).