[PATCH v3 0/5] Fix issues with ARM Processor CPER records

[PATCH v3 0/5] Fix issues with ARM Processor CPER records

[Mauro Carvalho Chehab]

This is needed for both kernelspace and userspace properly handle
ARM processor CPER events.

Patch 1 of this series fix the UEFI 2.6+ implementation of the ARM
trace event, as the original implementation was incomplete.
Changeset e9279e83ad1f ("trace, ras: add ARM processor error trace event")
added such event, but it reports only some fields of the CPER record
defined on UEFI 2.6+ appendix N, table N.16.  Those are not enough
actually parse such events on userspace, as not even the event type
is exported.

Patch 2 fixes a compilation breakage when W=1;

Patch 3 adds a new helper function to be used by cper and ghes drivers to
display CPER bitmaps;

Patch 4 fixes CPER logic according with UEFI 2.9A errata. Before it, there
was no description about how processor type field was encoded. The errata
defines it as a bitmask, and provides the information about how it should
be encoded.

Patch 5 adds CPER functions to Kernel-doc.

This series was validated with the help of an ARM EINJ code for QEMU:
	https://gitlab.com/mchehab_kernel/qemu/-/tree/qemu_submission_v5.1?ref_type=heads

	$ ./scripts/ghes_inject.py -d arm -m 2 4 -t tlb-error bus-error,micro-arch
	GUID: e19e3d16-bc11-11e4-9caa-c2051d5d46b0
	CPER:
	      00000000  04 00 00 00 02 00 00 00 68 00 00 00 00 00 00 00   ........h.......
	      00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
	      00000020  00 00 00 00 00 00 00 00 00 20 05 00 04 02 00 03   ......... ......
	      00000030  7f 00 54 00 00 00 00 00 ef be ad de 00 00 00 00   ..T.............
	      00000040  ad 0b ba ab 00 00 00 00 00 20 00 00 18 01 00 03   ......... ......
	      00000050  00 00 00 00 00 00 00 00 ef be ad de 00 00 00 00   ................
	      00000060  ad 0b ba ab 00 00 00 00                           ........

	Error injected.

The CPER event is now properly handled:

[   83.807957] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1
[   83.808314] {1}[Hardware Error]: event severity: recoverable
[   83.808545] {1}[Hardware Error]:  Error 0, type: recoverable
[   83.808806] {1}[Hardware Error]:   section_type: ARM processor error
[   83.809045] {1}[Hardware Error]:   MIDR: 0x0000000000000000
[   83.809262] {1}[Hardware Error]:   running state: 0x0
[   83.809441] {1}[Hardware Error]:   Power State Coordination Interface state: 0
[   83.809691] {1}[Hardware Error]:   Error info structure 0:
[   83.809885] {1}[Hardware Error]:   num errors: 3
[   83.810128] {1}[Hardware Error]:    error_type: 0x04: TLB error
[   83.810364] {1}[Hardware Error]:    error_info: 0x000000000054007f
[   83.810595] {1}[Hardware Error]:     transaction type: Instruction
[   83.810821] {1}[Hardware Error]:     TLB error, operation type: Instruction fetch
[   83.811095] {1}[Hardware Error]:     TLB level: 1
[   83.811283] {1}[Hardware Error]:     processor context not corrupted
[   83.811501] {1}[Hardware Error]:     the error has not been corrected
[   83.811721] {1}[Hardware Error]:     PC is imprecise
[   83.811924] {1}[Hardware Error]:   Error info structure 1:
[   83.812105] {1}[Hardware Error]:   num errors: 2
[   83.812263] {1}[Hardware Error]:    error_type: 0x18: bus error|micro-architectural error
[   83.812956] [Firmware Warn]: GHES: Unhandled processor error type 0x04: TLB error
[   83.813212] [Firmware Warn]: GHES: Unhandled processor error type 0x18: bus error|micro-architectural error

- 

I also tested the ghes and cper reports both with and without this
change, using different versions of rasdaemon, with and without
support for the extended trace event. Those are a summary of the
test results:

- adding more fields to the trace events didn't break userspace API:
  both versions of rasdaemon handled it;

- the rasdaemon patches to handle the new trace report was missing
  a backward-compatibility logic. I fixed already. So, rasdaemon
  can now handle both old and new trace events.

Btw, rasdaemon has gained support for the extended trace since its
version 0.5.8 (released in 2021). I didn't saw any issues there
complain about troubles on it, so either distros used on ARM servers
are using an old version of rasdaemon, or they're carrying on the trace
event changes as well.

---

v3:
 - rebased on the top of 6.11-rc1;
 - test example updated to reflect latest error-inj patch series submitted
   to qemu-devel

v2:
  - removed an uneeded patch adding #ifdef for CONFIG_ARM/ARM64;
  - cper_bits_to_str() now returns the number of chars filled at the buffer;
  - did a cosmetic (blank lines) improvement at include/linux/ras.h;
  - arm_event trace dynamic arrays renamed to pei_buf/ctx_buf/oem_buf.
    

Daniel Ferguson (1):
  RAS: Report all ARM processor CPER information to userspace

Mauro Carvalho Chehab (4):
  efi/cper: Adjust infopfx size to accept an extra space
  efi/cper: Add a new helper function to print bitmasks
  efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs
  docs: efi: add CPER functions to driver-api

 .../driver-api/firmware/efi/index.rst         | 11 ++--
 drivers/acpi/apei/ghes.c                      | 26 +++++-----
 drivers/firmware/efi/cper-arm.c               | 52 +++++++++----------
 drivers/firmware/efi/cper.c                   | 45 +++++++++++++++-
 drivers/ras/ras.c                             | 45 +++++++++++++++-
 include/linux/cper.h                          | 12 +++--
 include/linux/ras.h                           | 16 ++++--
 include/ras/ras_event.h                       | 48 +++++++++++++++--
 8 files changed, 196 insertions(+), 59 deletions(-)

-- 
2.45.2

[PATCH v3 1/5] RAS: Report all ARM processor CPER information to userspace

[Mauro Carvalho Chehab]

From: Daniel Ferguson <danielf@os.amperecomputing.com>

The ARM processor CPER record was added at UEFI 2.6, and hasn't
any changes up to UEFI 2.10 on its struct.

Yet, the original arm_event trace code added on changeset
e9279e83ad1f ("trace, ras: add ARM processor error trace event") is
incomplete, as it only traces some fields of UAPI 2.6 table N.16,
not exporting at all any information from tables N.17 to N.29 of
the record.

This is not enough for user to take appropriate action or to log
what exactly happened.

According to UEFI_2_9 specification chapter N2.4.4, the ARM processor
error section includes:

- several (ERR_INFO_NUM) ARM processor error information structures
  (Tables N.17 to N.20);
- several (CONTEXT_INFO_NUM) ARM processor context information
  structures (Tables N.21 to N.29);
- several vendor specific error information structures. The
  size is given by Section Length minus the size of the other
  fields.

In addition to those data, it also exports two fields that are
parsed by the GHES driver when firmware reports it, e. g.:

- error severity
- cpu logical index

Report all of these information to userspace via trace uAPI, So that
userspace can properly record the error and take decisions related
to cpu core isolation according to error severity and other info.

After this patch, all the data from ARM Processor record from table
N.16 are directly or indirectly visible on userspace:

======================================	=============================
UEFI field on table N.16		ARM Processor trace fields
======================================	=============================
Validation				handled when filling data for
					affinity MPIDR and running
					state.
ERR_INFO_NUM				pei_len
CONTEXT_INFO_NUM			ctx_len
Section Length				indirectly reported by
					pei_len, ctx_len and oem_len
Error affinity level			affinity
MPIDR_EL1				mpidr
MIDR_EL1				midr
Running State				running_state
PSCI State				psci_state
Processor Error Information Structure	pei_err - count at pei_len
Processor Context			ctx_err- count at ctx_len
Vendor Specific Error Info		oem - count at oem_len
======================================	=============================

It should be noticed that decoding of tables N.17 to N.29, if needed,
will be handled on userspace. That gives more flexibility, as there
won't be any need to flood the Kernel with micro-architecture specific
error decoding).
Also, decoding the other fields require a complex logic, and should
be done for each of the several values inside the record field.
So, let userspace daemons like rasdaemon decode them, parsing such
tables and having vendor-specific micro-architecture-specific decoders.

[mchehab: modified patch description, solve merge conflicts and fix coding style]
Fixes: e9279e83ad1f ("trace, ras: add ARM processor error trace event")
Signed-off-by: Shengwei Luo <luoshengwei@huawei.com>
Signed-off-by: Jason Tian <jason@os.amperecomputing.com>
Signed-off-by: Daniel Ferguson <danielf@os.amperecomputing.com>
Tested-by: Shiju Jose <shiju.jose@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Link: https://uefi.org/specs/UEFI/2.10/Apx_N_Common_Platform_Error_Record.html#arm-processor-error-section
---
 drivers/acpi/apei/ghes.c | 11 ++++-----
 drivers/ras/ras.c        | 45 +++++++++++++++++++++++++++++++++++--
 include/linux/ras.h      | 16 +++++++++++---
 include/ras/ras_event.h  | 48 +++++++++++++++++++++++++++++++++++-----
 4 files changed, 103 insertions(+), 17 deletions(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 623cc0cb4a65..06d9351a9abc 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -529,7 +529,7 @@ static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata,
 }
 
 static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata,
-				       int sev, bool sync)
+				     int sev, bool sync)
 {
 	struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata);
 	int flags = sync ? MF_ACTION_REQUIRED : 0;
@@ -537,9 +537,8 @@ static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata,
 	int sec_sev, i;
 	char *p;
 
-	log_arm_hw_error(err);
-
 	sec_sev = ghes_severity(gdata->error_severity);
+	log_arm_hw_error(err, sec_sev);
 	if (sev != GHES_SEV_RECOVERABLE || sec_sev != GHES_SEV_RECOVERABLE)
 		return false;
 
@@ -773,11 +772,9 @@ static bool ghes_do_proc(struct ghes *ghes,
 
 			arch_apei_report_mem_error(sev, mem_err);
 			queued = ghes_handle_memory_failure(gdata, sev, sync);
-		}
-		else if (guid_equal(sec_type, &CPER_SEC_PCIE)) {
+		} else if (guid_equal(sec_type, &CPER_SEC_PCIE)) {
 			ghes_handle_aer(gdata);
-		}
-		else if (guid_equal(sec_type, &CPER_SEC_PROC_ARM)) {
+		} else if (guid_equal(sec_type, &CPER_SEC_PROC_ARM)) {
 			queued = ghes_handle_arm_hw_error(gdata, sev, sync);
 		} else if (guid_equal(sec_type, &CPER_SEC_CXL_GEN_MEDIA_GUID)) {
 			struct cxl_cper_event_rec *rec = acpi_hest_get_payload(gdata);
diff --git a/drivers/ras/ras.c b/drivers/ras/ras.c
index a6e4792a1b2e..359bb163aee0 100644
--- a/drivers/ras/ras.c
+++ b/drivers/ras/ras.c
@@ -52,9 +52,50 @@ void log_non_standard_event(const guid_t *sec_type, const guid_t *fru_id,
 	trace_non_standard_event(sec_type, fru_id, fru_text, sev, err, len);
 }
 
-void log_arm_hw_error(struct cper_sec_proc_arm *err)
+void log_arm_hw_error(struct cper_sec_proc_arm *err, const u8 sev)
 {
-	trace_arm_event(err);
+	struct cper_arm_err_info *err_info;
+	struct cper_arm_ctx_info *ctx_info;
+	u8 *ven_err_data;
+	u32 ctx_len = 0;
+	int n, sz, cpu;
+	s32 vsei_len;
+	u32 pei_len;
+	u8 *pei_err;
+	u8 *ctx_err;
+
+	pei_len = sizeof(struct cper_arm_err_info) * err->err_info_num;
+	pei_err = (u8 *)err + sizeof(struct cper_sec_proc_arm);
+
+	err_info = (struct cper_arm_err_info *)(err + 1);
+	ctx_info = (struct cper_arm_ctx_info *)(err_info + err->err_info_num);
+	ctx_err = (u8 *)ctx_info;
+	for (n = 0; n < err->context_info_num; n++) {
+		sz = sizeof(struct cper_arm_ctx_info) + ctx_info->size;
+		ctx_info = (struct cper_arm_ctx_info *)((long)ctx_info + sz);
+		ctx_len += sz;
+	}
+
+	vsei_len = err->section_length - (sizeof(struct cper_sec_proc_arm) +
+					  pei_len + ctx_len);
+	if (vsei_len < 0) {
+		pr_warn(FW_BUG
+			"section length: %d\n", err->section_length);
+		pr_warn(FW_BUG
+			"section length is too small\n");
+		pr_warn(FW_BUG
+			"firmware-generated error record is incorrect\n");
+		vsei_len = 0;
+	}
+	ven_err_data = (u8 *)ctx_info;
+
+	cpu = GET_LOGICAL_INDEX(err->mpidr);
+	/* when return value is invalid, set cpu index to -1 */
+	if (cpu < 0)
+		cpu = -1;
+
+	trace_arm_event(err, pei_err, pei_len, ctx_err, ctx_len,
+			ven_err_data, (u32)vsei_len, sev, cpu);
 }
 
 static int __init ras_init(void)
diff --git a/include/linux/ras.h b/include/linux/ras.h
index a64182bc72ad..df444492b434 100644
--- a/include/linux/ras.h
+++ b/include/linux/ras.h
@@ -24,8 +24,7 @@ int __init parse_cec_param(char *str);
 void log_non_standard_event(const guid_t *sec_type,
 			    const guid_t *fru_id, const char *fru_text,
 			    const u8 sev, const u8 *err, const u32 len);
-void log_arm_hw_error(struct cper_sec_proc_arm *err);
-
+void log_arm_hw_error(struct cper_sec_proc_arm *err, const u8 sev);
 #else
 static inline void
 log_non_standard_event(const guid_t *sec_type,
@@ -33,7 +32,7 @@ log_non_standard_event(const guid_t *sec_type,
 		       const u8 sev, const u8 *err, const u32 len)
 { return; }
 static inline void
-log_arm_hw_error(struct cper_sec_proc_arm *err) { return; }
+log_arm_hw_error(struct cper_sec_proc_arm *err, const u8 sev) { return; }
 #endif
 
 struct atl_err {
@@ -53,4 +52,15 @@ static inline unsigned long
 amd_convert_umc_mca_addr_to_sys_addr(struct atl_err *err) { return -EINVAL; }
 #endif /* CONFIG_AMD_ATL */
 
+#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+#include <asm/smp_plat.h>
+/*
+ * Include ARM specific SMP header which provides a function mapping mpidr to
+ * cpu logical index.
+ */
+#define GET_LOGICAL_INDEX(mpidr) get_logical_index(mpidr & MPIDR_HWID_BITMASK)
+#else
+#define GET_LOGICAL_INDEX(mpidr) -EINVAL
+#endif /* CONFIG_ARM || CONFIG_ARM64 */
+
 #endif /* __RAS_H__ */
diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
index e5f7ee0864e7..af43857f0934 100644
--- a/include/ras/ras_event.h
+++ b/include/ras/ras_event.h
@@ -168,11 +168,24 @@ TRACE_EVENT(mc_event,
  * This event is generated when hardware detects an ARM processor error
  * has occurred. UEFI 2.6 spec section N.2.4.4.
  */
+#define APEIL "ARM Processor Err Info data len"
+#define APEID "ARM Processor Err Info raw data"
+#define APECIL "ARM Processor Err Context Info data len"
+#define APECID "ARM Processor Err Context Info raw data"
+#define VSEIL "Vendor Specific Err Info data len"
+#define VSEID "Vendor Specific Err Info raw data"
 TRACE_EVENT(arm_event,
 
-	TP_PROTO(const struct cper_sec_proc_arm *proc),
+	TP_PROTO(const struct cper_sec_proc_arm *proc, const u8 *pei_err,
+			const u32 pei_len,
+			const u8 *ctx_err,
+			const u32 ctx_len,
+			const u8 *oem,
+			const u32 oem_len,
+			u8 sev,
+			int cpu),
 
-	TP_ARGS(proc),
+	TP_ARGS(proc, pei_err, pei_len, ctx_err, ctx_len, oem, oem_len, sev, cpu),
 
 	TP_STRUCT__entry(
 		__field(u64, mpidr)
@@ -180,6 +193,14 @@ TRACE_EVENT(arm_event,
 		__field(u32, running_state)
 		__field(u32, psci_state)
 		__field(u8, affinity)
+		__field(u32, pei_len)
+		__dynamic_array(u8, pei_buf, pei_len)
+		__field(u32, ctx_len)
+		__dynamic_array(u8, ctx_buf, ctx_len)
+		__field(u32, oem_len)
+		__dynamic_array(u8, oem_buf, oem_len)
+		__field(u8, sev)
+		__field(int, cpu)
 	),
 
 	TP_fast_assign(
@@ -199,12 +220,29 @@ TRACE_EVENT(arm_event,
 			__entry->running_state = ~0;
 			__entry->psci_state = ~0;
 		}
+		__entry->pei_len = pei_len;
+		memcpy(__get_dynamic_array(pei_buf), pei_err, pei_len);
+		__entry->ctx_len = ctx_len;
+		memcpy(__get_dynamic_array(ctx_buf), ctx_err, ctx_len);
+		__entry->oem_len = oem_len;
+		memcpy(__get_dynamic_array(oem_buf), oem, oem_len);
+		__entry->sev = sev;
+		__entry->cpu = cpu;
 	),
 
-	TP_printk("affinity level: %d; MPIDR: %016llx; MIDR: %016llx; "
-		  "running state: %d; PSCI state: %d",
+	TP_printk("cpu: %d; error: %d; affinity level: %d; MPIDR: %016llx; MIDR: %016llx; "
+		  "running state: %d; PSCI state: %d; "
+		  "%s: %d; %s: %s; %s: %d; %s: %s; %s: %d; %s: %s",
+		  __entry->cpu,
+		  __entry->sev,
 		  __entry->affinity, __entry->mpidr, __entry->midr,
-		  __entry->running_state, __entry->psci_state)
+		  __entry->running_state, __entry->psci_state,
+		  APEIL, __entry->pei_len, APEID,
+		  __print_hex(__get_dynamic_array(pei_buf), __entry->pei_len),
+		  APECIL, __entry->ctx_len, APECID,
+		  __print_hex(__get_dynamic_array(ctx_buf), __entry->ctx_len),
+		  VSEIL, __entry->oem_len, VSEID,
+		  __print_hex(__get_dynamic_array(oem_buf), __entry->oem_len))
 );
 
 /*
-- 
2.45.2

[PATCH v3 0/5] Fix issues with ARM Processor CPER records

[Mauro Carvalho Chehab]

This is needed for both kernelspace and userspace properly handle
ARM processor CPER events.

Patch 1 of this series fix the UEFI 2.6+ implementation of the ARM
trace event, as the original implementation was incomplete.
Changeset e9279e83ad1f ("trace, ras: add ARM processor error trace event")
added such event, but it reports only some fields of the CPER record
defined on UEFI 2.6+ appendix N, table N.16.  Those are not enough
actually parse such events on userspace, as not even the event type
is exported.

Patch 2 fixes a compilation breakage when W=1;

Patch 3 adds a new helper function to be used by cper and ghes drivers to
display CPER bitmaps;

Patch 4 fixes CPER logic according with UEFI 2.9A errata. Before it, there
was no description about how processor type field was encoded. The errata
defines it as a bitmask, and provides the information about how it should
be encoded.

Patch 5 adds CPER functions to Kernel-doc.

This series was validated with the help of an ARM EINJ code for QEMU:

	https://gitlab.com/mchehab_kernel/qemu/-/tree/qemu_submission

$ scripts/ghes_inject.py -d arm -p 0xdeadbeef -t cache,bus,micro-arch

[   11.094205] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 0
[   11.095009] {1}[Hardware Error]: event severity: recoverable
[   11.095486] {1}[Hardware Error]:  Error 0, type: recoverable
[   11.096090] {1}[Hardware Error]:   section_type: ARM processor error
[   11.096399] {1}[Hardware Error]:   MIDR: 0x00000000000f0510
[   11.097135] {1}[Hardware Error]:   Multiprocessor Affinity Register (MPIDR): 0x0000000080000000
[   11.097811] {1}[Hardware Error]:   running state: 0x0
[   11.098193] {1}[Hardware Error]:   Power State Coordination Interface state: 0
[   11.098699] {1}[Hardware Error]:   Error info structure 0:
[   11.099174] {1}[Hardware Error]:   num errors: 2
[   11.099682] {1}[Hardware Error]:    error_type: 0x1a: cache error|bus error|micro-architectural error
[   11.100150] {1}[Hardware Error]:    physical fault address: 0x00000000deadbeef
[   11.111214] Memory failure: 0xdeadb: recovery action for free buddy page: Recovered

- 

I also tested the ghes and cper reports both with and without this
change, using different versions of rasdaemon, with and without
support for the extended trace event. Those are a summary of the
test results:

- adding more fields to the trace events didn't break userspace API:
  both versions of rasdaemon handled it;

- the rasdaemon patches to handle the new trace report was missing
  a backward-compatibility logic. I fixed already. So, rasdaemon
  can now handle both old and new trace events.

Btw, rasdaemon has gained support for the extended trace since its
version 0.5.8 (released in 2021). I didn't saw any issues there
complain about troubles on it, so either distros used on ARM servers
are using an old version of rasdaemon, or they're carrying on the trace
event changes as well.

---

v3:
 - history of patch 1 improved with a chain of co-developed-by;
 - add a better description and an example on patch 3;
 - use BIT_ULL() on patch 3;
 - add a missing include on patch 4.

v2:
  - removed an uneeded patch adding #ifdef for CONFIG_ARM/ARM64;
  - cper_bits_to_str() now returns the number of chars filled at the buffer;
  - did a cosmetic (blank lines) improvement at include/linux/ras.h;
  - arm_event trace dynamic arrays renamed to pei_buf/ctx_buf/oem_buf.
    


Jason Tian (1):
  RAS: Report all ARM processor CPER information to userspace

Mauro Carvalho Chehab (4):
  efi/cper: Adjust infopfx size to accept an extra space
  efi/cper: Add a new helper function to print bitmasks
  efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs
  docs: efi: add CPER functions to driver-api

 .../driver-api/firmware/efi/index.rst         | 11 +++-
 drivers/acpi/apei/ghes.c                      | 27 ++++----
 drivers/firmware/efi/cper-arm.c               | 52 ++++++++--------
 drivers/firmware/efi/cper.c                   | 62 ++++++++++++++++++-
 drivers/ras/ras.c                             | 41 +++++++++++-
 include/linux/cper.h                          | 12 ++--
 include/linux/ras.h                           | 16 ++++-
 include/ras/ras_event.h                       | 48 ++++++++++++--
 8 files changed, 210 insertions(+), 59 deletions(-)

-- 
2.46.0

Re: [PATCH v3 0/5] Fix issues with ARM Processor CPER records

[Borislav Petkov]

On Wed, Sep 04, 2024 at 08:07:13AM +0200, Mauro Carvalho Chehab wrote:
> Jason Tian (1):
>   RAS: Report all ARM processor CPER information to userspace
> 
> Mauro Carvalho Chehab (4):
>   efi/cper: Adjust infopfx size to accept an extra space
>   efi/cper: Add a new helper function to print bitmasks
>   efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs
>   docs: efi: add CPER functions to driver-api
> 
>  .../driver-api/firmware/efi/index.rst         | 11 +++-
>  drivers/acpi/apei/ghes.c                      | 27 ++++----
>  drivers/firmware/efi/cper-arm.c               | 52 ++++++++--------
>  drivers/firmware/efi/cper.c                   | 62 ++++++++++++++++++-
>  drivers/ras/ras.c                             | 41 +++++++++++-
>  include/linux/cper.h                          | 12 ++--
>  include/linux/ras.h                           | 16 ++++-
>  include/ras/ras_event.h                       | 48 ++++++++++++--
>  8 files changed, 210 insertions(+), 59 deletions(-)

With the issues to patch 1 fixed:

Acked-by: Borislav Petkov (AMD) <bp@alien8.de>

I'm presuming this'll go through Ard's tree. Alternatively, I can pick it up
too with Ard's ack.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v3 0/5] Fix issues with ARM Processor CPER records

[Ard Biesheuvel]

On Fri, 11 Oct 2024 at 13:57, Borislav Petkov <bp@alien8.de> wrote:
>
> On Wed, Sep 04, 2024 at 08:07:13AM +0200, Mauro Carvalho Chehab wrote:
> > Jason Tian (1):
> >   RAS: Report all ARM processor CPER information to userspace
> >
> > Mauro Carvalho Chehab (4):
> >   efi/cper: Adjust infopfx size to accept an extra space
> >   efi/cper: Add a new helper function to print bitmasks
> >   efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs
> >   docs: efi: add CPER functions to driver-api
> >
> >  .../driver-api/firmware/efi/index.rst         | 11 +++-
> >  drivers/acpi/apei/ghes.c                      | 27 ++++----
> >  drivers/firmware/efi/cper-arm.c               | 52 ++++++++--------
> >  drivers/firmware/efi/cper.c                   | 62 ++++++++++++++++++-
> >  drivers/ras/ras.c                             | 41 +++++++++++-
> >  include/linux/cper.h                          | 12 ++--
> >  include/linux/ras.h                           | 16 ++++-
> >  include/ras/ras_event.h                       | 48 ++++++++++++--
> >  8 files changed, 210 insertions(+), 59 deletions(-)
>
> With the issues to patch 1 fixed:
>
> Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
>
> I'm presuming this'll go through Ard's tree. Alternatively, I can pick it up
> too with Ard's ack.
>

Either works for me.

Mauro: please put all maintainers on cc of the code you are touching - thanks.

Re: [PATCH v3 0/5] Fix issues with ARM Processor CPER records

[Daniel Ferguson]

On 10/14/2024 3:00 AM, Ard Biesheuvel wrote:
> On Fri, 11 Oct 2024 at 13:57, Borislav Petkov <bp@alien8.de> wrote:
>>
>> On Wed, Sep 04, 2024 at 08:07:13AM +0200, Mauro Carvalho Chehab wrote:
>>> Jason Tian (1):
>>>   RAS: Report all ARM processor CPER information to userspace
>>>
>>> Mauro Carvalho Chehab (4):
>>>   efi/cper: Adjust infopfx size to accept an extra space
>>>   efi/cper: Add a new helper function to print bitmasks
>>>   efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs
>>>   docs: efi: add CPER functions to driver-api
>>>
>>>  .../driver-api/firmware/efi/index.rst         | 11 +++-
>>>  drivers/acpi/apei/ghes.c                      | 27 ++++----
>>>  drivers/firmware/efi/cper-arm.c               | 52 ++++++++--------
>>>  drivers/firmware/efi/cper.c                   | 62 ++++++++++++++++++-
>>>  drivers/ras/ras.c                             | 41 +++++++++++-
>>>  include/linux/cper.h                          | 12 ++--
>>>  include/linux/ras.h                           | 16 ++++-
>>>  include/ras/ras_event.h                       | 48 ++++++++++++--
>>>  8 files changed, 210 insertions(+), 59 deletions(-)
>>
>> With the issues to patch 1 fixed:
>>
>> Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
>>
>> I'm presuming this'll go through Ard's tree. Alternatively, I can pick it up
>> too with Ard's ack.
>>
> 
> Either works for me.
> 
> Mauro: please put all maintainers on cc of the code you are touching - thanks.

What can I do to help this patch move forward?
I noticed it needs to be rebased as of kernel v6.15.

Would it be helpful if I were to rebase, add all the maintainers to the cc, and
resubmit ?

I did rebase to v6.15 and tested. Everything still seems good to go.

Re: [PATCH v3 0/5] Fix issues with ARM Processor CPER records

[Ard Biesheuvel]

On Fri, 6 Jun 2025 at 20:30, Daniel Ferguson
<danielf@os.amperecomputing.com> wrote:
>
>
>
> On 10/14/2024 3:00 AM, Ard Biesheuvel wrote:
> > On Fri, 11 Oct 2024 at 13:57, Borislav Petkov <bp@alien8.de> wrote:
> >>
> >> On Wed, Sep 04, 2024 at 08:07:13AM +0200, Mauro Carvalho Chehab wrote:
> >>> Jason Tian (1):
> >>>   RAS: Report all ARM processor CPER information to userspace
> >>>
> >>> Mauro Carvalho Chehab (4):
> >>>   efi/cper: Adjust infopfx size to accept an extra space
> >>>   efi/cper: Add a new helper function to print bitmasks
> >>>   efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs
> >>>   docs: efi: add CPER functions to driver-api
> >>>
> >>>  .../driver-api/firmware/efi/index.rst         | 11 +++-
> >>>  drivers/acpi/apei/ghes.c                      | 27 ++++----
> >>>  drivers/firmware/efi/cper-arm.c               | 52 ++++++++--------
> >>>  drivers/firmware/efi/cper.c                   | 62 ++++++++++++++++++-
> >>>  drivers/ras/ras.c                             | 41 +++++++++++-
> >>>  include/linux/cper.h                          | 12 ++--
> >>>  include/linux/ras.h                           | 16 ++++-
> >>>  include/ras/ras_event.h                       | 48 ++++++++++++--
> >>>  8 files changed, 210 insertions(+), 59 deletions(-)
> >>
> >> With the issues to patch 1 fixed:
> >>
> >> Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
> >>
> >> I'm presuming this'll go through Ard's tree. Alternatively, I can pick it up
> >> too with Ard's ack.
> >>
> >
> > Either works for me.
> >
> > Mauro: please put all maintainers on cc of the code you are touching - thanks.
>
> What can I do to help this patch move forward?
> I noticed it needs to be rebased as of kernel v6.15.
>
> Would it be helpful if I were to rebase, add all the maintainers to the cc, and
> resubmit ?
>

Yes, please. And make sure you incorporate Boris's feedback on patch
#1 and apply his conditional ack.

Thanks,