All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Sean V Kelley <seanvk.dev@oregontracks.org>
Cc: <bhelgaas@google.com>, <rafael.j.wysocki@intel.com>,
	<ashok.raj@intel.com>, <tony.luck@intel.com>,
	<sathyanarayanan.kuppuswamy@intel.com>, <qiuxu.zhuo@intel.com>,
	<linux-pci@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	Sean V Kelley <sean.v.kelley@intel.com>
Subject: Re: [PATCH v7 06/13] PCI/ERR: Limit AER resets in pcie_do_recovery()
Date: Thu, 1 Oct 2020 11:00:52 +0100	[thread overview]
Message-ID: <20201001100052.00004f86@Huawei.com> (raw)
In-Reply-To: <20200930215820.1113353-7-seanvk.dev@oregontracks.org>

On Wed, 30 Sep 2020 14:58:13 -0700
Sean V Kelley <seanvk.dev@oregontracks.org> wrote:

> From: Sean V Kelley <sean.v.kelley@intel.com>
> 
> In some cases a bridge may not exist as the hardware
> controlling may be handled only by firmware and so is
> not visible to the OS. This scenario is also possible
> in future use cases involving non-native use of RCECs
> by firmware. So explicitly apply conditional logic
> around these resets by limiting them to root ports and
> downstream ports.
> 
> Signed-off-by: Sean V Kelley <sean.v.kelley@intel.com>

Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

> ---
>  drivers/pci/pcie/err.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
> index c6922c099c76..9e552330155b 100644
> --- a/drivers/pci/pcie/err.c
> +++ b/drivers/pci/pcie/err.c
> @@ -203,9 +203,12 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
>  	pci_dbg(dev, "broadcast resume message\n");
>  	pci_walk_bus(bus, report_resume, &status);
>  
> -	if (pcie_aer_is_native(dev))
> -		pcie_clear_device_status(dev);
> -	pci_aer_clear_nonfatal_status(dev);
> +	if (type == PCI_EXP_TYPE_ROOT_PORT ||
> +	    type == PCI_EXP_TYPE_DOWNSTREAM) {
> +		if (pcie_aer_is_native(bridge))
> +			pcie_clear_device_status(bridge);
> +		pci_aer_clear_nonfatal_status(bridge);
> +	}
>  	pci_info(dev, "device recovery successful\n");
>  	return status;
>  



  reply	other threads:[~2020-10-01 10:02 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-30 21:58 [PATCH v7 00/13] Add RCEC handling to PCI/AER Sean V Kelley
2020-09-30 21:58 ` [PATCH v7 01/13] PCI/RCEC: Add RCEC class code and extended capability Sean V Kelley
2020-09-30 21:58 ` [PATCH v7 02/13] PCI/RCEC: Bind RCEC devices to the Root Port driver Sean V Kelley
2020-09-30 21:58 ` [PATCH v7 03/13] PCI/RCEC: Cache RCEC capabilities in pci_init_capabilities() Sean V Kelley
2020-09-30 22:15   ` Sean V Kelley
2020-10-01  9:02   ` Jonathan Cameron
2020-09-30 21:58 ` [PATCH v7 04/13] PCI/ERR: Rename reset_link() to reset_subordinate_device() Sean V Kelley
2020-10-01  9:03   ` Jonathan Cameron
2020-09-30 21:58 ` [PATCH v7 05/13] PCI/ERR: Use "bridge" for clarity in pcie_do_recovery() Sean V Kelley
2020-10-01  9:06   ` Jonathan Cameron
2020-10-01 21:04     ` Sean V Kelley
2020-09-30 21:58 ` [PATCH v7 06/13] PCI/ERR: Limit AER resets " Sean V Kelley
2020-10-01 10:00   ` Jonathan Cameron [this message]
2020-09-30 21:58 ` [PATCH v7 07/13] PCI/AER: Extend AER error handling to RCECs Sean V Kelley
2020-10-01 23:14   ` Bjorn Helgaas
2020-10-02  4:15     ` Sean V Kelley
2020-09-30 21:58 ` [PATCH v7 08/13] PCI/AER: Apply function level reset to RCiEP on fatal error Sean V Kelley
2020-09-30 21:58 ` [PATCH v7 09/13] PCI/RCEC: Add pcie_link_rcec() to associate RCiEPs Sean V Kelley
2020-09-30 21:58 ` [PATCH v7 10/13] PCI/RCEC: Add RCiEP's linked RCEC to AER/ERR Sean V Kelley
2020-09-30 21:58 ` [PATCH v7 11/13] PCI/AER: Add pcie_walk_rcec() to RCEC AER handling Sean V Kelley
2020-09-30 21:58 ` [PATCH v7 12/13] PCI/PME: Add pcie_walk_rcec() to RCEC PME handling Sean V Kelley
2020-09-30 21:58 ` [PATCH v7 13/13] PCI/AER: Add RCEC AER error injection support Sean V Kelley
2020-10-01 10:16 ` [PATCH v7 00/13] Add RCEC handling to PCI/AER Jonathan Cameron
2020-10-01 21:01   ` Sean V Kelley

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=20201001100052.00004f86@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=ashok.raj@intel.com \
    --cc=bhelgaas@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=qiuxu.zhuo@intel.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=sathyanarayanan.kuppuswamy@intel.com \
    --cc=sean.v.kelley@intel.com \
    --cc=seanvk.dev@oregontracks.org \
    --cc=tony.luck@intel.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.