From: Tomasz Nowicki <tomasz.nowicki@linaro.org>
To: Borislav Petkov <bp@alien8.de>
Cc: rjw@rjwysocki.net, lenb@kernel.org, tony.luck@intel.com,
m.chehab@samsung.com, bp@suse.de, linux-edac@vger.kernel.org,
x86@kernel.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, linaro-acpi@lists.linaro.org,
rric@kernel.org
Subject: Re: [PATCH v3 2/5] acpi, apei, ghes: Introduce ARCH_HAS_ACPI_APEI_NMI to make NMI error notification a GHES feature.
Date: Tue, 24 Jun 2014 11:00:52 +0200 [thread overview]
Message-ID: <53A93E44.8040303@linaro.org> (raw)
In-Reply-To: <20140619142734.GE22025@pd.tnic>
On 19.06.2014 16:27, Borislav Petkov wrote:
> On Fri, Jun 13, 2014 at 01:02:57PM +0200, Tomasz Nowicki wrote:
>> Currently APEI depends on x86 architecture. It is because of NMI hardware
>> error notification of GHES which is currently supported by x86 only.
>> However, many other APEI features can be still used perfectly by other
>> architectures.
>>
>> This commit adds ARCH_HAS_ACPI_APEI_NMI which will be used in next patches
>> for NMI related code isolation in ghes.c file. Only NMI error notification
>> feature depends on x86 so let it be hard selected for x86 arch.
>>
>> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>> ---
>> arch/x86/Kconfig | 1 +
>> drivers/acpi/apei/Kconfig | 8 +++++++-
>> 2 files changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 3fc9b12..e1dc819 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -24,6 +24,7 @@ config X86
>> select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
>> select ARCH_MIGHT_HAVE_PC_PARPORT
>> select ARCH_MIGHT_HAVE_PC_SERIO
>> + select ARCH_HAS_ACPI_APEI_NMI
>> select HAVE_AOUT if X86_32
>> select HAVE_UNSTABLE_SCHED_CLOCK
>> select ARCH_SUPPORTS_NUMA_BALANCING if X86_64
>> diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig
>> index c4dac71..9f6c3ec 100644
>> --- a/drivers/acpi/apei/Kconfig
>> +++ b/drivers/acpi/apei/Kconfig
>> @@ -3,7 +3,6 @@ config ACPI_APEI
>> select MISC_FILESYSTEMS
>> select PSTORE
>> select UEFI_CPER
>> - depends on X86
>
> Now this can practically be enabled on any architecture, AFAICT. Which
> is wrong.
>
> I think a better solution would be to have another HAVE_ symbol which
> each arch which sports APEI selects. Like in the diff below ontop of
> this patch, also incorporating Robert's comments.
>
> You'll have to do select HAVE_ACPI_APEI on arm too.
>
> Hmm?
>
Now that it turns out we have to provide at least tlb_flush_... arch
function, APEI can not be selected by any architecture. So you are right
I will introduce HAVE_ACPI_APEI in next version of patches. Thanks.
Tomasz
next prev parent reply other threads:[~2014-06-24 9:00 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-13 11:02 [PATCH v3 0/5] APEI: Make APEI architecture independent Tomasz Nowicki
2014-06-13 11:02 ` [PATCH v3 1/5] apei, mce: Factor out APEI architecture specific MCE calls Tomasz Nowicki
2014-06-13 13:54 ` Robert Richter
2014-06-19 14:17 ` Borislav Petkov
2014-06-24 9:01 ` Tomasz Nowicki
2014-06-13 11:02 ` [PATCH v3 2/5] acpi, apei, ghes: Introduce ARCH_HAS_ACPI_APEI_NMI to make NMI error notification a GHES feature Tomasz Nowicki
2014-06-13 14:01 ` Robert Richter
2014-06-19 14:27 ` Borislav Petkov
2014-06-24 9:00 ` Tomasz Nowicki [this message]
2014-06-13 11:02 ` [PATCH v3 3/5] acpi, apei, ghes: Introduce more generic mechanism to init/deinit GHES error notifications Tomasz Nowicki
2014-06-13 13:10 ` Robert Richter
2014-06-19 14:28 ` Borislav Petkov
2014-06-24 9:06 ` Tomasz Nowicki
2014-06-13 11:02 ` [PATCH v3 4/5] apei, ghes, nmi: Factor out NMI arch-specific calls Tomasz Nowicki
2014-06-13 13:29 ` Robert Richter
2014-06-13 11:03 ` [PATCH v3 5/5] acpi, apei, ghes: Factor out ioremap virtual memory for IRQ and NMI context Tomasz Nowicki
2014-06-13 13:35 ` Robert Richter
2014-06-13 13:14 ` [PATCH v3 0/5] APEI: Make APEI architecture independent Robert Richter
2014-06-13 13:20 ` Borislav Petkov
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=53A93E44.8040303@linaro.org \
--to=tomasz.nowicki@linaro.org \
--cc=bp@alien8.de \
--cc=bp@suse.de \
--cc=lenb@kernel.org \
--cc=linaro-acpi@lists.linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.chehab@samsung.com \
--cc=rjw@rjwysocki.net \
--cc=rric@kernel.org \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.