From: "Elliott, Robert (Servers)" <elliott@hpe.com>
To: Jia He <justin.he@arm.com>, Len Brown <lenb@kernel.org>,
James Morse <james.morse@arm.com>,
Tony Luck <tony.luck@intel.com>, Borislav Petkov <bp@alien8.de>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Robert Richter <rric@kernel.org>,
Robert Moore <robert.moore@intel.com>,
Qiuxu Zhuo <qiuxu.zhuo@intel.com>,
Yazen Ghannam <yazen.ghannam@amd.com>,
"Jonathan Corbet" <corbet@lwn.net>,
Jan Luebbe <jlu@pengutronix.de>,
Khuong Dinh <khuong@os.amperecomputing.com>,
"Kani, Toshi" <toshi.kani@hpe.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
"devel@acpica.org" <devel@acpica.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Shuai Xue <xueshuai@linux.alibaba.com>,
Jarkko Sakkinen <jarkko@kernel.org>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
"nd@arm.com" <nd@arm.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Neeraj Upadhyay" <quic_neeraju@quicinc.com>,
Randy Dunlap <rdunlap@infradead.org>,
Damien Le Moal <damien.lemoal@opensource.wdc.com>,
Muchun Song <songmuchun@bytedance.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"stable@kernel.org" <stable@kernel.org>
Subject: RE: [RESEND PATCH v3 3/9] EDAC/ghes: Make ghes_edac a proper module to remove the dependency on ghes
Date: Fri, 26 Aug 2022 22:42:13 +0000 [thread overview]
Message-ID: <MW5PR84MB1842F7107770654C46CB0311AB759@MW5PR84MB1842.NAMPRD84.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <20220822154048.188253-4-justin.he@arm.com>
> -----Original Message-----
> From: Jia He <justin.he@arm.com>
> Sent: Monday, August 22, 2022 10:41 AM
> Subject: [RESEND PATCH v3 3/9] EDAC/ghes: Make ghes_edac a proper module to
> remove the dependency on ghes
1. I suggest adding:
MODULE_ALIAS("acpi*")
so udev will automatically load the module on any system with ACPI.
> drivers/edac/Kconfig
> config EDAC_GHES
> + tristate "Output ACPI APEI/GHES BIOS detected errors via EDAC"
2. I suggest:
tristate "APEI (ACPI Platform Error Interfaces) GHES (Generic Hardware Error Source)"
That's in a menu of EDAC drivers, so no suffix is needed.
3. The Kconfig help text needs some updates, since the drivers are now ordering
themselves to avoid race conditions.
Current:
Not all machines support hardware-driven error report. Some of those
provide a BIOS-driven error report mechanism via ACPI, using the
APEI/GHES driver. By enabling this option, the error reports provided
by GHES are sent to userspace via the EDAC API.
When this option is enabled, it will disable the hardware-driven
mechanisms, if a GHES BIOS is detected, entering into the
"Firmware First" mode.
It should be noticed that keeping both GHES and a hardware-driven
error mechanism won't work well, as BIOS will race with OS, while
reading the error registers. So, if you want to not use "Firmware
first" GHES error mechanism, you should disable GHES either at
compilation time or by passing "ghes.disable=1" Kernel parameter
at boot time.
In doubt, say 'Y'.
Suggestion:
Support for error detection and correction based on APEI (ACPI Platform
Error Interfaces), which allows system firmware to report hardware errors
via the HEST (Hardware Error Source Table) using GHES (Generic Hardware
Error Source) records. Some systems perform "firmware first" processing
of errors before reporting them.
This module is supported in systems supporting GHES. If the architecture
is x86, the module only loads if the platform is listed in a known-good
platform list (see drivers/edac/ghes_edac.c) or if ghes.force_load=1
is specified on the kernel command line).
4. In the help text for each module that looks for GHES and refuses to load
(e.g., EDAC_AMD64), add a sentence:
This module does not load on a system supporting ACPI GHES.
> drivers/acpi/apei/ghes.c
> +MODULE_DESCRIPTION("Output ACPI APEI/GHES BIOS detected errors module via EDAC");
5. I suggest:
MODULE_DESCRIPTION("APEI (ACPI Platform Error Interfaces) GHES (Generic Hardware Error Source) EDAC driver")
next prev parent reply other threads:[~2022-08-26 22:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-22 15:40 [RESEND PATCH v3 0/9] Make ghes_edac a proper module Jia He
2022-08-22 15:40 ` [RESEND PATCH v3 1/9] efi/cper: export several helpers for ghes_edac to use Jia He
2022-08-22 15:40 ` [RESEND PATCH v3 2/9] EDAC/ghes: Add a notifier for reporting memory errors Jia He
2022-08-22 15:40 ` [RESEND PATCH v3 3/9] EDAC/ghes: Make ghes_edac a proper module to remove the dependency on ghes Jia He
2022-08-24 15:37 ` Borislav Petkov
2022-08-25 12:21 ` Justin He
2022-08-26 19:30 ` Kani, Toshi
2022-08-26 22:42 ` Elliott, Robert (Servers) [this message]
2022-08-27 5:22 ` Borislav Petkov
2022-08-29 15:59 ` Yazen Ghannam
2022-08-29 20:39 ` Borislav Petkov
2022-08-29 21:37 ` Kani, Toshi
2022-08-22 15:40 ` [RESEND PATCH v3 4/9] EDAC/ghes: Move ghes_edac.force_load to setup parameter Jia He
2022-08-24 15:52 ` Borislav Petkov
2022-08-25 9:42 ` Justin He
2022-08-30 1:21 ` Justin He
2022-08-22 15:40 ` [RESEND PATCH v3 5/9] EDAC: Don't load chipset-specific edac drivers when ghes_edac is preferred Jia He
2022-08-24 23:04 ` Kani, Toshi
2022-08-25 9:45 ` Justin He
2022-08-25 23:38 ` Kani, Toshi
2022-08-22 15:40 ` [RESEND PATCH v3 6/9] ghes: Introduce a flag ghes_present Jia He
2022-08-22 15:40 ` [RESEND PATCH v3 7/9] apei/ghes: Use unrcu_pointer for cmpxchg Jia He
2022-08-22 15:40 ` [RESEND PATCH v3 8/9] EDAC/igen6: Keep returned errno consistent when edac mc has been enabled Jia He
2022-08-22 15:40 ` [RESEND PATCH v3 9/9] edac: Don't load Arm specific edac drivers when ghes_edac is preferred Jia He
2022-08-23 1:49 ` [RESEND PATCH v3 0/9] Make ghes_edac a proper module Justin He
2022-08-23 17:19 ` Rafael J. Wysocki
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=MW5PR84MB1842F7107770654C46CB0311AB759@MW5PR84MB1842.NAMPRD84.PROD.OUTLOOK.COM \
--to=elliott@hpe.com \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=damien.lemoal@opensource.wdc.com \
--cc=devel@acpica.org \
--cc=james.morse@arm.com \
--cc=jarkko@kernel.org \
--cc=jlu@pengutronix.de \
--cc=justin.he@arm.com \
--cc=khuong@os.amperecomputing.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=nd@arm.com \
--cc=paulmck@kernel.org \
--cc=qiuxu.zhuo@intel.com \
--cc=quic_neeraju@quicinc.com \
--cc=rafael@kernel.org \
--cc=rdunlap@infradead.org \
--cc=robert.moore@intel.com \
--cc=rric@kernel.org \
--cc=songmuchun@bytedance.com \
--cc=stable@kernel.org \
--cc=tony.luck@intel.com \
--cc=toshi.kani@hpe.com \
--cc=xueshuai@linux.alibaba.com \
--cc=yazen.ghannam@amd.com \
/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