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,
kw@linux.com, Amey Narkhede <ameynarkhede03@gmail.com>
Subject: [PATCH RESEND v2 0/7] Expose and manage PCI device reset
Date: Thu, 20 May 2021 05:24:19 +0530 [thread overview]
Message-ID: <20210519235426.99728-1-ameynarkhede03@gmail.com> (raw)
[RESEND with Shanker's patches as those depend on this series]
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
Shanker Donthineni (2):
PCI: Add support for a function level reset based on _RST method
PCI: Enable NO_BUS_RESET quirk for Nvidia GPUs
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 | 206 +++++++++++-------
drivers/pci/pci.h | 10 +-
drivers/pci/pcie/aer.c | 12 +-
drivers/pci/probe.c | 4 +-
drivers/pci/quirks.c | 23 +-
include/linux/pci.h | 11 +-
10 files changed, 278 insertions(+), 103 deletions(-)
--
2.31.1
next reply other threads:[~2021-05-19 23:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-19 23:54 Amey Narkhede [this message]
2021-05-19 23:54 ` [PATCH RESEND v2 1/7] PCI: merge slot and bus reset implementations Amey Narkhede
2021-05-20 14:54 ` Krzysztof Wilczyński
2021-05-19 23:54 ` [PATCH RESEND v2 2/7] PCI: Add pcie_reset_flr to follow calling convention of other reset methods Amey Narkhede
2021-05-20 15:05 ` Krzysztof Wilczyński
2021-05-24 14:48 ` Amey Narkhede
2021-05-25 15:17 ` Krzysztof Wilczyński
2021-05-25 16:03 ` Amey Narkhede
2021-05-19 23:54 ` [PATCH RESEND v2 3/7] PCI: Add new array for keeping track of ordering of " Amey Narkhede
2021-05-20 15:26 ` Krzysztof Wilczyński
2021-05-19 23:54 ` [PATCH RESEND v2 4/7] PCI: Remove reset_fn field from pci_dev Amey Narkhede
2021-05-19 23:54 ` [PATCH RESEND v2 5/7] PCI/sysfs: Allow userspace to query and set device reset mechanism Amey Narkhede
2021-05-20 16:37 ` Krzysztof Wilczyński
2021-05-19 23:54 ` [PATCH RESEND v2 6/7] PCI: Add support for a function level reset based on _RST method Amey Narkhede
2021-05-19 23:54 ` [PATCH RESEND v2 7/7] PCI: Enable NO_BUS_RESET quirk for Nvidia GPUs 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=20210519235426.99728-1-ameynarkhede03@gmail.com \
--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 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.