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

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"?

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.

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?

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.

Later, when there's need to make it more sophisticated, then we can talk
again.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette