From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752373AbdLNMwN (ORCPT ); Thu, 14 Dec 2017 07:52:13 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:54646 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751914AbdLNMwM (ORCPT ); Thu, 14 Dec 2017 07:52:12 -0500 Date: Thu, 14 Dec 2017 04:52:06 -0800 From: Christoph Hellwig To: Bjorn Helgaas Cc: Govinda Tatti , jgross@suse.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, JBeulich@suse.com, bhelgaas@google.com, xen-devel@lists.xenproject.org, boris.ostrovsky@Oracle.COM, roger.pau@citrix.com, Christoph Hellwig Subject: Re: [Xen-devel] [PATCH V3 1/2] Drivers/PCI: Export pcie_has_flr() interface Message-ID: <20171214125206.GA24958@infradead.org> 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> <20171212005919.GB30595@bhelgaas-glaptop.roam.corp.google.com> <49956aaf-5fd5-939d-5fc7-231ffdb98b70@Oracle.COM> <20171213212420.GH30595@bhelgaas-glaptop.roam.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171213212420.GH30595@bhelgaas-glaptop.roam.corp.google.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 13, 2017 at 03:24:21PM -0600, Bjorn Helgaas wrote: > Prior to a60a2b73ba69, we had > > int pcie_flr(struct pci_dev *dev, int probe); > > like all the other reset methods. AFAICT, the addition of > pcie_has_flr() was to optimize the path slightly because when drivers > call pcie_flr(), they should already know that their hardware supports > FLR. But I don't think that optimization is worth the extra code > complexity. If we do need to optimize it, we can check this in the > core during enumeration and set PCI_DEV_FLAGS_NO_FLR_RESET > accordingly. > > Christoph, chime in if I'm missing something here. Didn't we just have that discussion in another thread a few days ago? I think that the pcie_has_flr was a mistake in retrospective but I think the bool probe API was an even bigger mistake. The only use of it is to hide the reset attribute in sysfs. I'd much rather always have it and have it return EOPNOTSUPP if no reset method is supported. I can send a patch for that if it sounds fine to you.