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

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

On Sun, Dec 21, 2025 at 02:35:34 +0100, Borislav Petkov wrote:
> On Wed, Dec 17, 2025 at 11:28:33AM +0000, Ahmed Tiba wrote:
>> Platforms that rely on firmware-first RAS today only get the full Linux
>> handling pipeline when the records arrive through ACPI/APEI GHES. This
>> series lifts the generic parts of GHES into a reusable estatus core, wires
>
> Why is this thing called "error status"?

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

> Why is error status so significant so that you need to call it a thing,
> much less a "core"?

The reason this shows up as a separate “core” is that CPER parsing,
logging, and vendor dispatch are provider-agnostic once a Generic Error
Status block exists, independent of how it was discovered or notified.

> It looks like you basically want to dump error records from a system
> which doesn't support GHES into the common path so they get decoded?
>
> I mean, I'm only guessing because I don't get any wiser from this text.
>
> So how about you give the high-level, practical use spiel first? What's
> the use case?

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.

GHES remains one transport for delivering CPER records, but this
series separates the transport from the decoding so that other firmware-
first providers can reuse the same handling without duplicating code or
depending on ACPI/APEI internals.

As far as I can tell from the scope of https://uefi.org/specifications,
the UEFI specifications don’t define a notification mechanism for
DeviceTree systems—only the ACPI/APEI path is spelled out. Right now the DT
transport is described solely by the binding in patch 9/12. If there’s a
better place to document or name this, I’d appreciate guidance
so it’s clear how firmware-first notification happens on DT outside ACPI.

Thanks,
Ahmed