On 13.05.2014 21:41, Borislav Petkov wrote:
On Wed, Apr 09, 2014 at 05:14:32PM +0200, Tomasz Nowicki wrote:
Use CONFIG_ACPI_APEI_NMI to isolate NMI error notification path. NMI related
data and functions are grouped so they can be wrapped inside one
I have missed end of sentence. I should goes like that:
Use CONFIG_ACPI_APEI_NMI to isolate NMI error notification path. NMI
related data and functions are grouped so they can be wrapped inside one
#ifdefs CONFIG_ACPI_APEI_NMI.
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@xxxxxxxxxx>
---
drivers/acpi/apei/ghes.c | 54 +++++++++++++++++++++++++---------------------
1 file changed, 30 insertions(+), 24 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index ca8387e..7a0d66e 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -53,7 +53,9 @@
#include <asm/mce.h>
#endif
#include <asm/tlbflush.h>
+#ifdef CONFIG_ACPI_APEI_NMI
#include <asm/nmi.h>
+#endif
This, again, can be avoided with adding arch-specific versions and empty
default stubs.
I had that thoughts too. Looking at simple MCE calls, yes, it does make
sense to create corresponding arch-specific version and provide logic as
needed. I think that NMI is much more complicated. NMI context is
tightly coupled with the rest of GHES mechanisms like pool memory, list
locks etc. which are GHES locally available. I am not saying it is
impossible, I am just concerned if it makes sense to create e.g.
apei-nmi.c arch-specific file and export necessary GHES mechanisms just
for NMI purpose. Please let me know your opinion on this.
Regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
