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 v3 5/9] ACPI: APEI: EINJ: Enable the discovery of EINJv2 capabilities
Date: Wed, 12 Feb 2025 16:47:45 +0000	[thread overview]
Message-ID: <20250212164745.00000c5f@huawei.com> (raw)
In-Reply-To: <20250210183705.1114624-6-zaidal@os.amperecomputing.com>

On Mon, 10 Feb 2025 10:37:01 -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.
> 
> Signed-off-by: Zaid Alali <zaidal@os.amperecomputing.com>
Hi Zaid,
A few comments inline.

Jonathan

> diff --git a/drivers/acpi/apei/einj-core.c b/drivers/acpi/apei/einj-core.c
> index 0f65e8bc4c30..369d92e410c1 100644
> --- a/drivers/acpi/apei/einj-core.c
> +++ b/drivers/acpi/apei/einj-core.c

> @@ -649,6 +651,8 @@ static u64 error_param2;
>  static u64 error_param3;
>  static u64 error_param4;
>  static struct dentry *einj_debug_dir;
> +#define BUFF_SIZE	32

That's very generic name. I'd just put value inline and where
you use it currently just use sizeof(einj_buf) instead.

> +static char einj_buf[BUFF_SIZE];
>  static struct { u32 mask; const char *str; } const einj_error_type_string[] = {
>  	{ BIT(0), "Processor Correctable" },
>  	{ BIT(1), "Processor Uncorrectable non-fatal" },
> @@ -665,6 +669,12 @@ static struct { u32 mask; const char *str; } const einj_error_type_string[] = {
>  	{ 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)
>  {
>  
> @@ -672,17 +682,21 @@ static int available_error_type_show(struct seq_file *m, void *v)
>  		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);
> -
> +	if (available_error_type & ACPI65_EINJV2_SUPP) {
> +		for (int pos = 0; pos < ARRAY_SIZE(einjv2_error_type_string); pos++)

Add some {} probably as multiple lines.  Coding style is a little unclear on this
but here I think it would help a little.

> +			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,
> +					   einjv2_error_type_string[pos].str);
> +	}
>  	return 0;
>  }

>  bool einj_is_cxl_error_type(u64 type)
> @@ -715,9 +729,22 @@ int einj_validate_error_type(u64 type)
>  	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, BUFF_SIZE);
> +	if (copy_from_user(einj_buf, buf, count))
> +		return -EFAULT;
> +
> +	if (strncmp(einj_buf, "V2_", 3) == 0) {
> +		if (!sscanf(einj_buf, "V2_%llx", &val))
> +			return -EINVAL;
> +	} else

Brackets in this leg as well.
Convention is put them in all legs + this one is also multiline so
should be here anyway.

> +		if (!sscanf(einj_buf, "%llx", &val))
> +			return -EINVAL;
>  
>  	rc = einj_validate_error_type(val);
>  	if (rc)
> @@ -725,11 +752,13 @@ static int error_type_set(void *data, u64 val)
>  
>  	error_type = val;
>  
> -	return 0;
> +	return count;
>  }
>  
> -DEFINE_DEBUGFS_ATTRIBUTE(error_type_fops, error_type_get, error_type_set,
> -			 "0x%llx\n");
> +static const struct file_operations error_type_fops = {
> +	.read		= error_type_get,
> +	.write		= error_type_set,
> +};
>  
>  static int error_inject_set(void *data, u64 val)
>  {
> @@ -737,7 +766,7 @@ static int error_inject_set(void *data, u64 val)
>  		return -EINVAL;
>  
>  	return einj_error_inject(error_type, error_flags, error_param1, error_param2,
> -		error_param3, error_param4);
> +				error_param3, error_param4);
I'd avoid reformatting in a patch doing anything else.
Hard to spot if real changes...

>  }
>  


  reply	other threads:[~2025-02-12 16:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-10 18:36 [PATCH v3 0/9] Enable EINJv2 Support Zaid Alali
2025-02-10 18:36 ` [PATCH v3 1/9] ACPICA: Update values to hex to follow ACPI specs Zaid Alali
2025-02-10 18:36 ` [PATCH v3 2/9] ACPICA: Add EINJv2 get error type action Zaid Alali
2025-02-10 18:36 ` [PATCH v3 3/9] ACPI: APEI: EINJ: Fix kernel test robot sparse warning Zaid Alali
2025-02-12 16:35   ` Jonathan Cameron
2025-02-10 18:37 ` [PATCH v3 4/9] ACPI: APEI: EINJ: Remove redundant calls to einj_get_available_error_type Zaid Alali
2025-02-12 16:37   ` Jonathan Cameron
2025-02-10 18:37 ` [PATCH v3 5/9] ACPI: APEI: EINJ: Enable the discovery of EINJv2 capabilities Zaid Alali
2025-02-12 16:47   ` Jonathan Cameron [this message]
2025-02-10 18:37 ` [PATCH v3 6/9] ACPI: APEI: EINJ: Add einjv2 extension struct Zaid Alali
2025-02-12 16:49   ` Jonathan Cameron
2025-02-10 18:37 ` [PATCH v3 7/9] ACPI: APEI: EINJ: Add debugfs files for EINJv2 support Zaid Alali
2025-02-12 16:54   ` Jonathan Cameron
2025-02-10 18:37 ` [PATCH v3 8/9] ACPI: APEI: EINJ: Enable EINJv2 error injections Zaid Alali
2025-02-12 17:04   ` Jonathan Cameron
2025-02-10 18:37 ` [PATCH v3 9/9] ACPI: APEI: EINJ: Update the documentation for EINJv2 support Zaid Alali

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=20250212164745.00000c5f@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.