From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Ben Cheatham <benjamin.cheatham@amd.com>
Cc: <dan.j.williams@intel.com>, <rafael@kernel.org>,
<james.morse@arm.com>, <tony.luck@intel.com>, <bp@alien8.de>,
<dave@stogolabs.net>, <dave.jiang@intel.com>,
<alison.schofield@intel.com>, <vishal.l.verma@intel.com>,
<ira.weiny@intel.com>, <linux-cxl@vger.kernel.org>,
<linux-acpi@vger.kernel.org>
Subject: Re: [PATCH v14 2/4] EINJ: Add CXL error type support
Date: Thu, 7 Mar 2024 14:55:02 +0000 [thread overview]
Message-ID: <20240307145502.00000ba6@Huawei.com> (raw)
In-Reply-To: <77533c2f-99c0-4281-bc1b-cc970957510a@amd.com>
On Thu, 7 Mar 2024 08:46:49 -0600
Ben Cheatham <benjamin.cheatham@amd.com> wrote:
> Hey Jonathan, thanks for taking a look!
>
> On 3/7/24 6:09 AM, Jonathan Cameron wrote:
> > On Mon, 26 Feb 2024 16:27:02 -0600
> > Ben Cheatham <Benjamin.Cheatham@amd.com> wrote:
> >
> >> Remove CXL protocol error types from the EINJ module and move them to
> >> a new einj_cxl module. The einj_cxl module implements the necessary
> >> handling for CXL protocol error injection and exposes an API for the
> >> CXL core to use said functionality. Because the CXL error types
> >> require special handling, only allow them to be injected through the
> >> einj_cxl module and return an error when attempting to inject through
> >> "regular" EINJ.
> >>
> >> Signed-off-by: Ben Cheatham <Benjamin.Cheatham@amd.com>
> > Hi Ben,
> >
> > Some minor comments inline given you are doing a v15 (yikes!)
> >
>
> Yeah I know :(.
>
With headers tidied up.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >
> >
> >> + { BIT(13), "CXL.cache Protocol Uncorrectable non-fatal" },
> >> + { BIT(14), "CXL.cache Protocol Uncorrectable fatal" },
> >> + { BIT(15), "CXL.mem Protocol Correctable" },
> >> + { BIT(16), "CXL.mem Protocol Uncorrectable non-fatal" },
> >> + { BIT(17), "CXL.mem Protocol Uncorrectable fatal" },
> >> +};
> >> +
> >> +int einj_cxl_available_error_type_show(struct seq_file *m, void *v)
> >> +{
> >> + int cxl_err, rc;
> >> + u32 available_error_type = 0;
> >> +
> >> + if (!einj_initialized)
> >> + return -ENXIO;
> >> +
> >> + rc = einj_get_available_error_type(&available_error_type);
> >> + if (rc)
> >> + return rc;
> >> +
> >> + for (int pos = 0; pos < ARRAY_SIZE(einj_cxl_error_type_string); pos++) {
> >> + cxl_err = ACPI_EINJ_CXL_CACHE_CORRECTABLE << pos;
> > Hmm. This is a little ugly.
> > Could do something like the following bit it's of similar level of ugly
> > so up to you.
> >
> > int bit_pos = ACPI_EINJ_CXL_CACHE_CORRECTABLE;
> > for_each_bit_set_bit_from(bit_pos, &available_error_type,
> > ARRAY_SIZE(einj_cxl_error_type_string)) {
> > int pos = bit_pos - ACPI_EINJ_CXL_CACHE_CORRECTABLE;
> >
>
> I agree it's ugly. I think this version has the added benfit of parity
> with einj_available_error_type_show() in einj-core.c, so I think it's
> better to keep it this way if it's the same to you.
>
Sure. We can always (maybe) tidy them both up later :)
J
next prev parent reply other threads:[~2024-03-07 14:55 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-26 22:27 [PATCH v14 0/4] cxl, EINJ: Update EINJ for CXL error types Ben Cheatham
2024-02-26 22:27 ` [PATCH v14 1/4] EINJ: Migrate to a platform driver Ben Cheatham
2024-02-28 5:47 ` Dan Williams
2024-02-28 14:28 ` Ben Cheatham
2024-03-07 11:52 ` Jonathan Cameron
2024-02-26 22:27 ` [PATCH v14 2/4] EINJ: Add CXL error type support Ben Cheatham
2024-02-26 22:47 ` Luck, Tony
2024-02-27 14:56 ` Ben Cheatham
2024-02-27 20:14 ` Ben Cheatham
2024-02-28 6:00 ` Dan Williams
2024-02-28 14:28 ` Ben Cheatham
2024-02-28 6:04 ` Dan Williams
2024-02-28 14:28 ` Ben Cheatham
2024-03-07 12:09 ` Jonathan Cameron
2024-03-07 14:46 ` Ben Cheatham
2024-03-07 14:55 ` Jonathan Cameron [this message]
2024-02-26 22:27 ` [PATCH v14 3/4] cxl/core: Add CXL EINJ debugfs files Ben Cheatham
2024-02-27 20:14 ` Ben Cheatham
2024-03-07 12:10 ` Jonathan Cameron
2024-03-07 14:46 ` Ben Cheatham
2024-02-26 22:27 ` [PATCH v14 4/4] EINJ, Documentation: Update EINJ kernel doc Ben Cheatham
2024-03-07 12:12 ` Jonathan Cameron
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=20240307145502.00000ba6@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=alison.schofield@intel.com \
--cc=benjamin.cheatham@amd.com \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stogolabs.net \
--cc=ira.weiny@intel.com \
--cc=james.morse@arm.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=tony.luck@intel.com \
--cc=vishal.l.verma@intel.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