public inbox for linux-doc@vger.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
Subject: Re: [PATCH v2 02/11] ACPI: APEI: GHES: add ghes_cper.o stub
Date: Wed, 11 Mar 2026 12:19:22 +0000	[thread overview]
Message-ID: <8ced1e63-d8d7-42f0-bc45-88e7cc17ef59@arm.com> (raw)
In-Reply-To: <20260224152534.000040b6@huawei.com>

On 24/02/2026 15:25, Jonathan Cameron wrote:
> On Fri, 20 Feb 2026 13:42:20 +0000
> Ahmed Tiba <ahmed.tiba@arm.com> wrote:
> 
>> Introduce a dedicated ghes_cper translation unit so that follow-on commits
>> can move helpers out of ghes.c without touching the build logic twice.
>> This keeps the object in the tree while remaining functionally identical.
> 
> I'd probably do this with the first move patch not as a separate patch.
> That would resolve the question of headers etc below.

I kept the stub as a separate patch intentionally. It isolates the build
system change and the new translation unit so all subsequent patches are
pure mechanical moves, which makes review and bisection straightforward.
If I fold the stub into the first move, the first functional patch
ends up mixing build plumbing and code movement, which is exactly what 
I’m trying to avoid.

>>
>> Signed-off-by: Ahmed Tiba <ahmed.tiba@arm.com>
>> ---
>>   drivers/acpi/apei/Makefile    |  2 +-
>>   drivers/acpi/apei/ghes_cper.c | 26 ++++++++++++++++++++++++++
>>   2 files changed, 27 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/apei/Makefile b/drivers/acpi/apei/Makefile
>> index 1a0b85923cd4..b3774af70883 100644
>> --- a/drivers/acpi/apei/Makefile
>> +++ b/drivers/acpi/apei/Makefile
>> @@ -1,6 +1,6 @@
>>   # SPDX-License-Identifier: GPL-2.0
>>   obj-$(CONFIG_ACPI_APEI)		+= apei.o
>> -obj-$(CONFIG_ACPI_APEI_GHES)	+= ghes.o
>> +obj-$(CONFIG_ACPI_APEI_GHES)	+= ghes.o ghes_cper.o
>>   # clang versions prior to 18 may blow out the stack with KASAN
>>   ifeq ($(CONFIG_COMPILE_TEST)_$(CONFIG_CC_IS_CLANG)_$(call clang-min-version, 180000),y_y_)
>>   KASAN_SANITIZE_ghes.o := n
>> diff --git a/drivers/acpi/apei/ghes_cper.c b/drivers/acpi/apei/ghes_cper.c
>> new file mode 100644
>> index 000000000000..63047322a3d9
>> --- /dev/null
>> +++ b/drivers/acpi/apei/ghes_cper.c
>> @@ -0,0 +1,26 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + *
> 
> As below.
> 
>> + * APEI GHES CPER helper translation unit - staging file for helper moves
>> + *
>> + * Copyright (C) 2026 ARM Ltd.
> 
> As before. If there isn't significant new content copyright doesn't make sense yet.

I can defer the copyright line until there’s more new content.

>> + * Author: Ahmed Tiba <ahmed.tiba@arm.com>
>> + * Based on ACPI APEI GHES driver.
>> + *
> 
> No obvious benefit in this blank line so I'd drop it.

I'll drop it.

>> + */
>> +
>> +#include <linux/err.h>
>> +#include <linux/io.h>
>> +#include <linux/kernel.h>
>> +#include <linux/mm.h>
>> +#include <linux/ratelimit.h>
>> +#include <linux/slab.h>
> Build includes up as they become relevant. That way we can see whether
> they are needed or not.  Right now none of them are..

I’m front‑loading the includes that the subsequent mechanical moves
will need so those patches remain strict cut‑and‑paste with no extra 
edit noise. That keeps the movement obvious and reviewable.

>> +
>> +#include <acpi/apei.h>
>> +
>> +#include <asm/fixmap.h>
>> +#include <asm/tlbflush.h>
>> +
>> +#include "apei-internal.h"
>> +
>> +/* Helper bodies will be moved here in follow-up commits. */
>>
> 


  reply	other threads:[~2026-03-11 12:20 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
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 [this message]
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=8ced1e63-d8d7-42f0-bc45-88e7cc17ef59@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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox