All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ahmed Tiba <ahmed.tiba@arm.com>
To: Jonathan Cameron <jonathan.cameron@huawei.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: Wed, 11 Mar 2026 11:39:38 +0000	[thread overview]
Message-ID: <d0911510-9f87-49ed-b896-fa00e5d2a98b@arm.com> (raw)
In-Reply-To: <20260224152230.00000531@huawei.com>

On 24/02/2026 15:22, Jonathan Cameron wrote:
> 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

The content is intentionally GHES‑specific CPER handling,
not generic UEFI CPER. It's the GHES view of CPER parsing/handling
and is used by the shared GHES/DT path, so keeping it in ghes_cper.h 
documents that boundary better than moving it to ghes.h (which also 
contains non‑CPER GHES logic). The helpers moved there are the ones 
needed by the shared CPER handling path.

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

The file is new and maintained by Arm as part of this refactor,
so I kept the header consistent with other newly introduced files.

>> + * 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 */
>>
> 


  reply	other threads:[~2026-03-11 11:40 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
2026-03-11 11:39     ` Ahmed Tiba [this message]
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=d0911510-9f87-49ed-b896-fa00e5d2a98b@arm.com \
    --to=ahmed.tiba@arm.com \
    --cc=Dmitry.Lamerov@arm.com \
    --cc=Michael.Zhao2@arm.com \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=conor@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jonathan.cameron@huawei.com \
    --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.