Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752134AbdLLA7s (ORCPT ); Mon, 11 Dec 2017 19:59:48 -0500 Received: from mail.kernel.org ([198.145.29.99]:37472 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751641AbdLLA7k (ORCPT ); Mon, 11 Dec 2017 19:59:40 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 13F6C2073F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=helgaas@kernel.org Date: Mon, 11 Dec 2017 18:59:19 -0600 From: Bjorn Helgaas To: Govinda Tatti Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, bhelgaas@google.com, boris.ostrovsky@Oracle.COM, jgross@suse.com, JBeulich@suse.com, roger.pau@citrix.com, konrad.wilk@Oracle.COM Subject: Re: [PATCH V3 1/2] Drivers/PCI: Export pcie_has_flr() interface Message-ID: <20171212005919.GB30595@bhelgaas-glaptop.roam.corp.google.com> References: <20171207222145.9769-1-Govinda.Tatti@Oracle.COM> <20171207222145.9769-2-Govinda.Tatti@Oracle.COM> <20171208202424.GC12367@bhelgaas-glaptop.roam.corp.google.com> <426eeeab-0dcd-8de3-9c5f-a166acf2c130@Oracle.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426eeeab-0dcd-8de3-9c5f-a166acf2c130@Oracle.COM> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1839 Lines: 47 On Mon, Dec 11, 2017 at 06:29:29PM -0600, Govinda Tatti wrote: > > Thanks Bjorn for your review comments. Please see below for my comments. > > On 12/8/2017 2:24 PM, Bjorn Helgaas wrote: > >On Thu, Dec 07, 2017 at 05:21:44PM -0500, Govinda Tatti wrote: > >>This patch exports pcie_has_flr() and it is being used by Xen pciback > >>driver to reset (flr/slot/bus) PCI devices based on 'reset' SysFS > >>attribute. > >> > >>Signed-off-by: Govinda Tatti > >>--- > >>v3: -New > >> > >> drivers/pci/pci.c | 3 ++- > >> include/linux/pci.h | 1 + > >> 2 files changed, 3 insertions(+), 1 deletion(-) > >> > >>diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > >>index 6078dfc..499e922 100644 > >>--- a/drivers/pci/pci.c > >>+++ b/drivers/pci/pci.c > >>@@ -3872,7 +3872,7 @@ static void pci_flr_wait(struct pci_dev *dev) > >> * Returns true if the device advertises support for PCIe function level > >> * resets. > >> */ > >>-static bool pcie_has_flr(struct pci_dev *dev) > >>+bool pcie_has_flr(struct pci_dev *dev) > >> { > >> u32 cap; > >>@@ -3882,6 +3882,7 @@ static bool pcie_has_flr(struct pci_dev *dev) > >> pcie_capability_read_dword(dev, PCI_EXP_DEVCAP, &cap); > >> return cap & PCI_EXP_DEVCAP_FLR; > >> } > >>+EXPORT_SYMBOL_GPL(pcie_has_flr); > >I'd rather change pcie_flr() so you could *always* call it, and it > >would return 0, -ENOTTY, or whatever, based on whether FLR is > >supported. Is that feasible? > Sure, I will add pcie_has_flr() logic inside pcie_flr() and return > appropriate > values as suggested by you. Do we still want to retain pcie_has_flr() and > its usage inside pci.c?.Otherwise, I will remove it and do required cleanup. If you can restructure the code and remove pcie_has_flr() while retaining the existing behavior of its callers, that would be great. Bjorn