Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3057282pxk; Mon, 21 Sep 2020 04:17:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxKSeD2WQglpKYupwibFGMN0BQuEMp201sNZ2D/NK7CWG6IN07NGPOXq0cUS3d/57e8i2m+ X-Received: by 2002:a17:906:cf9b:: with SMTP id um27mr49499894ejb.66.1600687053174; Mon, 21 Sep 2020 04:17:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600687053; cv=none; d=google.com; s=arc-20160816; b=qBUOYnL7ovkUxM8smdxmLlgNvTMEe9jujtanuR43JBfbJdu1rGO45eWFV1cIk0stGD ycGrQ0XReT+JdkGwvhdNhdlKpw9wXy9zSK5vZcjcAkXqPK7a+/GJGQ1QUQ6UWnTCfLYm 3X/Dji4z1/iqGsm8n6+/oatw/IodDOl5PRkGduhZxWvKvh2qE8lMXFj141ifo7hi97yt rq4HsPo1yQDuqVebSN54rCSvitBhmS+Xt32EqtHzuMeh+x/QXesK/h9N9tKH1fJlMEYY wbDlnt3ZxX+1jUAvzS6YtKtmkVUkznLJXYoAvARLFNWNmGV3jwVCdU9Th0Wa13RWKiGd iVuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=GHexvS46P8P3yM7UT4rUqbWuQKCE/6gipeLMHDyOSs8=; b=jEuXY1Lh6xCKgrTW+gOcUZKVqOA4+niDl0T75LC2eyuD6AhY6an5brUE4d1bI6rumI b9BErKZtEYAjo4xXnGpBikawTkQubSqX+PoPeDQMupZMNvJH/SLuFtq/oZ1hEawTs4lS V1B4PObyCeITiv2AcP8kp9CuNAth4lclyrSd0bCSeNOVY+/dnQXnPLYV+mUUSK/dGIMT 7mdp9kqn/XfGTilzjRgQ1bYGAXPV5hgQMLMi94HTcmRABcVzqaT+5scqAKJKKImAX60P I9JyfXBA9THR0lNnRFzURcLcm5yWWIhMk199XRHwswcJNWQKwO8bUrEPgUhzUJGBPFN1 QbAA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p9si8004681ejy.150.2020.09.21.04.17.10; Mon, 21 Sep 2020 04:17:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726584AbgIULPi (ORCPT + 99 others); Mon, 21 Sep 2020 07:15:38 -0400 Received: from lhrrgout.huawei.com ([185.176.76.210]:2899 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726353AbgIULPg (ORCPT ); Mon, 21 Sep 2020 07:15:36 -0400 Received: from lhreml710-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 9FFDB116C53DF929762B; Mon, 21 Sep 2020 12:15:34 +0100 (IST) Received: from localhost (10.52.121.13) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 21 Sep 2020 12:15:34 +0100 Date: Mon, 21 Sep 2020 12:13:55 +0100 From: Jonathan Cameron To: Sean V Kelley CC: , , , , , , , Subject: Re: [PATCH v5 05/10] PCI/AER: Apply function level reset to RCiEP on fatal error Message-ID: <20200921121355.00002b77@Huawei.com> In-Reply-To: <20200918204603.62100-6-sean.v.kelley@intel.com> References: <20200918204603.62100-1-sean.v.kelley@intel.com> <20200918204603.62100-6-sean.v.kelley@intel.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.52.121.13] X-ClientProxiedBy: lhreml744-chm.china.huawei.com (10.201.108.194) To lhreml710-chm.china.huawei.com (10.201.108.61) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 18 Sep 2020 13:45:58 -0700 Sean V Kelley wrote: > From: Qiuxu Zhuo > > Attempt to do function level reset for an RCiEP associated with an > RCEC device on fatal error. I'm not sure the description is correct. Looks like it will do the reset even if not associated with an RCEC. I'd just cut this down to: "Attempt to do a function level reset for an RCiEP on fatal error." I'm not 100% sure doing an flr will actually help in most cass if you've reported a fatal error, but I suppose it does no harm! So with description changed. Reviewed-by: Jonathan Cameron > > Signed-off-by: Qiuxu Zhuo > --- > drivers/pci/pcie/err.c | 31 ++++++++++++++++++++++--------- > 1 file changed, 22 insertions(+), 9 deletions(-) > > diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c > index e575fa6cee63..5380ecc41506 100644 > --- a/drivers/pci/pcie/err.c > +++ b/drivers/pci/pcie/err.c > @@ -169,6 +169,17 @@ static void pci_bridge_walk(struct pci_dev *bridge, int (*cb)(struct pci_dev *, > cb(bridge, userdata); > } > > +static pci_ers_result_t flr_on_rciep(struct pci_dev *dev) > +{ > + if (!pcie_has_flr(dev)) > + return PCI_ERS_RESULT_NONE; > + > + if (pcie_flr(dev)) > + return PCI_ERS_RESULT_DISCONNECT; > + > + return PCI_ERS_RESULT_RECOVERED; > +} > + > pci_ers_result_t pcie_do_recovery(struct pci_dev *dev, > pci_channel_state_t state, > pci_ers_result_t (*reset_subordinate_devices)(struct pci_dev *pdev)) > @@ -195,15 +206,17 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev, > if (state == pci_channel_io_frozen) { > pci_bridge_walk(bridge, report_frozen_detected, &status); > if (type == PCI_EXP_TYPE_RC_END) { > - pci_warn(dev, "link reset not possible for RCiEP\n"); > - status = PCI_ERS_RESULT_NONE; > - goto failed; > - } > - > - status = reset_subordinate_devices(bridge); > - if (status != PCI_ERS_RESULT_RECOVERED) { > - pci_warn(dev, "subordinate device reset failed\n"); > - goto failed; > + status = flr_on_rciep(dev); > + if (status != PCI_ERS_RESULT_RECOVERED) { > + pci_warn(dev, "function level reset failed\n"); > + goto failed; > + } > + } else { > + status = reset_subordinate_devices(bridge); > + if (status != PCI_ERS_RESULT_RECOVERED) { > + pci_warn(dev, "subordinate device reset failed\n"); > + goto failed; > + } > } > } else { > pci_bridge_walk(bridge, report_normal_detected, &status);