From: Bjorn Helgaas <helgaas@kernel.org>
To: poza@codeaurora.org
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Philippe Ombredanne <pombredanne@nexb.com>,
Thomas Gleixner <tglx@linutronix.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Kate Stewart <kstewart@linuxfoundation.org>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
Dongdong Liu <liudongdong3@huawei.com>,
Keith Busch <keith.busch@intel.com>, Wei Zhang <wzhang@fb.com>,
Sinan Kaya <okaya@codeaurora.org>,
Timur Tabi <timur@codeaurora.org>
Subject: Re: [PATCH v14 0/9] Address error and recovery for AER and DPC
Date: Mon, 30 Apr 2018 17:40:02 -0500 [thread overview]
Message-ID: <20180430224002.GI95643@bhelgaas-glaptop.roam.corp.google.com> (raw)
In-Reply-To: <f97676e307fe7a02f1f2059a140a5e32@codeaurora.org>
On Thu, Apr 26, 2018 at 11:00:52AM +0530, poza@codeaurora.org wrote:
> On 2018-04-23 20:53, Oza Pawandeep wrote:
> > This patch set brings in error handling support for DPC
> >
> > The current implementation of AER and error message broadcasting to the
> > EP driver is tightly coupled and limited to AER service driver.
> > It is important to factor out broadcasting and other link handling
> > callbacks. So that not only when AER gets triggered, but also when DPC
> > get
> > triggered (for e.g. ERR_FATAL), callbacks are handled appropriately.
> >
> > The goal of the patch-set is:
> > DPC should handle the error handling and recovery similar to AER,
> > because
> > finally both are attempting recovery in some or the other way,
> > and for that error handling and recovery framework has to be loosely
> > coupled.
> > ...
> Hi Bjorn,
>
> I know I need to rebase this whole patch-set to 4.17 now.
>
> But before I do that, can you please help to comment.
My overall comment is that I think the series will be simpler and read
better if you first change AER to do remove/re-enumerate, before doing
anything with DPC.
This could be done by extracting just the AER part of "PCI/AER/DPC:
Align FATAL error handling for AER and DPC" (i.e., adding
pcie_do_fatal_recovery()) and moving that to be the very first patch.
It's a small change in terms of code size, but significant to drivers,
and it's really the core of the series, so it would be good to clearly
establish the policy of:
ERR_NONFATAL => call driver recovery entry points
ERR_FATAL => remove and re-enumerate
before bringing DPC into the picture.
Then the subsequent patches would all be more or less mechanical
changes to make DPC follow the same model.
Bjorn
next prev parent reply other threads:[~2018-04-30 22:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-23 15:23 Oza Pawandeep
2018-04-23 15:23 ` [PATCH v14 1/9] PCI/AER: Rename error recovery to generic PCI naming Oza Pawandeep
2018-04-23 15:23 ` [PATCH v14 2/9] PCI/AER: Factor out error reporting from AER Oza Pawandeep
2018-04-23 15:23 ` [PATCH v14 3/9] PCI/PORTDRV: Implement generic find service Oza Pawandeep
2018-04-23 15:23 ` [PATCH v14 4/9] PCI/PORTDRV: Implement generic find device Oza Pawandeep
2018-04-23 15:23 ` [PATCH v14 5/9] PCI/DPC: Unify and plumb error handling into DPC Oza Pawandeep
2018-04-23 15:23 ` [PATCH v14 6/9] PCI: Unify wait for link active into generic PCI Oza Pawandeep
2018-04-23 15:23 ` [PATCH v14 7/9] PCI/DPC: Disable ERR_NONFATAL and enable ERR_FATAL for DPC Oza Pawandeep
2018-04-23 15:23 ` [PATCH v14 8/9] PCI/AER/DPC: Align FATAL error handling for AER and DPC Oza Pawandeep
2018-04-24 4:47 ` kbuild test robot
2018-04-24 4:47 ` [RFC PATCH] PCI/AER/DPC: pcie_do_fatal_recovery() can be static kbuild test robot
2018-04-23 15:23 ` [PATCH v14 9/9] pci-error-recovery: Add AER_FATAL handling Oza Pawandeep
2018-04-26 5:30 ` [PATCH v14 0/9] Address error and recovery for AER and DPC poza
2018-04-30 22:40 ` Bjorn Helgaas [this message]
2018-05-01 10:00 ` poza
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=20180430224002.GI95643@bhelgaas-glaptop.roam.corp.google.com \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=keith.busch@intel.com \
--cc=kstewart@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=liudongdong3@huawei.com \
--cc=okaya@codeaurora.org \
--cc=pombredanne@nexb.com \
--cc=poza@codeaurora.org \
--cc=tglx@linutronix.de \
--cc=timur@codeaurora.org \
--cc=wzhang@fb.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
all inboxes | Powered by JetHome®