Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp282239pxk; Thu, 1 Oct 2020 02:10:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxL+PYzaGKcqt+eI/iw0nvQ172B/MaaP0SzOgW1mPwsUpr/swzO/v/N8GIQIM1yeY4MmBHA X-Received: by 2002:a17:906:5809:: with SMTP id m9mr6902295ejq.304.1601543402304; Thu, 01 Oct 2020 02:10:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601543402; cv=none; d=google.com; s=arc-20160816; b=tkd18xqwLVE/um+5mdLCXFBBZGbJ2C06EKn5A70f1QMA6GY0Oul47nwo+Q4jEoLu5P kKSYZNKWUI/jqgzSWHs502sezHUl2qwjzsFwxtHjcEkNNh/WJCCmChxCSEyziIf+hhdy +naFV1yIXAqw55lsfKKcg/6iud+xTXlQGe9IRxR0gZMzK0LUdQq0gE42vwwzrGAcAPTf 53e/c/oXNXeBDk9Rm6KUC3SWHlCCEs3J9OY0lMMVge5WtwGJmS5X0Vk2swjibig1QCke J+X+LfRhzTqsXqpD8MJlNry6QXpGrwf5unDVPCYKxcrgCE6YEn3+v7sIre89q+Yrbifp La8Q== 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=zuieoFyAAHfbMFL/niDuDN7tsQQdScEJujp85oQdMuY=; b=ExJicdM4MlaXotYMvQWwP9AuwruP/oDKTAAf8dCDSepB2gOFl9vPklut0LwH/N0cqx /h8M1lmJMa2wjZ79zxIn4VyEgIp3LfFLxnNgXfJQilzTWnVEJospTerHl5glYxZEYC9V eqiEM9Is61JQmSvtRDt+vfUP8B0u4TsazQ1rUjrMnMmzR5jomR8FibkmsLRyLCG2aiUT +YxT5zADpBu6lhX9c2/51aF489grom2g84hrI21ByN9TJuK5FIkiPIHa6IvSfmQga4bC wgqundg2K1a+Lm7LkK/+K1l+vfSQeT3Dx0PEhLt7IY4o54gYqG1d+YoQmWeN5EHwNIrD dovw== 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 p16si2676856ejb.522.2020.10.01.02.09.39; Thu, 01 Oct 2020 02:10:02 -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 S1731657AbgJAJIl (ORCPT + 99 others); Thu, 1 Oct 2020 05:08:41 -0400 Received: from lhrrgout.huawei.com ([185.176.76.210]:2937 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725921AbgJAJIl (ORCPT ); Thu, 1 Oct 2020 05:08:41 -0400 Received: from lhreml710-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id DCB6EF852BA1783EFB83; Thu, 1 Oct 2020 10:08:39 +0100 (IST) Received: from localhost (10.52.127.250) 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; Thu, 1 Oct 2020 10:08:39 +0100 Date: Thu, 1 Oct 2020 10:06:57 +0100 From: Jonathan Cameron To: Sean V Kelley CC: , , , , , , , , Sean V Kelley Subject: Re: [PATCH v7 05/13] PCI/ERR: Use "bridge" for clarity in pcie_do_recovery() Message-ID: <20201001090657.00003fe4@Huawei.com> In-Reply-To: <20200930215820.1113353-6-seanvk.dev@oregontracks.org> References: <20200930215820.1113353-1-seanvk.dev@oregontracks.org> <20200930215820.1113353-6-seanvk.dev@oregontracks.org> 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.127.250] X-ClientProxiedBy: lhreml754-chm.china.huawei.com (10.201.108.204) 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 Wed, 30 Sep 2020 14:58:12 -0700 Sean V Kelley wrote: > From: Sean V Kelley > > The term "dev" is being applied to root ports, switch > upstream ports, switch downstream ports, and the upstream > ports on endpoints. While endpoint upstream ports don't have > subordinate buses, a generic term such as "bridge" may be used This sentence is a bit confusing. The bit before the comma seems only slightly connected. Perhaps 2 sentences? > for something with a subordinate bus. The current conditional > logic in pcie_do_recovery() would also benefit from some > simplification with use of pci_upstream_bridge() in place of > dev->bus->self. Reverse the pcie_do_recovery() conditional logic > and replace use of "dev" with "bridge" for greater clarity. > > Suggested-by: Bjorn Helgaas > Signed-off-by: Sean V Kelley Acked-by: Jonathan Cameron > --- > drivers/pci/pcie/err.c | 20 +++++++++++++------- > 1 file changed, 13 insertions(+), 7 deletions(-) > > diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c > index 950612342f1c..c6922c099c76 100644 > --- a/drivers/pci/pcie/err.c > +++ b/drivers/pci/pcie/err.c > @@ -152,16 +152,22 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev, > { > pci_ers_result_t status = PCI_ERS_RESULT_CAN_RECOVER; > struct pci_bus *bus; > + struct pci_dev *bridge; > + int type; > > /* > - * Error recovery runs on all subordinates of the first downstream port. > - * If the downstream port detected the error, it is cleared at the end. > + * Error recovery runs on all subordinates of the first downstream > + * bridge. If the downstream bridge detected the error, it is > + * cleared at the end. > */ > - if (!(pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT || > - pci_pcie_type(dev) == PCI_EXP_TYPE_DOWNSTREAM)) > - dev = dev->bus->self; > - bus = dev->subordinate; > - > + type = pci_pcie_type(dev); > + if (type == PCI_EXP_TYPE_ROOT_PORT || > + type == PCI_EXP_TYPE_DOWNSTREAM) > + bridge = dev; > + else > + bridge = pci_upstream_bridge(dev); > + > + bus = bridge->subordinate; > pci_dbg(dev, "broadcast error_detected message\n"); > if (state == pci_channel_io_frozen) { > pci_walk_bus(bus, report_frozen_detected, &status);