Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <37f64467-c9d7-826d-de41-aa571b2df0ec@amd.com>
Date:   Wed, 7 Jun 2023 10:20:07 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cc:     yazen.ghannam@amd.com, avadnaik@amd.com,
        alexey.kardashevskiy@amd.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 1/3] ACPI: APEI: EINJ: Refactor
 available_error_type_show()
Content-Language: en-US
To:     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
References: <20230525204422.4754-1-Avadhut.Naik@amd.com>
 <20230525204422.4754-2-Avadhut.Naik@amd.com>
From:   Yazen Ghannam <yazen.ghannam@amd.com>
In-Reply-To: <20230525204422.4754-2-Avadhut.Naik@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TktJeEtTczBvQ1dyT0haTHlRd2p3emNwK3YrQXloZW02NHZ6RTI4TWhCZzdF?=
 =?utf-8?B?NjBpemU1akdRTG9CTm1oZlc3Q1dSMWpvTGxVcnA1S1JueFVUbmNaOWxzMnVa?=
 =?utf-8?B?aXUvZEN2TXVPeDcrNXJpZTJhMkdxSzFmVm9MaE1ybmVObVRCdkxQaUNXQVp4?=
 =?utf-8?B?NVZYelFyMjRoZlBoV0ZMNys0NW5yTlpwNjhJYVFvWWo5N0FRMEl6K3NldHBj?=
 =?utf-8?B?M05oSmRBNGlBSUh3UkdTZVk2QXJRdUFBVUVMVkVBZnJNKzB3MDlZQmRHNDQ3?=
 =?utf-8?B?L0NkZlVmSVgya3JGbWN3ZVZFS2l2WkVDcjdzNkErS0RLUGwzUHB4Z3NuNVdT?=
 =?utf-8?B?LzIwK0hJY0YwMjdOdmtDL0luc0RMWFBHd2Z6OTEzeXYrWHoySlNMS1I4RmVB?=
 =?utf-8?B?TmVJNnhUYzE5T04vNFZzbUxESURQMTNIZzVSU2o2RURlR2tSTUo5dmZMSVdV?=
 =?utf-8?B?R2p2VjBDZWMvWnA2QkpDQWVveDJQdVBOVS9ZenkvaHVYbzBKZlJTWmRWbFZB?=
 =?utf-8?B?V0F6S3I2R1dZMmxoVzhOZE1tTlMvVi83QnFITUtsN1hCbGhUYU9SUHhHOE5R?=
 =?utf-8?B?SkdUNUhweGhXdWFjVjhYQjVtQXZWWVFuV2FvUWNWaUNMT29VYUwxZm83NnI0?=
 =?utf-8?B?OVhSU1QzS2lkWFJVaDNTenZOUmttQm5mR09Yb0ExSlBha2dYODd3a3IzMXQ4?=
 =?utf-8?B?ZzZoVHRuZGxCUXlnSmxoZGJHSW55K2JVZTIyZGwrcFFqbmZ2U2Q2TjBCTU4r?=
 =?utf-8?B?bzNaM3ZUWVF6MHNqeW5KMHo3L1lzWTExc2hFSVI1MkVrQWRIL3RJV1lRNmJT?=
 =?utf-8?B?UkZERHd6S2g3ZkFmYWh5L01qMEpzRnRTMTJSRnBqTWVGZVRZQU0zdUdyK3Fy?=
 =?utf-8?B?V2lQMGxQSWh5MXlQREExS3IzSzFSdVBxUGJja1liQ0dDU0NDV3ljTU5QdzQy?=
 =?utf-8?B?bUlyeHNsR0o5TEZ6TnBJQXphUG9uS3pKd2VDQllHSjkrY04rbHVnVEk1ZGJx?=
 =?utf-8?B?VlhBbDY5Nng3VitQRXRMbXhWZjYvV3NBVnRCcjZaV3FHay83aEk5YjJoWkJW?=
 =?utf-8?B?Z1E2SUFBMVRFUGxWYlNLQVJ6c1RBVUtlTE1vc3FISnE3NllycTlOcXJUcTZ2?=
 =?utf-8?B?TXMzeDJkVjhyUE4vZ3crSXlDckZCYXl1NFRaeVVyOVJHVjZMcHplYkpDSm9w?=
 =?utf-8?B?YkNFYXZEek1QbFpSbVVlUjhCYzJ6TEFFbHk5cFBNQzZSS1p4eWI3RXJyNnJF?=
 =?utf-8?B?c1FHVU9PUThtamE0WDE4SmRWcXNmZFlVUkg3Tk9DdkZzeUlxa1RHeXhFb1o2?=
 =?utf-8?B?Ykk4SEJxRUdXR241YmE4YmFocll5WFhBMG5NSXFXVDlMTXI0RlZaaHlRRXdo?=
 =?utf-8?B?L01aZGdZZnNweWJFeittL1kwWHNONnErNjhZblA5bll3K2ZzbjhrOVBNS0xx?=
 =?utf-8?B?NEdxVUxiNVVJVzFBSHR2MzhzNmNheWVoY1hxUVNsQnpEd3gxRTM2M04xTWJE?=
 =?utf-8?B?RWFxN0g3anU4azdKQURJQkNTcmVqVWdpcnRBSzZEUzhoVEtwME5kSUdWbE91?=
 =?utf-8?B?emRBVi81OEV5RWdoYkFNRldETytVWlFCZFZxdUVYQXB5c0dnT1JpOXV2VS9s?=
 =?utf-8?B?SlZxOXF5R01oVnVZZjhtY09OSkFBd1ROWHVTU0Npc080QnpENEpRWEVZaXBR?=
 =?utf-8?B?OUFtenFRS0tBd28ydnhFaDV2T2JEbHp6TUZ5d0piNXBuSGYzOGdOalRsWWxy?=
 =?utf-8?B?M1FWamVlbytGcmJLcndJQ3l6eXAxbjBQQWsvR0ZzaFlCR3NFR0kva0tiZHhJ?=
 =?utf-8?B?dWsyVFpIYkR0ZXlQUXJSeTBzZ0JBc1ZQVzVKeEMrNDBqdkxzalNqeG1QMHN4?=
 =?utf-8?B?MWthQzliTkJhaEsrb3huOG11Um5pSkpTaGFwMXFWV2QvTHA2MUlBblZIeUxX?=
 =?utf-8?B?eGEyNDJMbWlpLzd5K1RZUHo5V1JodHg3dWc0Ukd5clRqditGYlAxVm9tanE3?=
 =?utf-8?B?Uzc4c1dRMklrZ2U1bTdPbk1ST2VXbVFCR1o3YjJQSDlQUjNNVFVWK0daTFYx?=
 =?utf-8?B?bU5kL1cyZVArSkwrcDgyWUd5VVZuL1p5Sy9xbGEybE1XMFo2aEZBZkd1aFE5?=
 =?utf-8?Q?PVe0sbBWqrEStL24XbbZgMvl0?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cf4f0f13-97ec-418b-de9d-08db67624d3e
X-MS-Exchange-CrossTenant-AuthSource: BN8PR12MB3108.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jun 2023 14:20:10.4844
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: yNHuhe0QhnlqJcNKsUvZTxs3kLHf/S35QrPAOFig0mtiDRYU6vTcc+tISoHvaIWfKMd8cXf8VkRbL4VmT+7c0A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB8161
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,NICE_REPLY_A,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,
        T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=no autolearn_force=no
        version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.

Thanks,
Yazen