Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2365705imm; Sun, 9 Sep 2018 23:11:32 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZF5bLtfaZzl79BiTvzyiTAQSz7tdtMUXJP3972rcdAvCCVJvIVuCPS2Fl1/oIh4kl1ME7x X-Received: by 2002:a62:760a:: with SMTP id r10-v6mr21929274pfc.207.1536559892853; Sun, 09 Sep 2018 23:11:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536559892; cv=none; d=google.com; s=arc-20160816; b=yHSrtsdJJDc+0htgbj9hDea1E2ScA0xeFzybuJ36wrUVwvkx/JiDtgNjLq+fqyzVXT Fb3oDuC0swQJlkxdNjhIkEeGouoFkMEJ1AyyH/e/dD3YosZYr6zR7zFaZ0ZpzMp94dkJ 1LglGbWp4fl8R/vsyTVTX/F6qsN7u68pn5JqMWdCLdvgfrIlGrbJWtn5AgWqQGBjrFeY UbMuv0lt1qZSg/4QPq76myhSnWa7JpF3tFu22N9BKkpRzzJ58kOosAI4IpLuxhUnREB6 tTwuYZR1+7u2xfLAJK9vL/tAbM1d/AYKKGzDQn8w/OU1sUUE0s54/iBZjuAdx2kjZ8UD yXhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature:dkim-signature; bh=QF+kBu+Io/2fs+7mRlFivFoGFcNqsghpJ4FeB6kMakM=; b=BehTTcy3eUMzrMpGBsRxzfFXMeU3/w4OfWK9IX0A/W8T40sh2yIOCEX7+E0pihSLvX 7kjZTQrw29gVxadwkpXv3Xd1aDCtXua0hARsXmtq4xKMzeM20Z+7xGXgxOVkjjRs7pws 2F9z1Hojxp+s6J393s6bWVlnmpFP/CFF+NF+/03Cv3/uXJuZcjCgoM18AmG485scpNQM GtSGLei/zp7e0mYTvI8I7Uu72z1Bh/U2ueNqOHYBQYeBBOujwTin1onNRkp3fMjkb/NR KrBUtDccPCYATpB9cZdr6pBOsXwdtLHNpnSGngQ6wbzwK/FtQUGE/nrwQJSrxuvClNEq OdLQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b="ZBYP8/QO"; dkim=pass header.i=@codeaurora.org header.s=default header.b=D1Toa8C0; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z71-v6si15947732pff.223.2018.09.09.23.11.17; Sun, 09 Sep 2018 23:11:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b="ZBYP8/QO"; dkim=pass header.i=@codeaurora.org header.s=default header.b=D1Toa8C0; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727656AbeIJLC1 (ORCPT + 99 others); Mon, 10 Sep 2018 07:02:27 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:59592 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726185AbeIJLC1 (ORCPT ); Mon, 10 Sep 2018 07:02:27 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id E7D90606DD; Mon, 10 Sep 2018 06:10:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1536559803; bh=RN1eVSrMzYYfKNRJmGAJwgtrET0Fp6BzGtc2y64hDiU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ZBYP8/QOFRP5IE5sk7T/pr9Y/FSR35X88hnH19tie1sMGmeC+wCdiGLIHSijLRhi0 qlm1zjuv2eajAKew4LLB2+Wb6Qz7AnI02cYc92pwhuNiBwBUi/XDWEYpX4FTSB3RtW icQxakOH2O70L8++tvn/BbEwyPeKr36uxxGd+lSI= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 790E360594; Mon, 10 Sep 2018 06:10:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1536559802; bh=RN1eVSrMzYYfKNRJmGAJwgtrET0Fp6BzGtc2y64hDiU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=D1Toa8C05jHMWSjGP7cKjd2SAAUb3BZiOWMZyO/sg2w8ja67QjO/FV3Sx9qrC/bsJ OiAml233BV7ZcTLOObeZHmKuI22I1vURx1nt+h5cz8GLmbegVlXCOgO05DM9zQQfHl PQ1+DUchCXOOoRgPdIJ+uF45gLuOzLmkSu8g6gNU= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 10 Sep 2018 11:40:02 +0530 From: poza@codeaurora.org To: Bjorn Helgaas Cc: Bharat Kumar Gogada , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, bhelgaas@google.com, rgummal@xilinx.com, linux-pci-owner@vger.kernel.org Subject: Re: [PATCH v2] PCI/AER: Enable SERR# forwarding in non ACPI flow In-Reply-To: <20180905201047.GQ107892@bhelgaas-glaptop.roam.corp.google.com> References: <1533826657-24552-1-git-send-email-bharat.kumar.gogada@xilinx.com> <2f53b7dd9c1464f40b10217eb64d511e@codeaurora.org> <20180905201047.GQ107892@bhelgaas-glaptop.roam.corp.google.com> Message-ID: X-Sender: poza@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-09-06 01:40, Bjorn Helgaas wrote: > On Thu, Aug 09, 2018 at 08:41:27PM +0530, poza@codeaurora.org wrote: >> On 2018-08-09 20:27, Bharat Kumar Gogada wrote: >> > As per Figure 6-3 in PCIe r4.0, sec 6.2.6, ERR_ messages >> > will be forwarded from the secondary interface to the primary interface, >> > if the SERR# Enable bit in the Bridge Control register is set. >> > Currently PCI_BRIDGE_CTL_SERR is being enabled only in >> > ACPI flow. >> > This patch enables PCI_BRIDGE_CTL_SERR for Type-1 PCI device. >> > >> > Signed-off-by: Bharat Kumar Gogada >> > --- >> > drivers/pci/pcie/aer.c | 23 +++++++++++++++++++++++ >> > 1 files changed, 23 insertions(+), 0 deletions(-) >> > >> > diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c >> > index a2e8838..4fb0d24 100644 >> > --- a/drivers/pci/pcie/aer.c >> > +++ b/drivers/pci/pcie/aer.c >> > @@ -343,6 +343,20 @@ int pci_enable_pcie_error_reporting(struct pci_dev >> > *dev) >> > if (!dev->aer_cap) >> > return -EIO; >> > >> > + if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) { >> > + u16 control; >> > + >> > + /* >> > + * A Type-1 PCI bridge will not forward ERR_ messages coming >> > + * from an endpoint if SERR# forwarding is not enabled. >> > + */ >> > + pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &control); >> > + if (!(control & PCI_BRIDGE_CTL_SERR)) { >> > + control |= PCI_BRIDGE_CTL_SERR; >> > + pci_write_config_word(dev, PCI_BRIDGE_CONTROL, control); >> > + } >> > + } >> > + >> > return pcie_capability_set_word(dev, PCI_EXP_DEVCTL, >> > PCI_EXP_AER_FLAGS); >> > } >> > EXPORT_SYMBOL_GPL(pci_enable_pcie_error_reporting); >> > @@ -352,6 +366,15 @@ int pci_disable_pcie_error_reporting(struct pci_dev >> > *dev) >> > if (pcie_aer_get_firmware_first(dev)) >> > return -EIO; >> > >> > + if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) { >> > + u16 control; >> > + >> > + /* Clear SERR Forwarding */ >> > + pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &control); >> > + control &= ~PCI_BRIDGE_CTL_SERR; >> > + pci_write_config_word(dev, PCI_BRIDGE_CONTROL, control); >> > + } >> > + >> > return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL, >> > PCI_EXP_AER_FLAGS); >> > } >> >> >> Hi Bjorn, >> >> I made some comments on patchv1., same I am putting it across here. >> >> what about hot-plug case ? >> should not aer_init() call pci_enable_pcie_error_reporting() for all >> the downstream pci_dev ? >> and remove all the calls from drivers.. >> aer_init will be called for each device (pci_dev) while pciehp does >> re-enumeration. >> so probable we might want to call pci_enable_pcie_error_reporting() >> but that dictates the design where AER framework is taking decision to >> enable error reporting on behalf of drivers as well. >> but thats fine I think, if drivers do not want to participate then >> they have >> to call pci_disable_pcie_error_reporting explicitly. >> does this make sense ? > > I just replied to the original patch; sorry, I forgot to add you to > the cc list. Bharat, when people respond to your v patch, can you > please add them (and anybody else *they* added) to the cc list when > you post your v patch? > > If we set PCI_BRIDGE_CTL_SERR in the pci_configure_device() path, > would that address your comments? yes, that should do. > > There's still a separate question of where and how we should configure > the error bits in PCI_EXP_DEVCTL (currently done in > pci_enable_pcie_error_reporting()). > > Bjorn