linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Avadhut Naik <avadnaik@amd.com>
To: Alexey Kardashevskiy <aik@amd.com>,
	Yazen Ghannam <yazen.ghannam@amd.com>,
	Avadhut Naik <Avadhut.Naik@amd.com>,
	rafael@kernel.org, gregkh@linuxfoundation.org, lenb@kernel.org,
	linux-acpi@vger.kernel.org, linux-fsdevel@vger.kernel.org
Cc: alexey.kardashevskiy@amd.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 1/3] ACPI: APEI: EINJ: Refactor available_error_type_show()
Date: Thu, 8 Jun 2023 16:08:29 -0500	[thread overview]
Message-ID: <2ed4a89d-e729-6e3c-8514-f33fb0a8c207@amd.com> (raw)
In-Reply-To: <aeecb9a0-b3b2-cfa2-e5b7-a64d1ffe1c0c@amd.com>

Hi,
	Thanks for reviewing.

On 6/7/2023 22:48, Alexey Kardashevskiy wrote:
> 
> 
> On 8/6/23 00:20, Yazen Ghannam wrote:
>> On 5/25/23 4:44 PM, Avadhut Naik wrote:
>>> OSPM can discover the error injection capabilities of the platform by
>>> executing GET_ERROR_TYPE error injection action.[1] The action returns
>>> a DWORD representing a bitmap of platform supported error injections.[2]
>>>
>>> The available_error_type_show() function determines the bits set within
>>> this DWORD and provides a verbose output, from einj_error_type_string
>>> array, through /sys/kernel/debug/apei/einj/available_error_type file.
>>>
>>> The function however, assumes one to one correspondence between an error's
>>> position in the bitmap and its array entry offset. Consequently, some
>>> errors like Vendor Defined Error Type fail this assumption and will
>>> incorrectly be shown as not supported, even if their corresponding bit is
>>> set in the bitmap and they have an entry in the array.
>>>
>>> Navigate around the issue by converting einj_error_type_string into an
>>> array of structures with a predetermined mask for all error types
>>> corresponding to their bit position in the DWORD returned by GET_ERROR_TYPE
>>> action. The same breaks the aforementioned assumption resulting in all
>>> supported error types by a platform being outputted through the above
>>> available_error_type file.
>>>
>>> [1] ACPI specification 6.5, Table 18.25
>>> [2] ACPI specification 6.5, Table 18.30
>>>
>>> Suggested-by: Alexey Kardashevskiy <alexey.kardashevskiy@amd.com>
>>> Signed-off-by: Avadhut Naik <Avadhut.Naik@amd.com>
>>> ---
>>>   drivers/acpi/apei/einj.c | 43 ++++++++++++++++++++--------------------
>>>   1 file changed, 22 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/drivers/acpi/apei/einj.c b/drivers/acpi/apei/einj.c
>>> index 013eb621dc92..d5f8dc4df7a5 100644
>>> --- a/drivers/acpi/apei/einj.c
>>> +++ b/drivers/acpi/apei/einj.c
>>> @@ -577,25 +577,25 @@ static u64 error_param2;
>>>   static u64 error_param3;
>>>   static u64 error_param4;
>>>   static struct dentry *einj_debug_dir;
>>> -static const char * const einj_error_type_string[] = {
>>> -    "0x00000001\tProcessor Correctable\n",
>>> -    "0x00000002\tProcessor Uncorrectable non-fatal\n",
>>> -    "0x00000004\tProcessor Uncorrectable fatal\n",
>>> -    "0x00000008\tMemory Correctable\n",
>>> -    "0x00000010\tMemory Uncorrectable non-fatal\n",
>>> -    "0x00000020\tMemory Uncorrectable fatal\n",
>>> -    "0x00000040\tPCI Express Correctable\n",
>>> -    "0x00000080\tPCI Express Uncorrectable non-fatal\n",
>>> -    "0x00000100\tPCI Express Uncorrectable fatal\n",
>>> -    "0x00000200\tPlatform Correctable\n",
>>> -    "0x00000400\tPlatform Uncorrectable non-fatal\n",
>>> -    "0x00000800\tPlatform Uncorrectable fatal\n",
>>> -    "0x00001000\tCXL.cache Protocol Correctable\n",
>>> -    "0x00002000\tCXL.cache Protocol Uncorrectable non-fatal\n",
>>> -    "0x00004000\tCXL.cache Protocol Uncorrectable fatal\n",
>>> -    "0x00008000\tCXL.mem Protocol Correctable\n",
>>> -    "0x00010000\tCXL.mem Protocol Uncorrectable non-fatal\n",
>>> -    "0x00020000\tCXL.mem Protocol Uncorrectable fatal\n",
>>> +static struct { u32 mask; const char *str; } const einj_error_type_string[] = {
>>> +    {0x00000001, "Processor Correctable"},
>>> +    {0x00000002, "Processor Uncorrectable non-fatal"},
>>> +    {0x00000004, "Processor Uncorrectable fatal"},
>>> +    {0x00000008, "Memory Correctable"},
>>> +    {0x00000010, "Memory Uncorrectable non-fatal"},
>>> +    {0x00000020, "Memory Uncorrectable fatal"},
>>> +    {0x00000040, "PCI Express Correctable"},
>>> +    {0x00000080, "PCI Express Uncorrectable non-fatal"},
>>> +    {0x00000100, "PCI Express Uncorrectable fatal"},
>>> +    {0x00000200, "Platform Correctable"},
>>> +    {0x00000400, "Platform Uncorrectable non-fatal"},
>>> +    {0x00000800, "Platform Uncorrectable fatal"},
>>> +    {0x00001000, "CXL.cache Protocol Correctable"},
>>> +    {0x00002000, "CXL.cache Protocol Uncorrectable non-fatal"},
>>> +    {0x00004000, "CXL.cache Protocol Uncorrectable fatal"},
>>> +    {0x00008000, "CXL.mem Protocol Correctable"},
>>> +    {0x00010000, "CXL.mem Protocol Uncorrectable non-fatal"},
>>> +    {0x00020000, "CXL.mem Protocol Uncorrectable fatal"},
>>>   };
>>>
>>
>> I think it'd be easier to read if the masks used the BIT() macro rather
>> than a hex value.
> 
> Makes sense but I'd say because it is easier to match the APCI spec which uses the bit numbers, not easier to read (which is arguable).
> 
	Agreed, will replace the hex values with BIT() macro.

Thanks,
Avadhut Naik
> 
>>
>> Thanks,
>> Yazen
> 

-- 

  reply	other threads:[~2023-06-08 21:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-25 20:44 [RFC PATCH v2 0/3] Add support for Vendor Defined Error Types in Einj Module Avadhut Naik
2023-05-25 20:44 ` [RFC PATCH v2 1/3] ACPI: APEI: EINJ: Refactor available_error_type_show() Avadhut Naik
2023-06-07 14:20   ` Yazen Ghannam
2023-06-08  3:48     ` Alexey Kardashevskiy
2023-06-08 21:08       ` Avadhut Naik [this message]
2023-05-25 20:44 ` [RFC PATCH v2 2/3] fs: debugfs: Add write functionality to debugfs blobs Avadhut Naik
2023-06-08  4:02   ` Alexey Kardashevskiy
2023-05-25 20:44 ` [RFC PATCH v2 3/3] ACPI: APEI: EINJ: Add support for vendor defined error types Avadhut Naik
2023-06-08  4:44   ` Alexey Kardashevskiy
2023-06-08 21:18     ` Avadhut Naik

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=2ed4a89d-e729-6e3c-8514-f33fb0a8c207@amd.com \
    --to=avadnaik@amd.com \
    --cc=Avadhut.Naik@amd.com \
    --cc=aik@amd.com \
    --cc=alexey.kardashevskiy@amd.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).