From patchwork Fri Aug 11 16:56:35 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sinan Kaya X-Patchwork-Id: 9896349 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 9A3D260236 for ; Fri, 11 Aug 2017 16:57:14 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8C1CB285B0 for ; Fri, 11 Aug 2017 16:57:14 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 80FC628C4C; Fri, 11 Aug 2017 16:57:14 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3395D28C55 for ; Fri, 11 Aug 2017 16:57:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753622AbdHKQ4u (ORCPT ); Fri, 11 Aug 2017 12:56:50 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:41050 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753251AbdHKQ4q (ORCPT ); Fri, 11 Aug 2017 12:56:46 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 80C5860398; Fri, 11 Aug 2017 16:56:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1502470605; bh=Z1JxWXLoCBVi5wTJgty9W4F5nCGu/7DgRGEl/B3n4Kc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=maLjNCYDIXBqG197uk3S7HID8INsVSACKe/e6ghdgZiAy5/pVWjcdV18HG0rfpUL7 hVjJPP5xBfmI30lxggV04WR81GZNj1SvasGCoHmCL7FR3si4PjzjLN7N/e76wiaanT gGuQ6q5lzNNpPZK9B33R4a6nO8r4J6uNqGbSxzUc= Received: from drakthul.qualcomm.com (global_nat1_iad_fw.qualcomm.com [129.46.232.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: okaya@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id E9408601A1; Fri, 11 Aug 2017 16:56:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1502470604; bh=Z1JxWXLoCBVi5wTJgty9W4F5nCGu/7DgRGEl/B3n4Kc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gA2wDd4cBIb9Mm2DUAq/oRyFqB6KKpCoH/c6zbG9Hb/KJ70VeGPXyIwhF8/3/vb4Q XuprTCcK8s9pd0fYIy32Pf4jsCr/qzOAYNaZU5qiiMAe+8lqvUnd139gS6PmrwN8JF alSXT+dRBL95KziVvDqmBhZV6XD37TN3el8roIGU= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org E9408601A1 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=okaya@codeaurora.org From: Sinan Kaya 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 , Bjorn Helgaas , linux-kernel@vger.kernel.org Subject: [PATCH V10 2/3] PCI: handle CRS returned by device after FLR Date: Fri, 11 Aug 2017 12:56:35 -0400 Message-Id: <1502470596-4112-2-git-send-email-okaya@codeaurora.org> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1502470596-4112-1-git-send-email-okaya@codeaurora.org> References: <1502470596-4112-1-git-send-email-okaya@codeaurora.org> Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Sporadic reset issues have been observed with Intel 750 NVMe drive while assigning the physical function to the guest machine. The sequence of events observed is as follows: - perform a Function Level Reset (FLR) - sleep up to 1000ms total - read ~0 from PCI_COMMAND - warn that the device didn't return from FLR - touch the device before it's ready - drop register read and writes performing register settings restore - incomplete reset operation and partial register restoration - second time device probe fails in the guest machine as HW is left in limbo. An endpoint is allowed to issue Configuration Request Retry Status (CRS) following a FLR request to indicate that it is not ready to accept new requests. CRS is defined in PCIe r3.1, sec 2.3.1. Request Handling Rules and CRS usage in FLR context is mentioned in PCIe r3.1, sec 6.6.2. Function-Level Reset. A CRS indication will only be given if the address to be read is vendor ID register. pci_bus_read_dev_vendor_id() knows how to deal with CRS returned 0xFFFF0001 value and will continue polling until a value other than 0xFFFF0001 is returned within a given timeout. Try to discover device presence via CRS first. If device is not found, fall through to old behavior. Signed-off-by: Sinan Kaya --- drivers/pci/pci.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index af0cc34..c853551 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -3821,17 +3821,36 @@ static void pci_flr_wait(struct pci_dev *dev) { int i = 0; u32 id; + bool ret; + + /* + * Don't touch the HW before waiting 100ms. HW has to finish + * within 100ms according to PCI Express Base Specification + * Revision 3.1 Section 6.6.2: Function-Level Reset (FLR). + */ + msleep(100); + + if (pci_bus_read_config_dword(dev->bus, dev->devfn, PCI_VENDOR_ID, + &id)) + return; + + /* See if we can find a device via CRS first. */ + if ((id & 0xffff) == 0x0001) { + ret = pci_bus_wait_crs(dev->bus, dev->devfn, &id, 60000); + if (ret) + return; + } do { msleep(100); pci_read_config_dword(dev, PCI_COMMAND, &id); - } while (i++ < 10 && id == ~0); + } while (i++ < 9 && id == ~0); if (id == ~0) dev_warn(&dev->dev, "Failed to return from FLR\n"); else if (i > 1) dev_info(&dev->dev, "Required additional %dms to return from FLR\n", - (i - 1) * 100); + i * 100); } /**