LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew W Carlis <mattc@purestorage.com>
To: lukas@wunner.de
Cc: agovindjee@purestorage.com, an.luo@enflame-tech.com,
	ashishk@purestorage.com, bill.wu@enflame-tech.com,
	dio.sun@enflame-tech.com, fernando.hu@enflame-tech.com,
	helgaas@kernel.org, jrangi@purestorage.com,
	linux-pci@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	mahesh@linux.ibm.com, mattc@purestorage.com,
	msaggi@purestorage.com, oohall@gmail.com,
	qingshun.wang@linux.intel.com, rhan@purestorage.com,
	sathyanarayanan.kuppuswamy@linux.intel.com,
	sconnor@purestorage.com, terry.bowman@amd.com,
	xin.wang@enflame-tech.com, yang.yicong@picoheart.com,
	yurypm@arista.com, zhenzhong.duan@intel.com
Subject: [PATCH 0/6] PCI/AER: Support Advisory Non-Fatal Errors
Date: Sat,  1 Aug 2026 02:24:18 -0600	[thread overview]
Message-ID: <20260801082419.7780-1-mattc@purestorage.com> (raw)
In-Reply-To: <amztrrIGvz8gPxQb@wunner.de>

There is a part of me that wonders whether all of the complexity in AER
handling is really worth it...

Advisory error is one of those insane things in the spec.. It feels like
the spec makes it unreasonably complicated for the driver to discriminate.
What if we decoupled the message received by the root port from checking &
logging the AER status registers? In other words, when the root port
receives a message we log the severity we received and whether it was
multiple errors.

Then, when we get to the device that sent the message we just always check the
CE and the UE status registers? If any status is set that is also unmasked then
we log the corresponding TLP Header for that. In addition we log the device
status register so users can know what severities were signaled.

We can use the Error Message severity received at the root port to decide
whether to walk the pci bus and do the error_detected() stuff. If there are
multiple UE status bits set at the reporter & Dev Status register says there
was a Non Fatal Error as well a Correctable Error I don't think I care if
simply logs everything in UE status as a UE, everything in CE status as CE
as long as it also tells me the Dev Status Bits that are set.

Going a little further I would be fine with just always checking both CE/UE
status because it seems like it simplifies things a lot & two/three extra
config reads/writes is almost a nop if you're already at the device probing
it for the other AER things.

Thank you!


  reply	other threads:[~2026-08-01 12:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-24 15:24 [PATCH 0/6] PCI/AER: Support Advisory Non-Fatal Errors Lukas Wunner
2026-07-24 15:24 ` [PATCH 1/6] PCI/AER: Fix mapping of errors to agent & layer Lukas Wunner
2026-07-24 15:24 ` [PATCH 2/6] PCI/AER: Log agent & layer for each individual error Lukas Wunner
2026-07-24 15:24 ` [PATCH 3/6] PCI/AER: Deduplicate logging of Error Source Identification Lukas Wunner
2026-07-24 15:24 ` [PATCH 4/6] PCI/AER: Emit TLP Log only for unmasked errors Lukas Wunner
2026-07-24 15:24 ` [PATCH 5/6] PCI/AER: Move retrieval of FEP and TLP Log into helper Lukas Wunner
2026-07-24 15:24 ` [PATCH 6/6] PCI/AER: Support Advisory Non-Fatal Errors Lukas Wunner
2026-07-24 22:39 ` [PATCH 0/6] " Bjorn Helgaas
2026-07-27 14:12   ` Lukas Wunner
2026-07-27 15:51     ` Bjorn Helgaas
2026-07-31 18:47     ` Lukas Wunner
2026-08-01  8:24       ` Matthew W Carlis [this message]
2026-08-01  9:08         ` Lukas Wunner

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=20260801082419.7780-1-mattc@purestorage.com \
    --to=mattc@purestorage.com \
    --cc=agovindjee@purestorage.com \
    --cc=an.luo@enflame-tech.com \
    --cc=ashishk@purestorage.com \
    --cc=bill.wu@enflame-tech.com \
    --cc=dio.sun@enflame-tech.com \
    --cc=fernando.hu@enflame-tech.com \
    --cc=helgaas@kernel.org \
    --cc=jrangi@purestorage.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lukas@wunner.de \
    --cc=mahesh@linux.ibm.com \
    --cc=msaggi@purestorage.com \
    --cc=oohall@gmail.com \
    --cc=qingshun.wang@linux.intel.com \
    --cc=rhan@purestorage.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=sconnor@purestorage.com \
    --cc=terry.bowman@amd.com \
    --cc=xin.wang@enflame-tech.com \
    --cc=yang.yicong@picoheart.com \
    --cc=yurypm@arista.com \
    --cc=zhenzhong.duan@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox