linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 13/17] PCI: Cache CRS Software Visibiliy in struct pci_dev
Date: Tue, 3 Mar 2020 14:28:48 +0100	[thread overview]
Message-ID: <20200303132852.13184-14-stanspas@amazon.com> (raw)
In-Reply-To: <20200303132852.13184-1-stanspas@amazon.com>

From: Stanislav Spassov <stanspas@amazon.de>

Arguably, since CRS SV is a capability of Root Ports and determines
how Root Ports will handle incoming CRS Completions, it makes more
sense to store this flag in the struct pci bus that represents the
port's secondary bus, and to cache it in any buses further down the
hierarchy.

However, storing the flag in struct pci_dev allows individual devices
to be marked as not supporting CRS properly even when CRS SV is enabled
on their parent Root Port. This way, future code that relies on the new
flag will not be misled that it is safe to probe a device by relying on
CRS SV to not cause platform timeouts (See the note on CRS SV on p. 553
of PCI Express Base Specification r5.0 from May 22, 2019).

Note: Endpoints integrated into the Root Complex (RCiEP) may also be
capable of using CRS. In that case, the software visibility is
controlled using a Root Complex Register Block (RCRB). This is currently
not supported by the kernel. The code introduced here would simply not
set the newly introduced flag for RCiEP as for those bus->self is NULL.

Signed-off-by: Stanislav Spassov <stanspas@amazon.de>
---
 drivers/pci/probe.c | 8 +++++++-
 include/linux/pci.h | 3 +++
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 512cb4312ddd..eeff8a07f330 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1080,9 +1080,11 @@ static void pci_enable_crs(struct pci_dev *pdev)
 
 	/* Enable CRS Software Visibility if supported */
 	pcie_capability_read_word(pdev, PCI_EXP_RTCAP, &root_cap);
-	if (root_cap & PCI_EXP_RTCAP_CRSVIS)
+	if (root_cap & PCI_EXP_RTCAP_CRSVIS) {
 		pcie_capability_set_word(pdev, PCI_EXP_RTCTL,
 					 PCI_EXP_RTCTL_CRSSVE);
+		pdev->crssv_enabled = true;
+	}
 }
 
 static unsigned int pci_scan_child_bus_extend(struct pci_bus *bus,
@@ -2414,6 +2416,10 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
 	list_add_tail(&dev->bus_list, &bus->devices);
 	up_write(&pci_bus_sem);
 
+	/* Propagate CRS Software Visibility bit from the parent bridge */
+	if (bus->self)
+		dev->crssv_enabled = bus->self->crssv_enabled;
+
 	ret = pcibios_add_device(dev);
 	WARN_ON(ret < 0);
 
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 16dbfff2092e..1763e98625b9 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -386,6 +386,9 @@ struct pci_dev {
 						   bit manually */
 	unsigned int    ignore_reset_delay_on_sx_resume:1; /* Cached value from
 							      pci_host_bridge */
+	unsigned int	crssv_enabled:1;	/* Configuration Request Retry
+						   Status Software Visibility
+						   enabled on (parent) bridge */
 	unsigned int    delay[PCI_INIT_EVENT_COUNT]; /* minimum waiting time
 							after various events
 							in ms */
-- 
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




  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 ` Stanislav Spassov [this message]
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 ` [PATCH v3 17/17] PCI: Lower PCIE_RESET_READY_POLL_MS from 1m to 1s Stanislav Spassov

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