linux-edac.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
To: Smita Koralahalli Channabasappa <skoralah@amd.com>
Cc: <x86@kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-pm@vger.kernel.org>, <linux-edac@vger.kernel.org>,
	<linux-efi@vger.kernel.org>, <linux-acpi@vger.kernel.org>,
	<devel@acpica.org>, Borislav Petkov <bp@alien8.de>,
	Tony Luck <tony.luck@intel.com>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Len Brown <len.brown@intel.com>, Ard Biesheuvel <ardb@kernel.org>,
	Yazen Ghannam <yazen.ghannam@amd.com>
Subject: Re: [PATCH v2 1/2] cper, apei, mce: Pass x86 CPER through the MCA handling chain
Date: Thu, 03 Sep 2020 15:33:47 +0900	[thread overview]
Message-ID: <87a6y7qshg.fsf@kokedama.swc.toshiba.co.jp> (raw)
In-Reply-To: <102d0c75-d642-8f8b-68c7-792499c2a62a@amd.com> (Smita Koralahalli Channabasappa's message of "Wed, 2 Sep 2020 14:29:28 -0500")

Hi Smita,

Smita Koralahalli Channabasappa <skoralah@amd.com> writes:

> On 8/31/20 12:05 AM, Punit Agrawal wrote:
>
>> Hi Smita,
>>
>> A couple of comments below -
>>
>> Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com> writes:
>>
>> [...]
>>
>>
>>> diff --git a/drivers/firmware/efi/cper-x86.c b/drivers/firmware/efi/cper-x86.c
>>> index 2531de49f56c..374b8e18552a 100644
>>> --- a/drivers/firmware/efi/cper-x86.c
>>> +++ b/drivers/firmware/efi/cper-x86.c
>>> @@ -1,7 +1,7 @@
>>>   // SPDX-License-Identifier: GPL-2.0
>>>   // Copyright (C) 2018, Advanced Micro Devices, Inc.
>>>   -#include <linux/cper.h>
>> Why is the include dropped? AFAICT, the definitions from there are still
>> being used after this patch.
>
> Dropped because <acpi/apei.h> already includes <linux/cper.h>

Generally, you want to follow the rule that if a declaration from a
header file is being used, it should show up in the includes. The same
applies to both source as well as header files.

It doesn't matter if another include in the source file in turn ends up
including the same header again; the #ifdef guards are there to prevent
duplicate declarations.

The rationale is that if future changes remove the usage of
<acpi/apei.h>, the C file can still be compiled after dropping the
include; there should be no need to then re-introduce <linux/cper.h> at
that point.

Hope that makes sense.

Thanks,
Punit

>>> +#include <acpi/apei.h>
>
> [...]
>
>>> diff --git a/include/acpi/apei.h b/include/acpi/apei.h
>>> index 680f80960c3d..44d4d08acce0 100644
>>> --- a/include/acpi/apei.h
>>> +++ b/include/acpi/apei.h
>>> @@ -33,8 +33,15 @@ extern bool ghes_disable;
>>>     #ifdef CONFIG_ACPI_APEI
>>>   void __init acpi_hest_init(void);
>>> +int arch_apei_report_x86_error(struct cper_ia_proc_ctx *ctx_info,
>>> +			       u64 lapic_id);
>>>   #else
>>>   static inline void acpi_hest_init(void) { return; }
>>> +static inline int arch_apei_report_x86_error(struct cper_ia_proc_ctx *ctx_info,
>>> +					     u64 lapic_id)
>>> +{
>>> +	return -EINVAL;
>>> +}
>>>   #endif
>> Adding the declaration to this include violates the separation of
>> generic and architecture specific code.
>>
>> Can this be moved to the appropriate architecture specific header?
>> Perhaps arch/x86/include/asm/apei.h.
>
> Yes, I have fixed this and moved into arch/x86/include/asm/acpi.h.
>
>>>   typedef int (*apei_hest_func_t)(struct acpi_hest_header *hest_hdr, void *data);
>>> @@ -51,6 +58,8 @@ int erst_clear(u64 record_id);
>>>     int arch_apei_enable_cmcff(struct acpi_hest_header *hest_hdr,
>>> void *data);
>>>   void arch_apei_report_mem_error(int sev, struct cper_sec_mem_err *mem_err);
>>> +int arch_apei_report_x86_error(struct cper_ia_proc_ctx *ctx_info,
>>> +			       u64 lapic_id);
>>
>> Why is the additional declaration needed?
>
> Will fix in the next revision.
>
> Thanks,
> Smita
>
> [...]

  reply	other threads:[~2020-09-03  6:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-28 20:33 [PATCH v2 0/2] Decode raw MSR values of MCA registers in BERT Smita Koralahalli
2020-08-28 20:33 ` [PATCH v2 1/2] cper, apei, mce: Pass x86 CPER through the MCA handling chain Smita Koralahalli
2020-08-31  5:05   ` Punit Agrawal
2020-09-02 19:29     ` Smita Koralahalli Channabasappa
2020-09-03  6:33       ` Punit Agrawal [this message]
2020-09-11 18:23         ` Ard Biesheuvel
2020-09-11 21:26           ` Smita Koralahalli Channabasappa
2020-09-01 19:36   ` Yazen Ghannam
2020-08-28 20:33 ` [PATCH v2 2/2] x86/mce/dev-mcelog: Fix updating kflags in AMD systems Smita Koralahalli

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=87a6y7qshg.fsf@kokedama.swc.toshiba.co.jp \
    --to=punit1.agrawal@toshiba.co.jp \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=devel@acpica.org \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=skoralah@amd.com \
    --cc=tony.luck@intel.com \
    --cc=x86@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).