From: Dave Jiang <dave.jiang@intel.com>
To: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>,
linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-cxl@vger.kernel.org
Cc: Ard Biesheuvel <ardb@kernel.org>,
Alison Schofield <alison.schofield@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Ira Weiny <ira.weiny@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Yazen Ghannam <yazen.ghannam@amd.com>,
Bowman Terry <terry.bowman@amd.com>
Subject: Re: [PATCH 2/4] acpi/ghes, efi/cper: Recognize and process CXL Protocol Errors.
Date: Thu, 23 May 2024 15:51:41 -0700 [thread overview]
Message-ID: <cf799922-d5f5-4f8d-96ef-5a526d5ae643@intel.com> (raw)
In-Reply-To: <08dc0027-371c-5783-fd65-ad6f8b228fee@amd.com>
On 5/23/24 2:19 PM, Smita Koralahalli wrote:
> Hi Dave,
>
> On 5/22/2024 10:59 AM, Dave Jiang wrote:
>>
>>
>> On 5/22/24 8:08 AM, Smita Koralahalli wrote:
>>> UEFI v2.10 section N.2.13 defines a CPER record for CXL Protocol errors.
>>>
>>> Add GHES support to detect CXL CPER Protocol Error Record and Cache Error
>>> Severity, Device ID, Device Serial number and CXL RAS capability struct in
>>> struct cxl_cper_prot_err. Include this struct as a member of struct
>>> cxl_cper_work_data.
>>>
>>> Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
>>> ---
>>> drivers/acpi/apei/ghes.c | 10 +++++
>>> drivers/firmware/efi/cper_cxl.c | 66 +++++++++++++++++++++++++++++++++
>>> include/linux/cxl-event.h | 26 +++++++++++++
>>> 3 files changed, 102 insertions(+)
>>>
>
> [snip]
>
>
>>> + * The device ID or agent address is required for CXL RCD, CXL
>>> + * SLD, CXL LD, CXL Fabric Manager Managed LD, CXL Root Port,
>>> + * CXL Downstream Switch Port and CXL Upstream Switch Port.
>>> + */
>>> + if (prot_err->agent_type <= 0x7 && prot_err->agent_type != RCH_DP) {
>>
>> Perhaps define an enum CXL_AGENT_TYPE_MAX instead of 0x7 magic number? Otherwise if a new type is introduced, it would break this code.
>
> Agreed. I will define a boolean array indexed by agent type as suggested by Alison. That would avoid all these comparisons and not worry about breaking code in future.
>
>>
>>> + p_err->segment = prot_err->agent_addr.segment;
>>> + p_err->bus = prot_err->agent_addr.bus;
>>> + p_err->device = prot_err->agent_addr.device;
>>> + p_err->function = prot_err->agent_addr.function;
>>> + } else {
>>> + pr_err(FW_WARN "Invalid agent type\n");
>>> + return -EINVAL;
>>> + }
>>
>> Up to you if you want to do this or not, but maybe:
>>
>> if (prot_err->agent_type >= CXL_AGENT_TYPE_MAX || prot_err->agent_type == RCH_DP) {
>> pr_warn(...);
>> return -EINVAL;
>> }
>>
>> p_err->segment = ...;
>> p_err->bus = ...;
>
> Noted.
>
>> ...
>>
>> Although perhaps a helper function cxl_cper_valid_agent_type() that checks invalid agent type by checking the valid_bits, the agent_type boundary, and if agent_type != RCH_DP?
>
> Okay.
>
>>> +
>>> + if (!(prot_err->valid_bits & PROT_ERR_VALID_ERROR_LOG)) {
>>> + pr_err(FW_WARN "Invalid Protocol Error log\n");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + dvsec_start = (u8 *)(prot_err + 1);
>>> + cap_start = dvsec_start + prot_err->dvsec_len;
>>> + p_err->cxl_ras = *(struct cxl_ras_capability_regs *)cap_start;
>>> +
>>> + /*
>>> + * Set device serial number unconditionally.
>>> + *
>>> + * Print a warning message if it is not valid. The device serial
>>> + * number is required for CXL RCD, CXL SLD, CXL LD and CXL Fabric
>>> + * Manager Managed LD.
>>> + */
>>> + if (!(prot_err->valid_bits & PROT_ERR_VALID_SERIAL_NUMBER) ||
>>> + prot_err->agent_type > 0x4 || prot_err->agent_type == RCH_DP)
>>
>> prot_err->agent_type > FM_LD? Although maybe it would be a clearer read if a helper function is defined to identify the agent types such as cxl_cper_prot_err_serial_needed() or cxl_cper_prot_agent_type_device() and with it a switch statement to explicitly identify all the agent types that require serial number. If a future device is defined, the > 0x4 logic may break.
>
> Probably helper function is not required if boolean array is defined? What do you think?
That works for me. My main concern is to clarify the code and remove possibility of breakage from future changes.
>
> Thanks,
> Smita
>
> [snip]
next prev parent reply other threads:[~2024-05-23 22:51 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-22 15:08 [PATCH 0/4] acpi/ghes, cper, cxl: Trace FW-First CXL Protocol Errors Smita Koralahalli
2024-05-22 15:08 ` [PATCH 1/4] efi/cper, cxl: Make definitions and structures global Smita Koralahalli
2024-05-22 17:28 ` Dave Jiang
2024-05-22 23:40 ` Alison Schofield
2024-06-07 15:14 ` Jonathan Cameron
2024-06-10 18:31 ` Smita Koralahalli
2024-05-22 15:08 ` [PATCH 2/4] acpi/ghes, efi/cper: Recognize and process CXL Protocol Errors Smita Koralahalli
2024-05-22 17:59 ` Dave Jiang
2024-05-23 21:19 ` Smita Koralahalli
2024-05-23 22:51 ` Dave Jiang [this message]
2024-05-23 0:03 ` Alison Schofield
2024-05-23 21:21 ` Smita Koralahalli
2024-06-07 15:26 ` Jonathan Cameron
2024-06-10 19:07 ` Smita Koralahalli
2024-05-22 15:08 ` [PATCH 3/4] acpi/ghes, cxl/pci: Trace FW-First " Smita Koralahalli
2024-05-22 18:05 ` Dave Jiang
2024-05-23 4:38 ` Alison Schofield
2024-05-23 21:23 ` Smita Koralahalli
2024-05-23 0:22 ` Alison Schofield
2024-05-23 21:35 ` Smita Koralahalli
2024-06-12 0:07 ` Dan Williams
2024-06-13 17:47 ` Smita Koralahalli
2024-06-24 22:04 ` Smita Koralahalli
2024-05-22 15:08 ` [PATCH 4/4] cxl/pci: Define a common function get_cxl_dev() Smita Koralahalli
2024-05-22 19:42 ` Dave Jiang
2024-05-23 21:37 ` Smita Koralahalli
2024-05-23 0:45 ` Alison Schofield
2024-06-07 15:40 ` 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=cf799922-d5f5-4f8d-96ef-5a526d5ae643@intel.com \
--to=dave.jiang@intel.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=Smita.KoralahalliChannabasappa@amd.com \
--cc=alison.schofield@intel.com \
--cc=ardb@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=terry.bowman@amd.com \
--cc=vishal.l.verma@intel.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