LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: email@example.com To: Bjorn Helgaas <firstname.lastname@example.org> Cc: Bjorn Helgaas <email@example.com>, Philippe Ombredanne <firstname.lastname@example.org>, Thomas Gleixner <email@example.com>, Greg Kroah-Hartman <firstname.lastname@example.org>, Kate Stewart <email@example.com>, firstname.lastname@example.org, email@example.com, Dongdong Liu <firstname.lastname@example.org>, Keith Busch <email@example.com>, Wei Zhang <firstname.lastname@example.org>, Sinan Kaya <email@example.com>, Timur Tabi <firstname.lastname@example.org> Subject: Re: [PATCH v12 0/6] Address error and recovery for AER and DPC Date: Mon, 12 Mar 2018 19:31:08 +0530 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <20180311220337.GA194000@bhelgaas-glaptop.roam.corp.google.com> On 2018-03-12 03:33, Bjorn Helgaas wrote: > On Wed, Feb 28, 2018 at 10:34:11PM +0530, 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. >> >> DPC should enumerate the devices after recovering the link, which is >> achieved by implementing error_resume callback. > > The main point of this series is to call the driver error handling > callbacks (error_detected(), mmio_enabled(), slot_reset(), etc.) when > DPC events occur. We've always called them for AER events, but prior > to this series, we didn't call them for DPC events. > > That's a good thing -- we should treat DPC events as much like AER > events as possible. > > This series does make it more obvious that there's still a big > difference between AER and DPC handling -- for DPC, we remove and > re-enumerate all the devices, but we don't for AER. > > That difference has been there since the beginning of DPC, so it has > nothing to do with *this* series EXCEPT for the fact that it really > complicates the logic you're adding to reset_link() and > broadcast_error_message(). > > We ought to be able to simplify that somehow because the only real > difference between AER and DPC should be that DPC automatically > disables the link and AER does it in software. > > Bjorn Ok, so here is slight modification which I will do and will post final looking patches. 1) do not enumerate the devices after link is up (since AER does not do it) 2) remove the call to pci_stop_and_remove_bus_device(dev); because now DPC also makes use of driver's callback. (like AER does) above 2 changes should make behavior of DPC identical to AER. Regards, Oza.
prev parent reply other threads:[~2018-03-12 14:01 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-02-28 17:04 [PATCH v12 0/6] Address error and recovery for AER and DPC Oza Pawandeep 2018-02-28 17:04 ` [PATCH v12 1/6] PCI/AER: Rename error recovery to generic PCI naming Oza Pawandeep 2018-02-28 17:04 ` [PATCH v12 2/6] PCI/AER: Factor out error reporting from AER Oza Pawandeep 2018-02-28 17:04 ` [PATCH v12 3/6] PCI/PORTDRV: Implement generic find service Oza Pawandeep 2018-03-06 14:02 ` Sinan Kaya 2018-03-08 7:56 ` poza 2018-02-28 17:04 ` [PATCH v12 4/6] PCI/DPC: Unify and plumb error handling into DPC Oza Pawandeep 2018-02-28 17:04 ` [PATCH v12 5/6] PCI: Unify wait for link active into generic PCI Oza Pawandeep 2018-02-28 17:04 ` [PATCH v12 6/6] PCI/DPC: Enumerate the devices after DPC trigger event Oza Pawandeep 2018-03-11 22:03 ` [PATCH v12 0/6] Address error and recovery for AER and DPC Bjorn Helgaas 2018-03-12 3:03 ` Sinan Kaya 2018-03-12 14:25 ` Keith Busch 2018-03-12 14:46 ` poza 2018-03-12 14:58 ` Keith Busch 2018-03-12 15:34 ` poza 2018-03-12 17:33 ` Keith Busch 2018-03-12 17:41 ` Sinan Kaya 2018-03-12 17:56 ` Keith Busch 2018-03-12 19:47 ` Bjorn Helgaas 2018-03-12 23:26 ` Keith Busch 2018-03-13 3:47 ` Sinan Kaya 2018-03-14 20:50 ` Keith Busch 2018-03-14 21:00 ` Sinan Kaya 2018-05-08 19:25 ` Bjorn Helgaas 2018-03-12 14:01 ` poza [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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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: linkBe 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).