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

[Ahmed Tiba <ahmed.tiba@arm.com>]

On 14/01/2026 14:15, Borislav Petkov wrote:
> 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"?

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.

>> 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.

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