[PATCH 03/12] ras: add estatus vendor handling and processing

[Ahmed Tiba]

On Fri, Dec 19, 2025 at 04:30:40PM +0100, Mauro Carvalho Chehab wrote:
>On Fri, Dec 19, 2025 at 02:49:02PM +0000, Ahmed Tiba wrote:
>>
>> On Wed, Dec 18, 2025 at 05:04:53PM +0100, Mauro Carvalho Chehab wrote:
>>
>> >> Teach the estatus core how to walk CPER records and expose the vendor
>> >> record notification path. This adds the section iteration helpers,
>> >> the logging helpers that mirror the GHES behaviour, and the deferred
>> >> work used to hand vendor GUIDs to interested drivers. No users switch
>> >> over yet; this simply moves the common logic out of GHES so the next
>> >> patches can wire it up.
>> >>
>> >> Signed-off-by: Ahmed Tiba <ahmed.tiba at arm.com>
>> >
>> >...
>> >
>> >> +static bool estatus_handle_arm_hw_error(estatus_generic_data *gdata, int sev, bool sync)
>> >
>> > Huh?
>> >
>> > This is a CPER record from GHES. Why are you moving CPER code out
>> > of ghes.c, placing in a file named estatus.c? Doesn't make much
>> > sense on my eyes...
>> >
>> > Same applies to to other GHES CPER record types.
>>
>> GHES still fills in the CPER record, but the parsing and logging logic is
>> shared with the new DeviceTree provider so I pulled those helpers into the
>> estatus core.
>
> I see, but this is not really estatus core. Instead, it is part of GHES CPER
> handling logic, which is defined at ACPI and UEFI specs. moving it to estatus
> sounds odd, at least on my eyes.
> 
> Perhaps I'm failing to see where at ACPI/UEFI specs how CPER would be
> integrated with an OpenFirmware approach to handle CPER without GHES.
> Care to point to the relevant specs, if any?

ACPI/APEI (via GHES) defines how CPER records are discovered and notified on ACPI systems,
but there is no ACPI or UEFI-defined equivalent for OpenFirmware/DeviceTree platforms.
UEFI standardises the CPER record format itself, not the transport or discovery mechanism.

On non-ACPI systems we still receive the same UEFI-defined CPER payload
from firmware, but Linux needs a different, platform-specific contract
to locate and acknowledge it. The DT binding is a Linux-side description
of that contract rather than something defined by ACPI/UEFI.

>> Both providers already call into the same notifier chain and
>> memory-pool helpers; this patch just moves the generic CPER walking routines
>> next to the rest of the common code so the DT path doesn’t have to grow its
>> own copy. If you’d prefer a different file layout or naming to make that
>> intent clearer, I’m happy to adjust.

> Moving the code from ghes.c to estatus.c or to elsewhere shouldn't make any
> difference, as the DT handling logic could simply be calling the functions
> from ghes.c (or estatus.c). I fail to see why they need to be moved.

The motivation is to provide a shared implementation for non-ACPI providers,
so that the DT path does not depend on ACPI/APEI.

While the helpers currently live in ghes.c, they are CPER-specific and do not rely on ACPI tables,
APEI infrastructure, or GHES notification semantics. Keeping them there effectively makes GHES
the only place those helpers can live, even though the logic itself is provider-agnostic.

By moving the CPER parsing and logging pieces into a common location,
both GHES and the DT provider can reuse the same implementation,
while the ACPI-specific discovery and notification code remains under drivers/acpi/apei/.
This avoids having the DT provider reach into GHES internals or duplicate CPER handling code.

If the current naming or file layout makes that separation unclear, I’m happy to adjust it.

Thanks,
Ahmed