| Message ID | 20180724000944.7671.64284.stgit@gimli.home (mailing list archive) |
|---|---|
| Headers | show
Return-Path: <linux-pci-owner@kernel.org>
Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org
[172.30.200.125])
by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id A063C9093
for <patchwork-linux-pci@patchwork.kernel.org>;
Tue, 24 Jul 2018 00:12:58 +0000 (UTC)
Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1])
by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 88B5928396
for <patchwork-linux-pci@patchwork.kernel.org>;
Tue, 24 Jul 2018 00:12:58 +0000 (UTC)
Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486)
id 7D0C828501; Tue, 24 Jul 2018 00:12:58 +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=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_HI autolearn=ham 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 262E128396
for <patchwork-linux-pci@patchwork.kernel.org>;
Tue, 24 Jul 2018 00:12:58 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S2388149AbeGXBQi (ORCPT
<rfc822;patchwork-linux-pci@patchwork.kernel.org>);
Mon, 23 Jul 2018 21:16:38 -0400
Received: from mx1.redhat.com ([209.132.183.28]:42206 "EHLO mx1.redhat.com"
rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
id S2388132AbeGXBQi (ORCPT <rfc822;linux-pci@vger.kernel.org>);
Mon, 23 Jul 2018 21:16:38 -0400
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com
[10.5.11.13])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.redhat.com (Postfix) with ESMTPS id 355A6308123F;
Tue, 24 Jul 2018 00:12:57 +0000 (UTC)
Received: from gimli.home (ovpn-116-105.phx2.redhat.com [10.3.116.105])
by smtp.corp.redhat.com (Postfix) with ESMTP id 86A6A608F3;
Tue, 24 Jul 2018 00:12:54 +0000 (UTC)
Subject: [PATCH v2 0/2] PCI: NVMe reset quirk
From: Alex Williamson <alex.williamson@redhat.com>
To: linux-pci@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org
Date: Mon, 23 Jul 2018 18:12:54 -0600
Message-ID: <20180724000944.7671.64284.stgit@gimli.home>
User-Agent: StGit/0.18-102-gdf9f
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
X-Greylist: Sender IP whitelisted,
not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.49]);
Tue, 24 Jul 2018 00:12:57 +0000 (UTC)
Sender: linux-pci-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-pci.vger.kernel.org>
X-Mailing-List: linux-pci@vger.kernel.org
X-Virus-Scanned: ClamAV using ClamSMTP
|
| Series |
PCI: NVMe reset quirk
|
expand
|
v2: Add bug link, use Samsung vendor ID, add spec references As discussed in the 2nd patch, at least one NVMe controller sometimes doesn't like being reset while enabled and another will timeout during a subsequent re-enable if it happens too quickly after reset. Introduce a device specific reset quirk for all NVMe class devices so that we can try to get reliable behavior from them for device assignment and any other users of the PCI subsystem reset interface. Patches against current PCI next branch. Thanks, Alex --- Alex Williamson (2): PCI: Export pcie_has_flr() PCI: NVMe device specific reset quirk drivers/pci/pci.c | 3 + drivers/pci/quirks.c | 118 ++++++++++++++++++++++++++++++++++++++++++++++++++ include/linux/pci.h | 1 3 files changed, 121 insertions(+), 1 deletion(-)