From patchwork Sat Mar 7 17:20:42 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stanislav Spassov X-Patchwork-Id: 1250917 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-pci-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=amazon.com header.i=@amazon.com header.a=rsa-sha256 header.s=amazon201209 header.b=SRO8Ndfl; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 48ZWVb1fj3z9sPK for ; Sun, 8 Mar 2020 04:21:27 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726139AbgCGRV0 (ORCPT ); Sat, 7 Mar 2020 12:21:26 -0500 Received: from smtp-fw-4101.amazon.com ([72.21.198.25]:57793 "EHLO smtp-fw-4101.amazon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726109AbgCGRVZ (ORCPT ); Sat, 7 Mar 2020 12:21:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1583601685; x=1615137685; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=HwpeeEBSuhzWpYTsEXe5OdgJRbOFyg3rXVY6QJ+/f1k=; b=SRO8NdflkqhmHcHP4dctI4GBuhdpTPXzAojp4DSoVn+4emK2mN9KGxLj Uv4S7T09SfSx8NpmIPi6W/tD2hpaYAid7pgM9W5kRPSU0lQSJIrZQeNJd xnRzJQghkRLbn7w3WflMaELd9SNaPS7Lz2rn/wMOTm0PQpTTvEPAGN/VF k=; IronPort-SDR: wMduy1ZCjnBvKGNYu5p/CFPI+IVJYmmp2HoOh4iXPZkY1B4JjqsWRBPh2QjbYC8zOqTBORfq4u G8mjLKIZoRQw== X-IronPort-AV: E=Sophos;i="5.70,526,1574121600"; d="scan'208";a="20226469" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1a-af6a10df.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP; 07 Mar 2020 17:21:13 +0000 Received: from EX13MTAUEA002.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1a-af6a10df.us-east-1.amazon.com (Postfix) with ESMTPS id DC2BBA281B; Sat, 7 Mar 2020 17:21:09 +0000 (UTC) Received: from EX13D04EUA002.ant.amazon.com (10.43.165.75) by EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Sat, 7 Mar 2020 17:21:09 +0000 Received: from EX13MTAUEE002.ant.amazon.com (10.43.62.24) by EX13D04EUA002.ant.amazon.com (10.43.165.75) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 7 Mar 2020 17:21:08 +0000 Received: from u961addbe640f56.ant.amazon.com (10.28.84.111) by mail-relay.amazon.com (10.43.62.224) with Microsoft SMTP Server id 15.0.1367.3 via Frontend Transport; Sat, 7 Mar 2020 17:21:05 +0000 From: Stanislav Spassov To: CC: Stanislav Spassov , Bjorn Helgaas , Thomas Gleixner , Andrew Morton , =?utf-8?q?Jan_H_=2E_Sch=C3=B6nherr?= , Jonathan Corbet , Ashok Raj , Alex Williamson , "Sinan Kaya" , Rajat Jain Subject: [PATCH v4 1/3] PCI: Refactor polling loop out of pci_dev_wait Date: Sat, 7 Mar 2020 18:20:42 +0100 Message-ID: <20200307172044.29645-2-stanspas@amazon.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200307172044.29645-1-stanspas@amazon.com> References: <20200307172044.29645-1-stanspas@amazon.com> MIME-Version: 1.0 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org From: Stanislav Spassov This patch does not (intentionally) introduce any observable difference in runtime behavior. Signed-off-by: Stanislav Spassov --- drivers/pci/pci.c | 70 +++++++++++++++++++++++++++++++++-------------- 1 file changed, 49 insertions(+), 21 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index d828ca835a98..44f5d4907db6 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -1021,47 +1021,75 @@ void pci_wakeup_bus(struct pci_bus *bus) pci_walk_bus(bus, pci_wakeup, NULL); } -static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout) +/* + * Performs DWORD Configuration Reads at a specific offset until the value read + * (with mask applied) is not equal to bad_value. + */ +static inline int pci_dev_poll_until_not_equal(struct pci_dev *dev, int where, + u32 mask, u32 bad_value, + const char *event_name, + int timeout, int *waited, + u32 *final_value) { int delay = 1; - u32 id; + u32 value; - /* - * 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 - * CRS SV is enabled and the read was for the Vendor ID; in that - * case it synthesizes 0x0001 data). - * - * Wait for the device to return a non-CRS completion. Read the - * Command register instead of Vendor ID so we don't have to - * contend with the CRS SV value. - */ - pci_read_config_dword(dev, PCI_COMMAND, &id); - while (id == ~0) { + if (!event_name) + event_name = ""; + + if (waited) + delay = *waited + 1; + + pci_read_config_dword(dev, where, &value); + + while ((value & mask) == bad_value) { if (delay > timeout) { pci_warn(dev, "not ready %dms after %s; giving up\n", - delay - 1, reset_type); + delay - 1, event_name); return -ENOTTY; } if (delay > 1000) pci_info(dev, "not ready %dms after %s; waiting\n", - delay - 1, reset_type); + delay - 1, event_name); msleep(delay); delay *= 2; - pci_read_config_dword(dev, PCI_COMMAND, &id); + + pci_read_config_dword(dev, where, &value); } if (delay > 1000) - pci_info(dev, "ready %dms after %s\n", delay - 1, - reset_type); + pci_info(dev, "ready %dms after %s\n", delay - 1, event_name); + + if (waited) + *waited = delay - 1; + + if (final_value) + *final_value = value; return 0; } +static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout) +{ + /* + * 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 + * CRS SV is enabled and the read was for the Vendor ID; in that + * case it synthesizes 0x0001 data). + * + * Wait for the device to return a non-CRS completion. Read the + * Command register instead of Vendor ID so we don't have to + * contend with the CRS SV value. + */ + return pci_dev_poll_until_not_equal(dev, PCI_COMMAND, ~0, ~0, + reset_type, timeout, NULL, + NULL); +} + /** * pci_power_up - Put the given device into D0 * @dev: PCI device to power up From patchwork Sat Mar 7 17:20:43 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stanislav Spassov X-Patchwork-Id: 1250918 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-pci-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=amazon.com header.i=@amazon.com header.a=rsa-sha256 header.s=amazon201209 header.b=uGF5u/fU; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 48ZWVt5hkxz9sPK for ; Sun, 8 Mar 2020 04:21:42 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726174AbgCGRVm (ORCPT ); Sat, 7 Mar 2020 12:21:42 -0500 Received: from smtp-fw-9102.amazon.com ([207.171.184.29]:59258 "EHLO smtp-fw-9102.amazon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726109AbgCGRVm (ORCPT ); Sat, 7 Mar 2020 12:21:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1583601700; x=1615137700; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=AV9Cs1W7Saj9rP6tXuDZlO4fggKNzxo4CeWdS2NgJVA=; b=uGF5u/fU/OdYqKUifXn2Bdtl5d4H6lYC4YVidP5mUuaY0GVSFCXWF+8q mqfqjxpqcMKWvnCAElMGvE9g+kPxYBCjF4rLYC7oizREd+rkVsmaWbw/s VweoRJ8QgUpjMDq1QBoyu/or9EibRI3DftutdgZV+JIk4EhBNcMjXDeS0 Q=; IronPort-SDR: oJ7e01Vy8Q/m+RATSO4niv4uFrpLMYaq9871dfcOS0vKTYupCXtWinQf8P9b16YBkZ0E6dIXut ze8TKCnXOYTw== X-IronPort-AV: E=Sophos;i="5.70,526,1574121600"; d="scan'208";a="29836567" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1e-27fb8269.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 07 Mar 2020 17:21:37 +0000 Received: from EX13MTAUEA002.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-27fb8269.us-east-1.amazon.com (Postfix) with ESMTPS id A43E5A21EF; Sat, 7 Mar 2020 17:21:34 +0000 (UTC) Received: from EX13D04EUA004.ant.amazon.com (10.43.165.150) by EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Sat, 7 Mar 2020 17:21:13 +0000 Received: from EX13MTAUEE002.ant.amazon.com (10.43.62.24) by EX13D04EUA004.ant.amazon.com (10.43.165.150) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 7 Mar 2020 17:21:12 +0000 Received: from u961addbe640f56.ant.amazon.com (10.28.84.111) by mail-relay.amazon.com (10.43.62.224) with Microsoft SMTP Server id 15.0.1367.3 via Frontend Transport; Sat, 7 Mar 2020 17:21:10 +0000 From: Stanislav Spassov To: CC: Stanislav Spassov , Bjorn Helgaas , Thomas Gleixner , Andrew Morton , =?utf-8?q?Jan_H_=2E_Sch=C3=B6nherr?= , Jonathan Corbet , Ashok Raj , Alex Williamson , "Sinan Kaya" , Rajat Jain Subject: [PATCH v4 2/3] PCI: Cache CRS Software Visibiliy in struct pci_dev Date: Sat, 7 Mar 2020 18:20:43 +0100 Message-ID: <20200307172044.29645-3-stanspas@amazon.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200307172044.29645-1-stanspas@amazon.com> References: <20200307172044.29645-1-stanspas@amazon.com> MIME-Version: 1.0 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org From: Stanislav Spassov 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 --- 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 3840a541a9de..1c222c7c2572 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -354,6 +354,9 @@ struct pci_dev { user sysfs */ unsigned int clear_retrain_link:1; /* Need to clear Retrain Link bit manually */ + unsigned int crssv_enabled:1; /* Configuration Request Retry + Status Software Visibility + enabled on (parent) bridge */ unsigned int d3_delay; /* D3->D0 transition time in ms */ unsigned int d3cold_delay; /* D3cold->D0 transition time in ms */ From patchwork Sat Mar 7 17:20:44 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stanislav Spassov X-Patchwork-Id: 1250919 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-pci-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=amazon.com header.i=@amazon.com header.a=rsa-sha256 header.s=amazon201209 header.b=f4T/63CJ; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 48ZWVw1jS5z9sPK for ; Sun, 8 Mar 2020 04:21:44 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726109AbgCGRVn (ORCPT ); Sat, 7 Mar 2020 12:21:43 -0500 Received: from smtp-fw-9102.amazon.com ([207.171.184.29]:59258 "EHLO smtp-fw-9102.amazon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726168AbgCGRVn (ORCPT ); Sat, 7 Mar 2020 12:21:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1583601702; x=1615137702; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=tS/0owXmOCDGEdMSxbFS+CwbTU1bCqe9UC/48sU2UHU=; b=f4T/63CJtx+Q6CPJuGBE5tN0GUVXDD74CDf6rI6M48mB98C7/k/v7l0g KcdZyyyvejw1zHoT60X93tW4zd4JmuJuHP5D2dnd0amnTBk6UG4vcPLmn glESuUebUJbMngRgT2JdcJQmhDNQ68FsWaxm5LE8uwtwhQdYShk1MLSfk 0=; IronPort-SDR: kC292tiqsTLxppFOtSkiYHEEhZXEQEhrJIb+KVO8rSkCXpzlutjvwpOYyGI2NX7288sIk7OUar 6wyO6vgCTFqw== X-IronPort-AV: E=Sophos;i="5.70,526,1574121600"; d="scan'208";a="29836569" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1a-807d4a99.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 07 Mar 2020 17:21:39 +0000 Received: from EX13MTAUEA002.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1a-807d4a99.us-east-1.amazon.com (Postfix) with ESMTPS id 609D3A252F; Sat, 7 Mar 2020 17:21:36 +0000 (UTC) Received: from EX13D12EUC003.ant.amazon.com (10.43.164.161) by EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Sat, 7 Mar 2020 17:21:17 +0000 Received: from EX13MTAUEE002.ant.amazon.com (10.43.62.24) by EX13D12EUC003.ant.amazon.com (10.43.164.161) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 7 Mar 2020 17:21:15 +0000 Received: from u961addbe640f56.ant.amazon.com (10.28.84.111) by mail-relay.amazon.com (10.43.62.224) with Microsoft SMTP Server id 15.0.1367.3 via Frontend Transport; Sat, 7 Mar 2020 17:21:13 +0000 From: Stanislav Spassov To: CC: Stanislav Spassov , Bjorn Helgaas , Thomas Gleixner , Andrew Morton , =?utf-8?q?Jan_H_=2E_Sch=C3=B6nherr?= , Jonathan Corbet , Ashok Raj , Alex Williamson , "Sinan Kaya" , Rajat Jain Subject: [PATCH v4 3/3] PCI: Add CRS handling to pci_dev_wait() Date: Sat, 7 Mar 2020 18:20:44 +0100 Message-ID: <20200307172044.29645-4-stanspas@amazon.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200307172044.29645-1-stanspas@amazon.com> References: <20200307172044.29645-1-stanspas@amazon.com> MIME-Version: 1.0 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org From: Stanislav Spassov The PCI Express specification dictates minimal amounts of time that the host needs to wait after triggering different kinds of resets before it is allowed to attempt accessing the device. After this waiting period, devices are required to be responsive to Configuration Space reads. However, if a device needs more time to actually complete the reset operation internally, it may respond to the read with a Completion Request Retry Status (CRS), and keep doing so on subsequent reads for as long as necessary. If the device is broken, it may even keep responding with CRS indefinitely. The specification also mandates that any Root Port that supports CRS and has CRS Software Visibility (CRS SV) enabled will synthesize the special value 0x0001 for the Vendor ID and set any other bits to 1 upon receiving a CRS Completion for a Configuration Read Request that includes both bytes of the Vendor ID (offset 0). If CRS SV is disabled or a different register (not Vendor ID) is being read, the request is retried autonomously by the Root Port. Platform-specific configuration registers may exist to limit the number of or time taken by such retries. If CRS is not supported, or a device is responding with CA/UR Completions (rather than CRS), the behavior is platform-dependent, but generally the Root Port synthesizes ~0 to complete the software read. Previously, pci_dev_wait() avoided taking advantage of CRS. However, on platforms where no retry limit/timeout can be configured, a device responding with CRS for too long (e.g. because it is stuck and cannot complete its reset) may trigger more severe error conditions (e.g. TOR timeout, 3-strike CPU CATERR), because the Root Port never reports back to the lower-level component requesting the transaction. This patch introduces special handling when CRS is available, and otherwise falls back to the previous behavior of polling COMMAND. Signed-off-by: Stanislav Spassov --- drivers/pci/pci.c | 55 ++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 47 insertions(+), 8 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 44f5d4907db6..a028147f4471 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -1073,17 +1073,56 @@ static inline int pci_dev_poll_until_not_equal(struct pci_dev *dev, int where, static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout) { + int waited = 0; + int rc = 0; + + /* * 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 - * CRS SV is enabled and the read was for the Vendor ID; in that - * case it synthesizes 0x0001 data). - * - * Wait for the device to return a non-CRS completion. Read the - * Command register instead of Vendor ID so we don't have to - * contend with the CRS SV value. + * responding to them with CRS completions. For such completions: + * - If CRS SV is enabled on the Root Port, and the read request + * covers both bytes of the Vendor ID register, the Root Port + * will synthesize the value 0x0001 (and set any extra requested + * bytes to 0xff) + * - If CRS SV is not enabled on the Root Port, the Root Port must + * re-issue the Configuration Request as a new Request. + * Depending on platform-specific Root Complex configurations, + * the Root Port may stop retrying after a set number of attempts, + * or a configured timeout is hit, or continue indefinitely + * (ultimately resulting in non-PCI-specific platform errors, such as + * a TOR timeout). + */ + if (dev->crssv_enabled) { + u32 id; + + rc = pci_dev_poll_until_not_equal(dev, PCI_VENDOR_ID, 0xffff, + 0x0001, reset_type, timeout, + &waited, &id); + if (rc) + return rc; + + timeout -= waited; + + /* + * If Vendor/Device ID is valid, the device must be ready. + * Note: SR-IOV VFs return ~0 for reads to Vendor/Device + * ID and will not be recognized as ready by this check. + */ + if (id != 0x0000ffff && id != 0xffff0000 && + id != 0x00000000 && id != 0xffffffff) + return 0; + } + + /* + * Root Ports will generally indicate error scenarios (e.g. + * internal timeouts, or received Completion with CA/UR) by + * synthesizing an 'all bits set' value (~0). + * In case CRS is not supported/enabled, as well as for SR-IOV VFs, + * fall back to polling a different register that cannot validly + * contain ~0. As of PCIe 5.0, bits 11-15 of COMMAND are still RsvdP + * and must return 0 when read. + * XXX: These bits might become meaningful in the future */ return pci_dev_poll_until_not_equal(dev, PCI_COMMAND, ~0, ~0, reset_type, timeout, NULL,