From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Ahmed Tiba <ahmed.tiba@arm.com>
Cc: <devicetree@vger.kernel.org>, <linux-acpi@vger.kernel.org>,
<Dmitry.Lamerov@arm.com>, <catalin.marinas@arm.com>,
<bp@alien8.de>, <robh@kernel.org>, <rafael@kernel.org>,
<will@kernel.org>, <conor@kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-doc@vger.kernel.org>, <krzk+dt@kernel.org>,
<Michael.Zhao2@arm.com>, <tony.luck@intel.com>,
"Mauro Carvalho Chehab" <mchehab+huawei@kernel.org>
Subject: Re: [PATCH v2 01/11] ACPI: APEI: GHES: share macros via a private header
Date: Tue, 24 Feb 2026 15:22:30 +0000 [thread overview]
Message-ID: <20260224152230.00000531@huawei.com> (raw)
In-Reply-To: <20260220-topics-ahmtib01-ras_ffh_arm_internal_review-v2-1-347fa2d7351b@arm.com>
On Fri, 20 Feb 2026 13:42:19 +0000
Ahmed Tiba <ahmed.tiba@arm.com> wrote:
> Carve the CPER helper macros out of ghes.c and place them in a private
> header so they can be shared with upcoming helper files. This is a
> mechanical include change with no functional differences.
>
> Signed-off-by: Ahmed Tiba <ahmed.tiba@arm.com>
+CC Mauro as he's been doing a lot of work on error injection recently so
can probably review the use of the various structures much more easily
than I can!
My main comment is on the naming of the new header.
Jonathan
> ---
> drivers/acpi/apei/ghes.c | 60 +-----------------------------
> include/acpi/ghes_cper.h | 95 ++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 96 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index f96aede5d9a3..07b70bcb8342 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
>
> static struct ghes_estatus_cache __rcu *ghes_estatus_caches[GHES_ESTATUS_CACHES_SIZE];
> diff --git a/include/acpi/ghes_cper.h b/include/acpi/ghes_cper.h
> new file mode 100644
> index 000000000000..2597fbadc4f3
> --- /dev/null
> +++ b/include/acpi/ghes_cper.h
> @@ -0,0 +1,95 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * APEI Generic Hardware Error Source: CPER Helper
There is other stuff in her usch as the GHES acks etc
in ghes_clear_estatus(). So I think this intro text
needs a bit more thought. The boundary is already rather
blurred though as for example cper_estatus_len() is only
tangentially connected to cper.
> + *
> + * Copyright (C) 2026 ARM Ltd.
Doesn't make sense to ad this copyright in this patch as so far
it's cut and paste of code from a file that you didn't write (at least
not in 2026!)
Might make sense after a few patches, in which case add the copyright
when it does.
> + * Author: Ahmed Tiba <ahmed.tiba@arm.com>
> + * Based on ACPI APEI GHES driver.
> + *
> + */
> +
> +#ifndef ACPI_APEI_GHES_CPER_H
> +#define ACPI_APEI_GHES_CPER_H
> +
> +#include <linux/workqueue.h>
> +
> +#include <acpi/ghes.h>
> +
> +#define GHES_PFX "GHES: "
> +
> +#define GHES_ESTATUS_MAX_SIZE 65536
> +#define GHES_ESOURCE_PREALLOC_MAX_SIZE 65536
> +
> +#define GHES_ESTATUS_POOL_MIN_ALLOC_ORDER 3
> +
> +/* This is just an estimation for memory pool allocation */
> +#define GHES_ESTATUS_CACHE_AVG_SIZE 512
> +
> +#define GHES_ESTATUS_CACHES_SIZE 4
> +
> +#define GHES_ESTATUS_IN_CACHE_MAX_NSEC 10000000000ULL
> +/* Prevent too many caches are allocated because of RCU */
> +#define GHES_ESTATUS_CACHE_ALLOCED_MAX (GHES_ESTATUS_CACHES_SIZE * 3 / 2)
> +
> +#define GHES_ESTATUS_CACHE_LEN(estatus_len) \
> + (sizeof(struct ghes_estatus_cache) + (estatus_len))
> +#define GHES_ESTATUS_FROM_CACHE(estatus_cache) \
> + ((struct acpi_hest_generic_status *) \
> + ((struct ghes_estatus_cache *)(estatus_cache) + 1))
> +
> +#define GHES_ESTATUS_NODE_LEN(estatus_len) \
> + (sizeof(struct ghes_estatus_node) + (estatus_len))
> +#define GHES_ESTATUS_FROM_NODE(estatus_node) \
> + ((struct acpi_hest_generic_status *) \
> + ((struct ghes_estatus_node *)(estatus_node) + 1))
> +
> +#define GHES_VENDOR_ENTRY_LEN(gdata_len) \
> + (sizeof(struct ghes_vendor_record_entry) + (gdata_len))
> +#define GHES_GDATA_FROM_VENDOR_ENTRY(vendor_entry) \
> + ((struct acpi_hest_generic_data *) \
> + ((struct ghes_vendor_record_entry *)(vendor_entry) + 1))
> +
> +static inline bool is_hest_type_generic_v2(struct ghes *ghes)
> +{
> + return ghes->generic->header.type == ACPI_HEST_TYPE_GENERIC_ERROR_V2;
> +}
> +
> +/*
> + * A platform may describe one error source for the handling of synchronous
> + * errors (e.g. MCE or SEA), or for handling asynchronous errors (e.g. SCI
> + * or External Interrupt). On x86, the HEST notifications are always
> + * asynchronous, so only SEA on ARM is delivered as a synchronous
> + * notification.
> + */
> +static inline bool is_hest_sync_notify(struct ghes *ghes)
> +{
> + u8 notify_type = ghes->generic->notify.type;
> +
> + return notify_type == ACPI_HEST_NOTIFY_SEA;
> +}
> +
> +struct ghes_vendor_record_entry {
> + struct work_struct work;
> + int error_severity;
> + char vendor_record[];
> +};
> +
> +static struct ghes *ghes_new(struct acpi_hest_generic *generic);
> +static void ghes_fini(struct ghes *ghes);
> +
> +static int ghes_read_estatus(struct ghes *ghes,
> + struct acpi_hest_generic_status *estatus,
> + u64 *buf_paddr, enum fixed_addresses fixmap_idx);
> +static void ghes_clear_estatus(struct ghes *ghes,
> + struct acpi_hest_generic_status *estatus,
> + u64 buf_paddr, enum fixed_addresses fixmap_idx);
I'm not sure some of this makes sense in a file named ghes_cper.h
Maybe we just need a different intro comment though.
> +static int __ghes_peek_estatus(struct ghes *ghes,
> + struct acpi_hest_generic_status *estatus,
> + u64 *buf_paddr, enum fixed_addresses fixmap_idx);
> +static int __ghes_check_estatus(struct ghes *ghes,
> + struct acpi_hest_generic_status *estatus);
> +static int __ghes_read_estatus(struct acpi_hest_generic_status *estatus,
> + u64 buf_paddr, enum fixed_addresses fixmap_idx,
> + size_t buf_len);
> +
> +#endif /* ACPI_APEI_GHES_CPER_H */
>
next prev parent reply other threads:[~2026-02-24 15:22 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-20 13:42 [PATCH v2 00/11] ACPI: APEI: share GHES CPER helpers and add DT FFH provider Ahmed Tiba
2026-02-20 13:42 ` [PATCH v2 01/11] ACPI: APEI: GHES: share macros via a private header Ahmed Tiba
2026-02-24 15:22 ` Jonathan Cameron [this message]
2026-03-11 11:39 ` Ahmed Tiba
2026-03-11 12:39 ` Jonathan Cameron
2026-03-11 12:56 ` Ahmed Tiba
2026-02-26 6:44 ` Himanshu Chauhan
2026-03-11 11:55 ` Ahmed Tiba
2026-02-20 13:42 ` [PATCH v2 02/11] ACPI: APEI: GHES: add ghes_cper.o stub Ahmed Tiba
2026-02-24 15:25 ` Jonathan Cameron
2026-03-11 12:19 ` Ahmed Tiba
2026-02-20 13:42 ` [PATCH v2 03/11] ACPI: APEI: GHES: move CPER read helpers Ahmed Tiba
2026-02-24 15:32 ` Jonathan Cameron
2026-03-11 12:38 ` Ahmed Tiba
2026-02-26 5:58 ` Himanshu Chauhan
2026-03-11 13:18 ` Ahmed Tiba
2026-02-20 13:42 ` [PATCH v2 04/11] ACPI: APEI: GHES: move GHESv2 ack and alloc helpers Ahmed Tiba
2026-02-20 13:42 ` [PATCH v2 05/11] ACPI: APEI: GHES: move estatus cache helpers Ahmed Tiba
2026-02-20 13:42 ` [PATCH v2 06/11] ACPI: APEI: GHES: move vendor record helpers Ahmed Tiba
2026-02-20 13:42 ` [PATCH v2 07/11] ACPI: APEI: GHES: move CXL CPER helpers Ahmed Tiba
2026-02-24 15:34 ` Jonathan Cameron
2026-02-20 13:42 ` [PATCH v2 08/11] ACPI: APEI: introduce GHES helper Ahmed Tiba
2026-02-20 13:42 ` [PATCH v2 09/11] ACPI: APEI: share GHES CPER helpers Ahmed Tiba
2026-02-20 19:19 ` kernel test robot
2026-02-20 19:24 ` kernel test robot
2026-02-20 20:37 ` kernel test robot
2026-02-20 21:16 ` kernel test robot
2026-02-20 13:42 ` [PATCH v2 10/11] dt-bindings: firmware: add arm,ras-ffh Ahmed Tiba
2026-02-26 7:03 ` Himanshu Chauhan
2026-03-11 13:41 ` Ahmed Tiba
2026-02-20 13:42 ` [PATCH v2 11/11] RAS: add DeviceTree firmware-first CPER provider Ahmed Tiba
2026-02-21 9:06 ` Krzysztof Kozlowski
2026-02-23 19:10 ` Ahmed Tiba
2026-02-24 15:55 ` Jonathan Cameron
2026-03-12 12:23 ` Ahmed Tiba
2026-03-12 14:50 ` Jonathan Cameron
2026-02-26 7:01 ` Himanshu Chauhan
2026-02-26 7:05 ` [PATCH v2 00/11] ACPI: APEI: share GHES CPER helpers and add DT FFH provider Himanshu Chauhan
2026-03-11 10:44 ` Ahmed Tiba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260224152230.00000531@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=Dmitry.Lamerov@arm.com \
--cc=Michael.Zhao2@arm.com \
--cc=ahmed.tiba@arm.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=mchehab+huawei@kernel.org \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=tony.luck@intel.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.