All of lore.kernel.org
 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,
	Leon Romanovsky <leon@kernel.org>
Subject: Re: [PATCH v2 0/5] Expose and manage PCI device reset
Date: Fri, 30 Apr 2021 21:04:11 +0530	[thread overview]
Message-ID: <20210430153411.6xp6t4q2qmqbmkgj@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

A gentle ping ;)

Thanks,
Amey

  parent reply	other threads:[~2021-04-30 15:34 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 ` Amey Narkhede [this message]
2021-05-15  0:59 ` [PATCH v2 0/5] Expose and manage PCI device reset Amey Narkhede

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=20210430153411.6xp6t4q2qmqbmkgj@archlinux \
    --to=ameynarkhede03@gmail.com \
    --cc=alex.williamson@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=leon@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.