From: Keith Busch <keith.busch@intel.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Linux PCI <linux-pci@vger.kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Sinan Kaya <okaya@kernel.org>, Thomas Tai <thomas.tai@oracle.com>,
poza@codeaurora.org, Lukas Wunner <lukas@wunner.de>,
Christoph Hellwig <hch@lst.de>,
Mika Westerberg <mika.westerberg@linux.intel.com>
Subject: Re: [PATCHv4 08/12] PCI: ERR: Always use the first downstream port
Date: Tue, 2 Oct 2018 13:55:00 -0600 [thread overview]
Message-ID: <20181002195459.GA17539@localhost.localdomain> (raw)
In-Reply-To: <20181002193522.GB120535@bhelgaas-glaptop.roam.corp.google.com>
On Tue, Oct 02, 2018 at 02:35:22PM -0500, Bjorn Helgaas wrote:
> Here's my proposal for the changelog. Let me know what I screwed up.
>
> commit 1f7d2967334433d885c0712b8ac3f073f20211ee
> Author: Keith Busch <keith.busch@intel.com>
> Date: Thu Sep 20 10:27:13 2018 -0600
>
> PCI/ERR: Run error recovery callbacks for all affected devices
>
> If an Endpoint reported an error with ERR_FATAL, we previously ran driver
> error recovery callbacks only for the Endpoint's driver. But if we reset a
> Link to recover from the error, all downstream components are affected,
> including the Endpoint, any multi-function peers, and children of those
> peers.
>
> Initiate the Link reset from the deepest Downstream Port that is
> reliable, and call the error recovery callbacks for all its children.
>
> If a Downstream Port (including a Root Port) reports an error, we assume
> the Port itself is reliable and we need to reset its downstream Link. In
> all other cases (Switch Upstream Ports, Endpoints, Bridges, etc), we assume
> the Link leading to the component needs to be reset, so we initiate the
> reset at the parent Downstream Port.
>
> This allows two other clean-ups. First, we currently only use a Link
> reset, which can only be initiated using a Downstream Port, so we can
> remove checks for Endpoints. Second, the Downstream Port where we initiate
> the Link reset is reliable (unlike the device that reported the error), so
> the special cases for error detect and resume are no longer necessary.
A downstream port may have been the device that reports the error, but
we still consider that to be accessible. Maybe "unlike its subordinate
bus".
Otherwise this sounds good to me.
next prev parent reply other threads:[~2018-10-02 19:52 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-20 16:27 [PATCHv4 00/12] pci error handling fixes Keith Busch
2018-09-20 16:27 ` [PATCHv4 01/12] PCI: portdrv: Initialize service drivers directly Keith Busch
2018-09-20 16:27 ` [PATCHv4 02/12] PCI: portdrv: Restore pci state on slot reset Keith Busch
2018-09-20 16:27 ` [PATCHv4 03/12] PCI: DPC: Save and restore control state Keith Busch
2018-09-20 19:46 ` Sinan Kaya
2018-09-20 19:47 ` Sinan Kaya
2018-09-20 19:54 ` Keith Busch
2018-09-20 16:27 ` [PATCHv4 04/12] PCI: AER: Take reference on error devices Keith Busch
2018-09-20 16:27 ` [PATCHv4 05/12] PCI: AER: Don't read upstream ports below fatal errors Keith Busch
2018-09-20 16:27 ` [PATCHv4 06/12] PCI: ERR: Use slot reset if available Keith Busch
2018-09-20 16:27 ` [PATCHv4 07/12] PCI: ERR: Handle fatal error recovery Keith Busch
2018-09-20 16:27 ` [PATCHv4 08/12] PCI: ERR: Always use the first downstream port Keith Busch
2018-09-26 22:01 ` Bjorn Helgaas
2018-09-26 22:19 ` Keith Busch
2018-09-27 22:56 ` Bjorn Helgaas
2018-09-28 15:42 ` Keith Busch
2018-09-28 20:50 ` Bjorn Helgaas
2018-09-28 21:35 ` Keith Busch
2018-09-28 23:28 ` Bjorn Helgaas
2018-10-01 15:14 ` Keith Busch
2018-10-02 19:35 ` Bjorn Helgaas
2018-10-02 19:55 ` Keith Busch [this message]
2018-09-20 16:27 ` [PATCHv4 09/12] PCI: ERR: Simplify broadcast callouts Keith Busch
2018-09-20 16:27 ` [PATCHv4 10/12] PCI: ERR: Report current recovery status for udev Keith Busch
2018-09-20 16:27 ` [PATCHv4 11/12] PCI: Unify device inaccessible Keith Busch
2018-09-20 16:27 ` [PATCHv4 12/12] PCI: Make link active reporting detection generic Keith Busch
2018-09-20 20:00 ` [PATCHv4 00/12] pci error handling fixes Sinan Kaya
2018-09-20 21:17 ` Bjorn Helgaas
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=20181002195459.GA17539@localhost.localdomain \
--to=keith.busch@intel.com \
--cc=benh@kernel.crashing.org \
--cc=bhelgaas@google.com \
--cc=hch@lst.de \
--cc=helgaas@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mika.westerberg@linux.intel.com \
--cc=okaya@kernel.org \
--cc=poza@codeaurora.org \
--cc=thomas.tai@oracle.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.