Re: [PATCH v5 07/10] ACPI: APEI: introduce GHES helper

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] CONFIG_GHES_CPER_HELPERS is missing critical Kconfig dependencies (ACPI_APEI and GENERIC_ALLOCATOR) required by the code it enables.
- [Low] Compiling an object in a deep subdirectory directly from a top-level Makefile bypasses directory-specific build flags.
--

commit c3231ce0a6f8ed7d287ec012f30d2735da8daa00
Author: Ahmed Tiba <ahmed.tiba@arm.com>
ACPI: APEI: introduce GHES helper

This commit adds a dedicated GHES_CPER_HELPERS Kconfig entry to allow the
shared helper code to be built even when ACPI_APEI_GHES is disabled. It
updates the build glue and headers to depend on the new symbol.

> diff --git a/drivers/Makefile b/drivers/Makefile
> index 0841ea851847e..27a664cb45ea7 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -31,6 +31,7 @@ obj-y				+= idle/
>  obj-y				+= char/ipmi/
>  
>  obj-$(CONFIG_ACPI)		+= acpi/
> +obj-$(CONFIG_GHES_CPER_HELPERS)	+= acpi/apei/ghes_cper.o

[Severity: Low]
Does compiling an object in a deep subdirectory directly from a top-level
Makefile bypass directory-specific build flags?

Since Kbuild evaluates this in the context of the drivers/ directory rather
than descending into the drivers/acpi/ and drivers/acpi/apei/ Makefiles,
any directory-specific ccflags-y (such as those for ACPI_DEBUG_OUTPUT) will
be ignored.

Could this be addressed by descending into the directories instead using
the standard Kbuild approach?

[ ... ]

> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index f165d14cf61a3..13ef0e99f840b 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -6,6 +6,10 @@
>  config ARCH_SUPPORTS_ACPI
>  	bool
>  
> +config GHES_CPER_HELPERS
> +	bool
> +	select UEFI_CPER

[Severity: Low]
Is this missing select statements for GENERIC_ALLOCATOR and ACPI_APEI?

The ghes_cper.c code uses gen_pool_alloc and gen_pool_free, which depend
on CONFIG_GENERIC_ALLOCATOR. Without selecting GENERIC_ALLOCATOR here,
selecting GHES_CPER_HELPERS in isolation results in linker errors for
missing gen_pool_* symbols.

While this doesn't trigger in this specific commit since ACPI_APEI_GHES
(the only selector) selects both, this missing dependency causes build
errors later in the series when RAS_CPER_ESOURCE selects GHES_CPER_HELPERS
without also selecting GENERIC_ALLOCATOR.

Please note that while the ACPI_APEI dependency issue is fixed later in
the series by the commit "ACPI: APEI: share GHES CPER helpers" through
added #ifdef wrappers, the missing GENERIC_ALLOCATOR dependency remains
unresolved.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260529-topics-ahmtib01-ras_ffh_arm_internal_review-v5-0-2e0500d42642@arm.com?part=7