[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240620123104.000029cf@Huawei.com>
Date: Thu, 20 Jun 2024 12:31:04 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Terry Bowman <terry.bowman@....com>
CC: <dan.j.williams@...el.com>, <ira.weiny@...el.com>, <dave@...olabs.net>,
<dave.jiang@...el.com>, <alison.schofield@...el.com>, <ming4.li@...el.com>,
<vishal.l.verma@...el.com>, <jim.harris@...sung.com>,
<ilpo.jarvinen@...ux.intel.com>, <ardb@...nel.org>,
<sathyanarayanan.kuppuswamy@...ux.intel.com>, <linux-cxl@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <Yazen.Ghannam@....com>,
<Robert.Richter@....com>, Bjorn Helgaas <bhelgaas@...gle.com>,
<linux-pci@...r.kernel.org>
Subject: Re: [RFC PATCH 2/9] PCI/AER: Call AER CE handler before clearing
AER CE status register
On Mon, 17 Jun 2024 15:04:04 -0500
Terry Bowman <terry.bowman@....com> wrote:
> The AER service driver clears the AER correctable error (CE) status before
> calling the correctable error handler. This results in the error's status
> not correctly reflected if read from the CE handler.
>
> The AER CE status is needed by the portdrv's CE handler. The portdrv's
> CE handler is intended to only call the registered notifier callbacks
> if the CE error status has correctable internal error (CIE) set.
>
> This is not a problem for AER uncorrrectbale errors (UCE). The UCE status
uncorrectable
> is still present in the AER capability and available for reading, if
> needed, when the UCE handler is called.
I'm seeing the clear in the DPC path for UCE. For other cases is
it a side effect of the reset?
>
> Change the order of clearing the CE status and calling the CE handler.
> Make it to call the CE handler first and then clear the CE status
> after returning.
>
> Signed-off-by: Terry Bowman <terry.bowman@....com>
> Cc: Bjorn Helgaas <bhelgaas@...gle.com>
> Cc: linux-pci@...r.kernel.org
Seems reasonable, but many gremlins around the ordering in these
flows, so I'm to particularly confident. With that in mind.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@...ei.com>
> ---
> drivers/pci/pcie/aer.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index ac6293c24976..4dc03cb9aff0 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -1094,9 +1094,6 @@ static void pci_aer_handle_error(struct pci_dev *dev, struct aer_err_info *info)
> * Correctable error does not need software intervention.
> * No need to go through error recovery process.
> */
> - if (aer)
> - pci_write_config_dword(dev, aer + PCI_ERR_COR_STATUS,
> - info->status);
> if (pcie_aer_is_native(dev)) {
> struct pci_driver *pdrv = dev->driver;
>
> @@ -1105,6 +1102,10 @@ static void pci_aer_handle_error(struct pci_dev *dev, struct aer_err_info *info)
> pdrv->err_handler->cor_error_detected(dev);
> pcie_clear_device_status(dev);
> }
> + if (aer)
> + pci_write_config_dword(dev, aer + PCI_ERR_COR_STATUS,
> + info->status);
> +
> } else if (info->severity == AER_NONFATAL)
> pcie_do_recovery(dev, pci_channel_io_normal, aer_root_reset);
> else if (info->severity == AER_FATAL)
Powered by blists - more mailing lists