From: Ben Cheatham <benjamin.cheatham@amd.com>
To: Zaid Alali <zaidal@os.amperecomputing.com>,
rafael@kernel.org, lenb@kernel.org, james.morse@arm.com,
tony.luck@intel.com, bp@alien8.de, robert.moore@intel.com,
Jonathan.Cameron@huawei.com, dan.j.williams@intel.com,
arnd@arndb.de, Avadhut.Naik@amd.com,
u.kleine-koenig@pengutronix.de, john.allen@amd.com,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
acpica-devel@lists.linux.dev
Subject: Re: [RFC PATCH v2 4/8] ACPI: APEI: EINJ: Enable the discovery of EINJv2 capabilities
Date: Wed, 22 May 2024 11:50:40 -0500 [thread overview]
Message-ID: <e58a144a-c4f6-4d20-9ef9-56ee225c31db@amd.com> (raw)
In-Reply-To: <20240521211036.227674-5-zaidal@os.amperecomputing.com>
Hi Zaid,
I've got comments inline with a couple (mostly little) concerns, but this looks really good so far!
On 5/21/24 4:10 PM, Zaid Alali wrote:
> Enable the driver to show all supported error injections for EINJ
> and EINJv2 at the same time. EINJv2 capabilities can be discovered
> by checking the return value of get_error_type, where bit 30 set
> indicates EINJv2 support.
>
> Signed-off-by: Zaid Alali <zaidal@os.amperecomputing.com>
> ---
> drivers/acpi/apei/apei-internal.h | 2 +-
> drivers/acpi/apei/einj-core.c | 35 ++++++++++++++++++++++++-------
> drivers/acpi/apei/einj-cxl.c | 2 +-
> 3 files changed, 29 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/acpi/apei/apei-internal.h b/drivers/acpi/apei/apei-internal.h
> index cd2766c69d78..9a3dbaeed39a 100644
> --- a/drivers/acpi/apei/apei-internal.h
> +++ b/drivers/acpi/apei/apei-internal.h
> @@ -131,7 +131,7 @@ static inline u32 cper_estatus_len(struct acpi_hest_generic_status *estatus)
>
> int apei_osc_setup(void);
>
> -int einj_get_available_error_type(u32 *type);
> +int einj_get_available_error_type(u32 *type, int version);
> int einj_error_inject(u32 type, u32 flags, u64 param1, u64 param2, u64 param3,
> u64 param4);
> int einj_cxl_rch_error_inject(u32 type, u32 flags, u64 param1, u64 param2,
> diff --git a/drivers/acpi/apei/einj-core.c b/drivers/acpi/apei/einj-core.c
> index b1bbbee9c664..cc5ad1f45ea4 100644
> --- a/drivers/acpi/apei/einj-core.c
> +++ b/drivers/acpi/apei/einj-core.c
> @@ -33,6 +33,7 @@
> #define SLEEP_UNIT_MAX 5000 /* 5ms */
> /* Firmware should respond within 1 seconds */
> #define FIRMWARE_TIMEOUT (1 * USEC_PER_SEC)
> +#define ACPI65_EINJV2_SUPP BIT(30)
> #define ACPI5_VENDOR_BIT BIT(31)
> #define MEM_ERROR_MASK (ACPI_EINJ_MEMORY_CORRECTABLE | \
> ACPI_EINJ_MEMORY_UNCORRECTABLE | \
> @@ -84,6 +85,7 @@ static struct debugfs_blob_wrapper vendor_errors;
> static char vendor_dev[64];
>
> static u32 available_error_type;
> +static u32 available_error_type_v2;
>
> /*
> * Some BIOSes allow parameters to the SET_ERROR_TYPE entries in the
> @@ -159,13 +161,13 @@ static void einj_exec_ctx_init(struct apei_exec_context *ctx)
> EINJ_TAB_ENTRY(einj_tab), einj_tab->entries);
> }
>
> -static int __einj_get_available_error_type(u32 *type)
> +static int __einj_get_available_error_type(u32 *type, int version)
> {
> struct apei_exec_context ctx;
> int rc;
>
> einj_exec_ctx_init(&ctx);
> - rc = apei_exec_run(&ctx, ACPI_EINJ_GET_ERROR_TYPE);
> + rc = apei_exec_run(&ctx, version);
> if (rc)
> return rc;
> *type = apei_exec_ctx_get_output(&ctx);
> @@ -174,12 +176,12 @@ static int __einj_get_available_error_type(u32 *type)
> }
>
> /* Get error injection capabilities of the platform */
> -int einj_get_available_error_type(u32 *type)
> +int einj_get_available_error_type(u32 *type, int version)
> {
> int rc;
>
> mutex_lock(&einj_mutex);
> - rc = __einj_get_available_error_type(type);
> + rc = __einj_get_available_error_type(type, version);
> mutex_unlock(&einj_mutex);
>
> return rc;
> @@ -647,15 +649,27 @@ static struct { u32 mask; const char *str; } const einj_error_type_string[] = {
> { BIT(11), "Platform Uncorrectable fatal"},
> { BIT(31), "Vendor Defined Error Types" },
> };
> +static struct { u32 mask; const char *str; } const einjv2_error_type_string[] = {
> + { BIT(0), "EINJV2 Processor Error" },
> + { BIT(1), "EINJV2 Memory Error" },
> + { BIT(2), "EINJV2 PCI Express Error" },
> +};
>
> static int available_error_type_show(struct seq_file *m, void *v)
> {
>
> + seq_printf(m, "EINJ error types:\n");
> for (int pos = 0; pos < ARRAY_SIZE(einj_error_type_string); pos++)
> if (available_error_type & einj_error_type_string[pos].mask)
> seq_printf(m, "0x%08x\t%s\n", einj_error_type_string[pos].mask,
> - einj_error_type_string[pos].str);
> -
> + einj_error_type_string[pos].str);
> + if (available_error_type & ACPI65_EINJV2_SUPP) {
> + seq_printf(m, "EINJv2 error types:\n");
I think this print and the added one above are not needed since the EINJv2 error type
strings have EINJV2 in them already.
> + for (int pos = 0; pos < ARRAY_SIZE(einjv2_error_type_string); pos++)
> + if (available_error_type_v2 & einjv2_error_type_string[pos].mask)
> + seq_printf(m, "0x%08x\t%s\n", einjv2_error_type_string[pos].mask,
> + einjv2_error_type_string[pos].str);
> + }
> return 0;
> }
>
> @@ -692,7 +706,7 @@ int einj_validate_error_type(u64 type)
> if (tval & (tval - 1))
> return -EINVAL;
> if (!vendor)
> - if (!(type & available_error_type))
> + if (!(type & (available_error_type | available_error_type_v2)))
> return -EINVAL;
I don't think this will work? Take the following scenario:
available_error_type = 0x2
available_error_type_v2 = 0x1
If I specify an error type of 0x1 and then inject a EINJv1 error I will have
injected an invalid error type, but still have passed the validation check.
I think you can just get rid of the check for the EINJv2 type here since you also
check it before the actual injection in patch 7/8.
>
> return 0;
> @@ -769,9 +783,14 @@ static int __init einj_probe(struct platform_device *pdev)
> goto err_put_table;
> }
>
> - rc = einj_get_available_error_type(&available_error_type);
> + rc = einj_get_available_error_type(&available_error_type, ACPI_EINJ_GET_ERROR_TYPE);
> if (rc)
> return rc;
> + if (available_error_type & ACPI65_EINJV2_SUPP) {
> + rc = einj_get_available_error_type(&available_error_type_v2, ACPI_EINJV2_GET_ERROR_TYPE);
> + if (rc)
> + return rc;
> + }
>
> rc = -ENOMEM;
> einj_debug_dir = debugfs_create_dir("einj", apei_get_debugfs_dir());
> diff --git a/drivers/acpi/apei/einj-cxl.c b/drivers/acpi/apei/einj-cxl.c
> index 8b8be0c90709..25adc9b03d18 100644
> --- a/drivers/acpi/apei/einj-cxl.c
> +++ b/drivers/acpi/apei/einj-cxl.c
> @@ -30,7 +30,7 @@ int einj_cxl_available_error_type_show(struct seq_file *m, void *v)
> int cxl_err, rc;
> u32 available_error_type = 0;
>
> - rc = einj_get_available_error_type(&available_error_type);
> + rc = einj_get_available_error_type(&available_error_type, ACPI_EINJ_GET_ERROR_TYPE);
> if (rc)
> return rc;
>
next prev parent reply other threads:[~2024-05-22 16:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-21 21:10 [RFC PATCH v2 0/8] Enable EINJv2 support Zaid Alali
2024-05-21 21:10 ` [RFC PATCH v2 1/8] ACPICA: Update values to hex to follow ACPI specs Zaid Alali
2024-05-22 10:10 ` Rafael J. Wysocki
2024-05-21 21:10 ` [RFC PATCH v2 2/8] ACPICA: Add EINJv2 get error type action Zaid Alali
2024-05-21 21:10 ` [RFC PATCH v2 3/8] ACPI: APEI: EINJ: Remove redundant calls to einj_get_available_error_type Zaid Alali
2024-05-23 15:13 ` Jonathan Cameron
2024-05-23 16:02 ` Luck, Tony
2024-05-21 21:10 ` [RFC PATCH v2 4/8] ACPI: APEI: EINJ: Enable the discovery of EINJv2 capabilities Zaid Alali
2024-05-22 16:50 ` Ben Cheatham [this message]
2024-05-21 21:10 ` [RFC PATCH v2 5/8] ACPI: APEI: EINJ: Add einjv2 extension struct Zaid Alali
2024-05-22 16:50 ` Ben Cheatham
2024-05-21 21:10 ` [RFC PATCH v2 6/8] ACPI: APEI: EINJ: Add debugfs files for EINJv2 support Zaid Alali
2024-05-21 21:10 ` [RFC PATCH v2 7/8] ACPI: APEI: EINJ: Enable EINJv2 error injections Zaid Alali
2024-05-22 16:50 ` Ben Cheatham
2024-05-21 21:10 ` [RFC PATCH v2 8/8] ACPI: APEI: EINJ: Update the documentation for EINJv2 support Zaid Alali
2024-05-22 16:50 ` Ben Cheatham
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=e58a144a-c4f6-4d20-9ef9-56ee225c31db@amd.com \
--to=benjamin.cheatham@amd.com \
--cc=Avadhut.Naik@amd.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=acpica-devel@lists.linux.dev \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=james.morse@arm.com \
--cc=john.allen@amd.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=robert.moore@intel.com \
--cc=tony.luck@intel.com \
--cc=u.kleine-koenig@pengutronix.de \
--cc=zaidal@os.amperecomputing.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
all inboxes | Powered by JetHome®