linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Sinan Kaya <okaya@kernel.org>
Cc: linux-pci@vger.kernel.org,
	Mike Marciniszyn <mike.marciniszyn@intel.com>,
	Dennis Dalessandro <dennis.dalessandro@intel.com>,
	Doug Ledford <dledford@redhat.com>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Derek Chickles <derek.chickles@caviumnetworks.com>,
	Satanand Burla <satananda.burla@caviumnetworks.com>,
	Felix Manlunas <felix.manlunas@caviumnetworks.com>,
	Raghu Vatsavayi <raghu.vatsavayi@caviumnetworks.com>,
	"David S. Miller" <davem@davemloft.net>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Juergen Gross <jgross@suse.com>,
	Jia-Ju Bai <baijiaju1990@gmail.com>
Subject: Re: [PATCH v5 08/11] PCI: Unify pci_reset_function_locked() and __pci_reset_function_locked()
Date: Thu, 11 Oct 2018 10:02:41 -0600	[thread overview]
Message-ID: <20181011100241.42c10935@w520.home> (raw)
In-Reply-To: <20181011045008.32212-8-okaya@kernel.org>

On Thu, 11 Oct 2018 04:50:00 +0000
Sinan Kaya <okaya@kernel.org> wrote:

> The difference between pci_reset_function_locked() and
> __pci_reset_function_locked() is the saving and restoring of the registers.
> Unify these API by adding saverestore argument that caller passes.
> 
> Signed-off-by: Sinan Kaya <okaya@kernel.org>
> ---
>  drivers/infiniband/hw/hfi1/pcie.c               |  2 +-
>  drivers/net/ethernet/cavium/liquidio/lio_main.c |  2 +-
>  drivers/pci/pci.c                               | 10 +++++++---
>  drivers/pci/pci.h                               |  1 +
>  drivers/xen/xen-pciback/pci_stub.c              |  6 +++---
>  include/linux/pci.h                             |  4 ++--
>  6 files changed, 15 insertions(+), 10 deletions(-)

TBH, I'm not a fan of this patch or the remainder in this series.
Having a function prefixed with underscored or specifically indicate
locked tells callers that these are special cases and should be
understood before using.  Adding bool parameters to the common
functions ensures that every caller now needs to understand those
special cases and potentially get them wrong.  Also, a string of random
bool options to a function means that any time we want to use it we
need to go reexamine the function definition.  It's not intuitive to
use or review.  Thanks,

Alex

  reply	other threads:[~2018-10-11 16:02 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-11  4:49 [PATCH v5 01/11] PCI: Expose reset_type to users of __pci_reset_function_locked() Sinan Kaya
2018-10-11  4:49 ` [PATCH v5 02/11] PCI: Expose reset_type to users of pci_reset_function() Sinan Kaya
2018-10-11  4:49 ` [PATCH v5 03/11] PCI: Expose reset_type to users of pci_reset_function_locked() Sinan Kaya
2018-10-11  4:49 ` [PATCH v5 04/11] PCI: Expose reset type to users of pci_try_reset_function() Sinan Kaya
2018-10-11  4:49 ` [PATCH v5 05/11] PCI: Expose reset type to users of pci_probe_reset_function() Sinan Kaya
2018-10-11  4:49 ` [PATCH v5 06/11] PCI: Expose reset type to users of pci_reset_bus() Sinan Kaya
2018-10-11 15:33   ` Alex Williamson
2018-10-11 15:36     ` Sinan Kaya
2018-10-11  4:49 ` [PATCH v5 07/11] IB/hfi1,PCI: switch to __pci_function_locked() for reset request Sinan Kaya
2018-10-11  4:50 ` [PATCH v5 08/11] PCI: Unify pci_reset_function_locked() and __pci_reset_function_locked() Sinan Kaya
2018-10-11 16:02   ` Alex Williamson [this message]
2018-10-11 16:11     ` Sinan Kaya
2018-10-12  9:18   ` Christoph Hellwig
2018-10-12 14:46     ` Sinan Kaya
2018-10-11  4:50 ` [PATCH v5 09/11] PCI: Add options to pci_reset_function Sinan Kaya
2018-10-12  9:18   ` Christoph Hellwig
2018-10-11  4:50 ` [PATCH v5 10/11] PCI: Hide pci_reset_function_locked() Sinan Kaya
2018-10-11  4:50 ` [PATCH v5 11/11] PCI: Hide pcie_flr() in favor of pci_reset_function() Sinan Kaya
2018-10-11 15:41   ` Sinan Kaya

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181011100241.42c10935@w520.home \
    --to=alex.williamson@redhat.com \
    --cc=baijiaju1990@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=davem@davemloft.net \
    --cc=dennis.dalessandro@intel.com \
    --cc=derek.chickles@caviumnetworks.com \
    --cc=dledford@redhat.com \
    --cc=felix.manlunas@caviumnetworks.com \
    --cc=jgg@ziepe.ca \
    --cc=jgross@suse.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=mike.marciniszyn@intel.com \
    --cc=okaya@kernel.org \
    --cc=raghu.vatsavayi@caviumnetworks.com \
    --cc=satananda.burla@caviumnetworks.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).