From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
To: Lukas Wunner <lukas@wunner.de>,
Bjorn Helgaas <helgaas@kernel.org>,
Raag Jadav <raag.jadav@intel.com>,
Riana Tauro <riana.tauro@intel.com>,
Yury Murashka <yurypm@arista.com>,
Matthew W Carlis <mattc@purestorage.com>,
linux-pci@vger.kernel.org
Cc: Mahesh J Salgaonkar <mahesh@linux.ibm.com>,
Oliver OHalloran <oohall@gmail.com>,
linuxppc-dev@lists.ozlabs.org,
Aravind Iddamsetty <aravind.iddamsetty@intel.com>,
Srinivasa Adatrao <srinivasa.adatrao@intel.com>,
Terry Bowman <terry.bowman@amd.com>,
Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCH 5/7] PCI/AER: Move AER capability check out of pcie_aer_is_native()
Date: Tue, 29 Sep 2026 12:47:26 -0700 [thread overview]
Message-ID: <7d21f908-ea38-4b8c-9646-0aaaa520206a@linux.intel.com> (raw)
In-Reply-To: <6a21637111397810d75679d1ca597766f3bf5605.1790531238.git.lukas@wunner.de>
On 9/27/2026 11:02 AM, Lukas Wunner wrote:
> When firmware grants control of Advanced Error Reporting to the operating
> system, that not only encompasses the AER capability, but also error
> enable/status bits in the Device Control and Device Status registers
> (PCI Firmware r3.3 table 4-6 bit 3).
>
> PCIe devices without AER capability still support baseline capability
> error reporting through these enable/status bits (PCIe r7.1 sec 6.2.1),
> but the bits must not be modified unless AER control was granted.
>
> pcie_aer_is_native() is unsuitable to check for control of AER-incapable
> devices because it implicitly checks for presence of an AER capability.
>
> Move that check to its callers (where needed) to allow using the function
> for the imminent baseline capability error reporting.
Agreed that ownership and AER presence are separate questions, but
changing the semantics while keeping the name may trip up callers that
assume "native" implies "present". Would a separate ownership-only
helper (e.g. pcie_err_is_native()) be cleaner? It could also replace
cxl_error_is_native().
I think you also need to fix kernel-doc of pci_aer_unmask_internal_errors().
it says to check AER support with pcie_aer_is_native(). That's no longer
sufficient, and the function has no aer_cap check, Please update the comment
and ideally add an "if (!aer) return;".
>
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> ---
> drivers/pci/pcie/aer.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index d8dcd238fda1..34a8eddc427a 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -257,9 +257,6 @@ int pcie_aer_is_native(struct pci_dev *dev)
> {
> struct pci_host_bridge *host = pci_find_host_bridge(dev->bus);
>
> - if (!dev->aer_cap)
> - return 0;
> -
> return pcie_ports_native || host->native_aer;
> }
> EXPORT_SYMBOL_NS_GPL(pcie_aer_is_native, "CXL");
> @@ -280,7 +277,7 @@ int pci_aer_clear_nonfatal_status(struct pci_dev *dev)
> int aer = dev->aer_cap;
> u32 status, sev;
>
> - if (!pcie_aer_is_native(dev))
> + if (!aer || !pcie_aer_is_native(dev))
> return -EIO;
>
> /* Clear status bits for ERR_NONFATAL errors only */
> @@ -299,7 +296,7 @@ void pci_aer_clear_fatal_status(struct pci_dev *dev)
> int aer = dev->aer_cap;
> u32 status, sev;
>
> - if (!pcie_aer_is_native(dev))
> + if (!aer || !pcie_aer_is_native(dev))
> return;
>
> /* Clear status bits for ERR_FATAL errors only */
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
next prev parent reply other threads:[~2026-09-29 19:47 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-27 18:02 [PATCH 0/7] Error reporting for AER-incapable devices Lukas Wunner
2026-09-27 18:02 ` [PATCH 1/7] PCI/DPC: Avoid access to non-existent AER capability Lukas Wunner
2026-09-27 18:27 ` sashiko-bot
2026-09-29 18:49 ` Kuppuswamy Sathyanarayanan
2026-09-27 18:02 ` [PATCH 2/7] PCI/DPC: Reinstate support for AER-incapable ports Lukas Wunner
2026-09-27 18:26 ` sashiko-bot
2026-09-29 19:04 ` Kuppuswamy Sathyanarayanan
2026-09-27 18:02 ` [PATCH 3/7] PCI/ERR: Avoid stale error status bits on recovery failure Lukas Wunner
2026-09-27 18:31 ` sashiko-bot
2026-09-27 18:57 ` Lukas Wunner
2026-09-29 19:20 ` Kuppuswamy Sathyanarayanan
2026-09-27 18:02 ` [PATCH 4/7] PCI/AER: Drop AER native check from handles_cxl_errors() Lukas Wunner
2026-09-27 18:26 ` sashiko-bot
2026-09-28 20:58 ` Bowman, Terry
2026-09-29 19:24 ` Kuppuswamy Sathyanarayanan
2026-09-27 18:02 ` [PATCH 5/7] PCI/AER: Move AER capability check out of pcie_aer_is_native() Lukas Wunner
2026-09-27 18:30 ` sashiko-bot
2026-09-29 19:47 ` Kuppuswamy Sathyanarayanan [this message]
2026-09-27 18:02 ` [PATCH 6/7] PCI/AER: Renumber severity constants Lukas Wunner
2026-09-27 18:29 ` sashiko-bot
2026-09-27 19:23 ` Lukas Wunner
2026-09-29 19:55 ` Kuppuswamy Sathyanarayanan
2026-09-27 18:02 ` [PATCH 7/7] PCI/AER: Enable baseline capability error reporting Lukas Wunner
2026-09-27 18:33 ` sashiko-bot
2026-09-29 21:01 ` Kuppuswamy Sathyanarayanan
2026-09-30 7:08 ` Lukas Wunner
2026-10-01 17:44 ` Kuppuswamy Sathyanarayanan
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=7d21f908-ea38-4b8c-9646-0aaaa520206a@linux.intel.com \
--to=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=aravind.iddamsetty@intel.com \
--cc=helgaas@kernel.org \
--cc=kbusch@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lukas@wunner.de \
--cc=mahesh@linux.ibm.com \
--cc=mattc@purestorage.com \
--cc=oohall@gmail.com \
--cc=raag.jadav@intel.com \
--cc=riana.tauro@intel.com \
--cc=srinivasa.adatrao@intel.com \
--cc=terry.bowman@amd.com \
--cc=yurypm@arista.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