linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Tomasz Nowicki <tomasz.nowicki@linaro.org>
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: Thu, 19 Jun 2014 16:27:35 +0200	[thread overview]
Message-ID: <20140619142734.GE22025@pd.tnic> (raw)
In-Reply-To: <1402657380-18539-3-git-send-email-tomasz.nowicki@linaro.org>

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?

--
Index: b/arch/x86/Kconfig
===================================================================
--- a/arch/x86/Kconfig	2014-06-19 16:25:48.118452980 +0200
+++ b/arch/x86/Kconfig	2014-06-19 16:24:57.270453451 +0200
@@ -24,7 +24,6 @@ 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
@@ -132,6 +131,8 @@ config X86
 	select HAVE_CC_STACKPROTECTOR
 	select GENERIC_CPU_AUTOPROBE
 	select HAVE_ARCH_AUDITSYSCALL
+	select HAVE_ACPI_APEI
+	select HAVE_ACPI_APEI_NMI
 
 config INSTRUCTION_DECODER
 	def_bool y
Index: b/drivers/acpi/apei/Kconfig
===================================================================
--- a/drivers/acpi/apei/Kconfig	2014-06-19 16:25:48.118452980 +0200
+++ b/drivers/acpi/apei/Kconfig	2014-06-19 16:24:32.710453679 +0200
@@ -1,8 +1,15 @@
+config HAVE_ACPI_APEI
+	bool
+
+config HAVE_ACPI_APEI_NMI
+	bool
+
 config ACPI_APEI
 	bool "ACPI Platform Error Interface (APEI)"
 	select MISC_FILESYSTEMS
 	select PSTORE
 	select UEFI_CPER
+	depends on HAVE_ACPI_APEI
 	help
 	  APEI allows to report errors (for example from the chipset)
 	  to the operating system. This improves NMI handling
@@ -25,12 +32,6 @@ config ACPI_APEI_GHES
 	  by firmware to produce more valuable hardware error
 	  information for Linux.
 
-config ARCH_HAS_ACPI_APEI_NMI
-	bool
-	help
-	  Firmware first mode can use NMI notification mechanism to report errors
-	  to operating system. This feature is currently supported by X86
-	  architecture only.
 
 config ACPI_APEI_PCIEAER
 	bool "APEI PCIe AER logging/recovering support"


-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

  parent reply	other threads:[~2014-06-19 14:27 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 [this message]
2014-06-24  9:00     ` Tomasz Nowicki
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=20140619142734.GE22025@pd.tnic \
    --to=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=tomasz.nowicki@linaro.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 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).