From: Raphael Norwitz <raphael.norwitz@nutanix.com>
To: Amey Narkhede <ameynarkhede03@gmail.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Raphael Norwitz <raphael.norwitz@nutanix.com>
Subject: Re: [PATCH 0/4] Expose and manage PCI device reset
Date: Sat, 13 Mar 2021 02:02:27 +0000 [thread overview]
Message-ID: <20210313020221.GA14334@raphael-debian-dev> (raw)
In-Reply-To: <20210312184038.to3g3px6ep4xfavn@archlinux>
On Sat, Mar 13, 2021 at 12:10:38AM +0530, Amey Narkhede wrote:
> On 21/03/12 11:20AM, Alex Williamson wrote:
> > On Fri, 12 Mar 2021 23:04:48 +0530
> > ameynarkhede03@gmail.com wrote:
> >
> > > From: Amey Narkhede <ameynarkhede03@gmail.com>
> > >
> > > 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.
> > >
> > > Suggested-by: Alex Williamson <alex.williamson@redhat.com>
> > > Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
> > > Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
> >
> > Reviews/Acks/Sign-off-by from others (aside from Tested/Reported-by)
> > really need to be explicit, IMO. This is a common issue for new
> > developers, but it really needs to be more formal. I wouldn't claim to
> > be able to speak for Raphael and interpret his comments so far as his
> > final seal of approval.
> >
> > Also in the patches, all Sign-offs/Reviews/Acks need to be above the
> > triple dash '---' line. Anything between that line and the beginning
> > of the diff is discarded by tools. People will often use that for
> > difference between version since it will be discarded on commit.
> > Likewise, the cover letter is not committed, so Review-by there are
> > generally not done. I generally make my Sign-off last in the chain and
> > maintainers will generally add theirs after that. This makes for a
> > chain where someone can read up from the bottom to see how this commit
> > entered the kernel. Reviews, Acks, and whatnot will therefore usually
> > be collected above the author posting the patch.
> >
> > Since this is a v1 patch and it's likely there will be more revisions,
> > rather than send a v2 immediately with corrections, I'd probably just
> > reply to the cover letter retracting Raphael's Review-by for him to
> > send his own and noting that you'll fix the commit reviews formatting,
> > but will wait for a bit for further comments before sending a new
> > version.
> >
> > No big deal, nice work getting it sent out. Thanks,
> >
> > Alex
> >
> Raphael sent me the email with
> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com> that
> is why I included it.
> So basically in v2 I should reorder tags such that Sign-off will be
> the last. Did I get that right? Or am I missing something?
>
Just to confirm, I did send
Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
for the latest version and I'm happy to have it on this series.
> Thanks,
> Amey
>
> > > Amey Narkhede (4):
> > > PCI: Refactor pcie_flr to follow calling convention of other reset
> > > methods
> > > PCI: Add new bitmap for keeping track of supported reset mechanisms
> > > PCI: Remove reset_fn field from pci_dev
> > > PCI/sysfs: Allow userspace to query and set device reset mechanism
> > >
> > > Documentation/ABI/testing/sysfs-bus-pci | 15 ++
> > > drivers/crypto/cavium/nitrox/nitrox_main.c | 4 +-
> > > drivers/crypto/qat/qat_common/adf_aer.c | 2 +-
> > > drivers/infiniband/hw/hfi1/chip.c | 4 +-
> > > drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +-
> > > .../ethernet/cavium/liquidio/lio_vf_main.c | 4 +-
> > > .../ethernet/cavium/liquidio/octeon_mailbox.c | 2 +-
> > > drivers/net/ethernet/freescale/enetc/enetc.c | 2 +-
> > > .../ethernet/freescale/enetc/enetc_pci_mdio.c | 2 +-
> > > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 +-
> > > drivers/pci/pci-sysfs.c | 68 +++++++-
> > > drivers/pci/pci.c | 160 ++++++++++--------
> > > drivers/pci/pci.h | 11 +-
> > > drivers/pci/pcie/aer.c | 12 +-
> > > drivers/pci/probe.c | 4 +-
> > > drivers/pci/quirks.c | 17 +-
> > > include/linux/pci.h | 17 +-
> > > 17 files changed, 213 insertions(+), 117 deletions(-)
> > >
> > > --
> > > 2.30.2
> > >
> >
next prev parent reply other threads:[~2021-03-13 2:21 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-12 17:34 [PATCH 0/4] Expose and manage PCI device reset ameynarkhede03
2021-03-12 17:34 ` [PATCH 1/4] PCI: Refactor pcie_flr to follow calling convention of other reset methods ameynarkhede03
2021-03-12 17:34 ` [PATCH 2/4] PCI: Add new bitmap for keeping track of supported reset mechanisms ameynarkhede03
2021-03-14 23:51 ` Pali Rohár
2021-03-12 17:34 ` [PATCH 3/4] PCI: Remove reset_fn field from pci_dev ameynarkhede03
2021-03-14 23:52 ` Pali Rohár
2021-03-12 17:34 ` [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device reset mechanism ameynarkhede03
2021-03-14 23:55 ` Pali Rohár
2021-03-15 13:43 ` Amey Narkhede
2021-03-15 13:52 ` Pali Rohár
2021-03-15 14:34 ` Alex Williamson
2021-03-15 14:52 ` Pali Rohár
2021-03-15 15:03 ` Alex Williamson
2021-03-17 19:02 ` Pali Rohár
2021-03-17 19:15 ` Alex Williamson
2021-03-17 19:24 ` Pali Rohár
2021-03-17 19:32 ` Alex Williamson
2021-03-17 19:40 ` Pali Rohár
2021-03-17 20:00 ` Alex Williamson
2021-03-17 20:13 ` Pali Rohár
2021-03-18 14:31 ` Amey Narkhede
2021-03-23 14:34 ` Pali Rohár
2021-03-23 14:44 ` Alex Williamson
2021-03-23 15:32 ` Amey Narkhede
2021-03-23 16:06 ` Alex Williamson
2021-03-23 16:15 ` Alex Williamson
2021-03-15 15:07 ` Leon Romanovsky
2021-03-15 15:33 ` Amey Narkhede
2021-03-15 16:29 ` Alex Williamson
2021-03-15 18:32 ` Raphael Norwitz
2021-03-17 4:20 ` Leon Romanovsky
2021-03-17 10:24 ` Amey Narkhede
2021-03-17 11:02 ` Leon Romanovsky
2021-03-17 11:23 ` Amey Narkhede
2021-03-17 11:47 ` Leon Romanovsky
2021-03-17 13:17 ` Amey Narkhede
2021-03-17 13:58 ` Leon Romanovsky
2021-03-17 17:31 ` Alex Williamson
2021-03-18 9:09 ` Leon Romanovsky
2021-03-18 14:22 ` Amey Narkhede
2021-03-18 14:57 ` Leon Romanovsky
2021-03-18 17:01 ` Amey Narkhede
2021-03-18 17:35 ` Leon Romanovsky
2021-03-18 17:43 ` Amey Narkhede
2021-03-18 18:14 ` Enrico Weigelt, metux IT consult
2021-03-19 13:05 ` Leon Romanovsky
2021-03-19 15:23 ` Amey Narkhede
2021-03-19 15:37 ` Leon Romanovsky
2021-03-19 15:53 ` Amey Narkhede
2021-03-18 17:58 ` Enrico Weigelt, metux IT consult
2021-03-19 13:07 ` Leon Romanovsky
2021-03-18 16:39 ` Alex Williamson
2021-03-18 17:22 ` Leon Romanovsky
2021-03-18 17:38 ` Amey Narkhede
2021-03-18 18:34 ` Enrico Weigelt, metux IT consult
2021-03-19 12:59 ` Leon Romanovsky
2021-03-19 13:48 ` Enrico Weigelt, metux IT consult
2021-03-19 15:51 ` Leon Romanovsky
2021-03-19 15:57 ` Bjorn Helgaas
2021-03-19 16:24 ` Leon Romanovsky
2021-03-19 16:23 ` Alex Williamson
2021-03-20 9:10 ` Leon Romanovsky
2021-03-20 14:59 ` Alex Williamson
2021-03-21 8:40 ` Leon Romanovsky
2021-03-21 14:57 ` Amey Narkhede
2021-03-22 17:10 ` Alex Williamson
2021-03-24 10:03 ` Leon Romanovsky
2021-03-24 14:37 ` Alex Williamson
2021-03-24 15:13 ` Leon Romanovsky
2021-03-24 17:17 ` Alex Williamson
2021-03-25 8:37 ` Leon Romanovsky
2021-03-25 14:55 ` Alex Williamson
2021-03-25 16:09 ` Leon Romanovsky
2021-03-25 17:22 ` Amey Narkhede
2021-03-25 17:36 ` Leon Romanovsky
2021-03-25 17:53 ` Alex Williamson
2021-03-26 6:40 ` Leon Romanovsky
2021-03-26 9:18 ` Krzysztof Wilczyński
2021-03-26 12:54 ` Leon Romanovsky
2021-03-26 14:20 ` Alex Williamson
2021-03-27 6:02 ` Leon Romanovsky
2021-03-25 16:26 ` Amey Narkhede
2021-03-25 16:46 ` Leon Romanovsky
2021-03-18 17:51 ` Enrico Weigelt, metux IT consult
[not found] ` <20210312112043.3f2954e3@omen.home.shazbot.org>
2021-03-12 18:40 ` [PATCH 0/4] Expose and manage PCI device reset Amey Narkhede
2021-03-12 18:58 ` Krzysztof Wilczyński
2021-03-12 19:06 ` Amey Narkhede
2021-03-12 19:20 ` Krzysztof Wilczyński
2021-03-13 2:02 ` Raphael Norwitz [this message]
2021-03-14 12:09 ` Leon Romanovsky
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=20210313020221.GA14334@raphael-debian-dev \
--to=raphael.norwitz@nutanix.com \
--cc=alex.williamson@redhat.com \
--cc=ameynarkhede03@gmail.com \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
/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.