Em Fri, 19 Dec 2025 18:11:54 +0000
Ahmed Tiba [off-list ref] escreveu:

On Fri, Dec 19, 2025 at 04:30:40PM +0100, Mauro Carvalho Chehab wrote:

quoted

On Fri, Dec 19, 2025 at 02:49:02PM +0000, Ahmed Tiba wrote:  

quoted

On Wed, Dec 18, 2025 at 05:04:53PM +0100, Mauro Carvalho Chehab wrote:
 

quoted

quoted

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

...
 

quoted

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

That's where I'm failing to understand: CPER is part of UEFI spec, and
the only deliverable mechanism I'm aware of for CPER is via GHES or
GHESv2 - e.g. via ACPI.

Within the scope of https://uefi.org/specifications, I'm failing
to see any other deliverable mechanism.
 

quoted

quoted

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.  

quoted

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.

The logic is related to GHES, as this seems to be the only standardized
mechanism to report CPER records. As it is part of APEI, get_maintainers
points to the people that have been maintaining it as:

	$ ./scripts/get_maintainer.pl -f ./drivers/acpi/apei/ghes.c
	"Rafael J. Wysocki" [off-list ref] (maintainer:ACPI APEI,commit_signer:6/13=46%)
	Tony Luck [off-list ref] (reviewer:ACPI APEI,commit_signer:3/13=23%)
	Borislav Petkov [off-list ref] (reviewer:ACPI APEI,removed_lines:5/62=8%)
	Hanjun Guo [off-list ref] (reviewer:ACPI APEI,commit_signer:4/13=31%)
	Mauro Carvalho Chehab [off-list ref] (reviewer:ACPI APEI,authored:1/13=8%,removed_lines:6/62=10%)
	Shuai Xue [off-list ref] (reviewer:ACPI APEI,commit_signer:5/13=38%,authored:2/13=15%,added_lines:56/218=26%,removed_lines:34/62=55%)
	Len Brown [off-list ref] (reviewer:ACPI)
	Jonathan Cameron [off-list ref] (commit_signer:5/13=38%)
	Breno Leitao [off-list ref] (authored:2/13=15%,added_lines:38/218=17%)
	Smita Koralahalli [off-list ref] (authored:2/13=15%,added_lines:103/218=47%)
	Ankit Agrawal [off-list ref] (authored:1/13=8%,removed_lines:6/62=10%)
	Jason Tian [off-list ref] (removed_lines:7/62=11%)
	linux-acpi@vger.kernel.org (open list:ACPI APEI)
	linux-kernel@vger.kernel.org (open list)

Moving it elsewhere would make it confusing, as the expected deliverable
mechanism for CPER is via GHES - as this is the only one defined at the
uefi.org specs.

While it might be moved to EFI and placed under cper.c, 
get_maintainers.pl would point to:

	$ ./scripts/get_maintainer.pl -f ./drivers/firmware/efi/cper.c
	Ard Biesheuvel [off-list ref] (maintainer:EXTENSIBLE FIRMWARE INTERFACE (EFI))
	linux-efi@vger.kernel.org (open list:EXTENSIBLE FIRMWARE INTERFACE (EFI))
	linux-kernel@vger.kernel.org (open list)

which is not the people that have been maintaining RAS.

Placing it under a "estatus.c" file would make it completely
dissociated with UEFI/ACPI specs, as this name means nothing at
the specs.

Also, adding a new maintainer's entry won't make any sense, as the
people that currently reviews and maintains GHES/CPER records
should be kept.

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.

As Boris mentioned on patch 00/12, we need to better understand
the high level scenario, as it is still not clear to me how a
firmware-first notification would happen without ACPI.

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

Thanks,
Mauro