All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Zaid Alali <zaidal@os.amperecomputing.com>
Cc: <rafael@kernel.org>, <lenb@kernel.org>, <james.morse@arm.com>,
	<tony.luck@intel.com>, <bp@alien8.de>, <robert.moore@intel.com>,
	<dan.j.williams@intel.com>, <Benjamin.Cheatham@amd.com>,
	<Avadhut.Naik@amd.com>, <viro@zeniv.linux.org.uk>,
	<arnd@arndb.de>, <ira.weiny@intel.com>, <dave.jiang@intel.com>,
	<sthanneeru.opensrc@micron.com>, <linux-acpi@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <acpica-devel@lists.linux.dev>
Subject: Re: [PATCH v2 5/9] ACPI: APEI: EINJ: Enable the discovery of EINJv2 capabilities
Date: Tue, 24 Dec 2024 15:46:50 +0000	[thread overview]
Message-ID: <20241224154650.00006a06@huawei.com> (raw)
In-Reply-To: <20241205211854.43215-6-zaidal@os.amperecomputing.com>

On Thu,  5 Dec 2024 13:18:50 -0800
Zaid Alali <zaidal@os.amperecomputing.com> 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.
> 
> This update makes the driver parse the error_type as a string to
> avoid any ambiguity with EINJv1 and EINJv2 error types that has
> the same value, where EINJv2 error types has the prefix "V2_".
> 
> Signed-off-by: Zaid Alali <zaidal@os.amperecomputing.com>
Hi Zaid,

Some comments inline.

Thanks,

Jonathan

> ---
>  drivers/acpi/apei/apei-internal.h |  2 +-
>  drivers/acpi/apei/einj-core.c     | 70 ++++++++++++++++++++++++-------
>  drivers/acpi/apei/einj-cxl.c      |  2 +-
>  3 files changed, 56 insertions(+), 18 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);

As below. I'm not sure version is a good name for this as it
is not the version number at all.

>  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 a6b648361d96..2c57e25252ac 100644
> --- a/drivers/acpi/apei/einj-core.c
> +++ b/drivers/acpi/apei/einj-core.c

> @@ -641,6 +643,7 @@ static u64 error_param2;
>  static u64 error_param3;
>  static u64 error_param4;
>  static struct dentry *einj_debug_dir;
> +static char *einj_buf;
>  static struct { u32 mask; const char *str; } const einj_error_type_string[] = {
>  	{ BIT(0), "Processor Correctable" },
>  	{ BIT(1), "Processor Uncorrectable non-fatal" },
> @@ -656,6 +659,11 @@ static struct { u32 mask; const char *str; } const einj_error_type_string[] = {
>  	{ BIT(11), "Platform Uncorrectable fatal"},
>  	{ BIT(31), "Vendor Defined Error Types" },
>  };

blank line here.

> +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)
>  {
> @@ -663,18 +671,22 @@ static int available_error_type_show(struct seq_file *m, void *v)
>  	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);

Fix this up and check for any other accidental changes like this. They just
make the patches harder to review.


> +	if (available_error_type & ACPI65_EINJV2_SUPP) {
> +		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, "V2_0x%08x\t%s\n", einjv2_error_type_string[pos].mask,

Long line. I'd wrap before last parameter for readability.

> +					einjv2_error_type_string[pos].str);

Align after closing bracket.

> +	}
>  	return 0;
>  }
>  
>  DEFINE_SHOW_ATTRIBUTE(available_error_type);
>  
> -static int error_type_get(void *data, u64 *val)
> +static ssize_t error_type_get(struct file *file, char __user *buf,
> +				size_t count, loff_t *ppos)
>  {
> -	*val = error_type;
> -
> -	return 0;
> +	return simple_read_from_buffer(buf, count, ppos, einj_buf, strlen(einj_buf));
>  }
>  
>  bool einj_is_cxl_error_type(u64 type)
> @@ -701,15 +713,28 @@ 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)))

Maybe a comment on this. Not obvious to me which the | makes sense.

>  			return -EINVAL;
>  
>  	return 0;
>  }
>  
> -static int error_type_set(void *data, u64 val)
> +static ssize_t error_type_set(struct file *file, const char __user *buf,
> +				size_t count, loff_t *ppos)
>  {
>  	int rc;
> +	u64 val;
> +
> +	memset(einj_buf, 0, sizeof(einj_buf));

sizeof the pointer?

> +	if (copy_from_user(einj_buf, buf, count))

What stops this being bigger than einj_buf?  Perhaps
best to check that.

> +		return -EFAULT;
> +
> +	if (strncmp(einj_buf, "V2_", 3) == 0) {
> +		if (!sscanf(einj_buf, "V2_%llx", &val))
> +			return -EINVAL;
> +	} else
	} else {

Both because you kernel style is same bracketing for all legs
of if / else and because what follows is multi line.

> +		if (!sscanf(einj_buf, "%llx", &val))
> +			return -EINVAL;
>  
>  	rc = einj_validate_error_type(val);
>  	if (rc)
> @@ -717,11 +742,13 @@ static int error_type_set(void *data, u64 val)
>  
>  	error_type = val;
>  
> -	return 0;
> +	return count;
>  }

>  static int error_inject_set(void *data, u64 val)
>  {
> @@ -778,9 +805,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);
The parameter is called version. I'd expect that to just be 1 or 2 giving naming.
Maybe a different parameter name would be less confusing?

> +		if (rc)
> +			return rc;
> +	}
>  
>  	rc = -ENOMEM;
>  	einj_debug_dir = debugfs_create_dir("einj", apei_get_debugfs_dir());
> @@ -828,6 +860,11 @@ static int __init einj_probe(struct platform_device *pdev)
>  				   einj_debug_dir, &notrigger);
>  	}
>  
> +	einj_buf = kzalloc(32, GFP_KERNEL);

Why 32? Can we base that on a define or similar?
Given it is global anyway and fairly small, why not just declare
a static array and skip the allocation and free?


> +	if (!einj_buf) {
> +		goto err_release;

Not sure on local style, but general kernel style is no brackets for single line if block.

> +	}
> +
>  	if (vendor_dev[0]) {
>  		vendor_blob.data = vendor_dev;
>  		vendor_blob.size = strlen(vendor_dev);
> @@ -875,6 +912,7 @@ static void __exit einj_remove(struct platform_device *pdev)
>  	apei_resources_fini(&einj_resources);
>  	debugfs_remove_recursive(einj_debug_dir);
>  	acpi_put_table((struct acpi_table_header *)einj_tab);
> +	kfree(einj_buf);
>  }
>  

>  	if (rc)
>  		return rc;
>  


  parent reply	other threads:[~2024-12-24 15:46 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-05 21:18 [PATCH v2 0/9] Enable EINJv2 support Zaid Alali
2024-12-05 21:18 ` [PATCH v2 1/9] ACPICA: Update values to hex to follow ACPI specs Zaid Alali
2024-12-05 21:18 ` [PATCH v2 2/9] ACPICA: Add EINJv2 get error type action Zaid Alali
2024-12-05 21:18 ` [PATCH v2 3/9] ACPI: APEI: EINJ: Fix kernel test robot sparse warning Zaid Alali
2024-12-06  3:21   ` kernel test robot
2024-12-24 15:28   ` Jonathan Cameron
2025-01-02 21:24     ` Zaid Alali
2024-12-05 21:18 ` [PATCH v2 4/9] ACPI: APEI: EINJ: Remove redundant calls to einj_get_available_error_type Zaid Alali
2024-12-24 15:32   ` Jonathan Cameron
2024-12-05 21:18 ` [PATCH v2 5/9] ACPI: APEI: EINJ: Enable the discovery of EINJv2 capabilities Zaid Alali
2024-12-06  3:10   ` kernel test robot
2024-12-06  4:54   ` kernel test robot
2024-12-06 21:02   ` kernel test robot
2024-12-24 15:46   ` Jonathan Cameron [this message]
2024-12-05 21:18 ` [PATCH v2 6/9] ACPI: APEI: EINJ: Add einjv2 extension struct Zaid Alali
2024-12-24 15:51   ` Jonathan Cameron
2025-02-06 22:08     ` Zaid Alali
2024-12-05 21:18 ` [PATCH v2 7/9] ACPI: APEI: EINJ: Add debugfs files for EINJv2 support Zaid Alali
2024-12-05 21:18 ` [PATCH v2 8/9] ACPI: APEI: EINJ: Enable EINJv2 error injections Zaid Alali
2024-12-24 15:57   ` Jonathan Cameron
2024-12-05 21:18 ` [PATCH v2 9/9] ACPI: APEI: EINJ: Update the documentation for EINJv2 support Zaid Alali
2025-01-08  9:55   ` Lai, Yi

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=20241224154650.00006a06@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=Avadhut.Naik@amd.com \
    --cc=Benjamin.Cheatham@amd.com \
    --cc=acpica-devel@lists.linux.dev \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=ira.weiny@intel.com \
    --cc=james.morse@arm.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=sthanneeru.opensrc@micron.com \
    --cc=tony.luck@intel.com \
    --cc=viro@zeniv.linux.org.uk \
    --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 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.