Re: [PATCH 00/12] ras: share firmware-first estatus handling

On 14/01/2026 14:15, Borislav Petkov wrote:

On Mon, Dec 29, 2025 at 11:54:36AM +0000, Ahmed Tiba wrote:

quoted

By “error status” I’m referring to the UEFI CPER Generic Error Status block,
which is the standard firmware-produced error payload that Linux already

Standard, schmandard - a bunch of fw crap.

That's UEFI's understanding of a common platform error record, no?

So why is this a generic estatus and not part of CPER-something?

You're calling something "estatus" which sounds like a generic thing but it is
simply a subset of functionality you need to make it work on ARM without
ACPI and have packaged whatever you need under the name "estatus".

Why does this thing need to be called an "estatus core"?

The CPER records are defined as part of UEFI specs, but its primary way 
to report it is via APEI/GHES.

In drivers/acpi/apei/ghes.c, this subset of CPER handling
is already implemented using a number of helpers mostly named
estatus_* rather than cper_*. The naming therefore originates
from the existing GHES implementation, not from a new abstraction.

What I did was lift that existing estatus_* logic so it can be reused by 
a non-ACPI provider, rather than duplicating the CPER handling
in a parallel DT path.

I'd expect to see a compilation unit which contains shared functionality, gets
linked to your stuff and that's it. No "fanfares", no CONFIG symbols, no
nothing.

That’s a reasonable expectation, and I’m fine aligning with it.The 
approach mirrors drivers/firmware/efi/cper.c, which factors out shared 
functionality for reuse without adding extra fanfare.

quoted

consumes via GHES on ACPI systems. I’m not introducing a new error model
here; the intent is to reuse the existing CPER decoding and handling once
that payload exists.

So why aren't you doing only that? Why are you doing all that extra stuff?

Because the DT-based path still needs a clean way to call into the 
shared logic without dragging in ACPI plumbing.

quoted

The practical use case is firmware-first RAS platforms that emit CPER
records but do not use ACPI/APEI GHES for discovery or notification. Today,
those platforms either have to duplicate CPER parsing logic or miss out on
the common Linux RAS handling (standard logging, memory failure flow,
vendor notification paths). As a result, the full firmware-first RAS
pipeline effectively only works when CPER arrives through GHES.

Yah, got it.

But see above.

Please do not "over-design" this into a separate thing but simply carve out
the functionality and share it. And leave it where it belongs
- drivers/firmware/efi/ is not the right place as this isn't really EFI. This
is a piece of APEI/GHES crap you need.

As it stands, that code is coupled to APEI/GHES and ACPI assumptions. 
Reusing it directly from a DT-based path would implicitly require ACPI, 
which defeats the purpose of supporting firmware-first RAS
on non-ACPI platforms.

Thanks for the discussion.

Regards,
Ahmed