linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Amey Narkhede <ameynarkhede03@gmail.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: alex.williamson@redhat.com, raphael.norwitz@nutanix.com,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Krzysztof Wilczyński" <kw@linux.com>
Subject: Re: [PATCH v2 0/5] Expose and manage PCI device reset
Date: Sat, 15 May 2021 06:29:42 +0530	[thread overview]
Message-ID: <20210515005942.nfcbdyn6fssuhld7@archlinux> (raw)
In-Reply-To: <20210409192324.30080-1-ameynarkhede03@gmail.com>

On 21/04/10 12:53AM, Amey Narkhede wrote:
> PCI and PCIe devices may support a number of possible reset mechanisms
> for example Function Level Reset (FLR) provided via Advanced Feature or
> PCIe capabilities, Power Management reset, bus reset, or device specific reset.
> Currently the PCI subsystem creates a policy prioritizing these reset methods
> which provides neither visibility nor control to userspace.
>
> Expose the reset methods available per device to userspace, via sysfs
> and allow an administrative user or device owner to have ability to
> manage per device reset method priorities or exclusions.
> This feature aims to allow greater control of a device for use cases
> as device assignment, where specific device or platform issues may
> interact poorly with a given reset method, and for which device specific
> quirks have not been developed.
>
> Changes in v2:
> 	- Use byte array instead of bitmap to keep track of
> 	  ordering of reset methods
> 	- Fix incorrect use of reset_fn field in octeon driver
> 	- Allow writing comma separated list of names of supported reset
> 	  methods to reset_method sysfs attribute
> 	- Writing empty string instead of "none" to reset_method attribute
> 	  disables ability of reset the device
>
> Sending Raphael's patch again as this series depends on it.
>
> Amey Narkhede (4):
>   PCI: Add pcie_reset_flr to follow calling convention of other reset
>     methods
>   PCI: Add new array for keeping track of ordering of reset methods
>   PCI: Remove reset_fn field from pci_dev
>   PCI/sysfs: Allow userspace to query and set device reset mechanism
>
> Raphael Norwitz (1):
>   PCI: merge slot and bus reset implementations
>
>  Documentation/ABI/testing/sysfs-bus-pci       |  16 ++
>  drivers/crypto/cavium/nitrox/nitrox_main.c    |   4 +-
>  .../ethernet/cavium/liquidio/lio_vf_main.c    |   2 +-
>  drivers/pci/pci-sysfs.c                       |  93 ++++++++-
>  drivers/pci/pci.c                             | 176 ++++++++++--------
>  drivers/pci/pci.h                             |  10 +-
>  drivers/pci/pcie/aer.c                        |  12 +-
>  drivers/pci/probe.c                           |   4 +-
>  drivers/pci/quirks.c                          |  11 +-
>  include/linux/pci.h                           |  11 +-
>  10 files changed, 236 insertions(+), 103 deletions(-)
>
> --
> 2.31.1

Hi Bjorn,
I guess as the merge window is closed this patch
won't get merged in 5.13. I was wondering if you
have any suggestions on this patch series so that I can
make changes meanwhile.

Thanks,
Amey

      parent reply	other threads:[~2021-05-15  0:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-09 19:23 [PATCH v2 0/5] Expose and manage PCI device reset Amey Narkhede
2021-04-09 19:23 ` [PATCH v2 1/5] PCI: merge slot and bus reset implementations Amey Narkhede
2021-04-09 19:23 ` [PATCH v2 2/5] PCI: Add pcie_reset_flr to follow calling convention of other reset methods Amey Narkhede
2021-04-09 19:23 ` [PATCH v2 3/5] PCI: Add new array for keeping track of ordering of " Amey Narkhede
2021-04-09 19:23 ` [PATCH v2 4/5] PCI: Remove reset_fn field from pci_dev Amey Narkhede
2021-04-09 19:23 ` [PATCH v2 5/5] PCI/sysfs: Allow userspace to query and set device reset mechanism Amey Narkhede
2021-04-30 15:34 ` [PATCH v2 0/5] Expose and manage PCI device reset Amey Narkhede
2021-05-15  0:59 ` Amey Narkhede [this message]

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=20210515005942.nfcbdyn6fssuhld7@archlinux \
    --to=ameynarkhede03@gmail.com \
    --cc=alex.williamson@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=kw@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=raphael.norwitz@nutanix.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).