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

[Mauro Carvalho Chehab]

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?

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

-- 
Thanks,
Mauro