Re: [PATCH V7 05/10] acpi: apei: handle SEA notification type for ARMv8

From: Baicar, Tyler
Date: Tue Jan 24 2017 - 13:43:49 EST

On 1/24/2017 10:55 AM, James Morse wrote:
Hi Tyler,

On 20/01/17 20:58, Baicar, Tyler wrote:
On 1/19/2017 10:57 AM, James Morse wrote:
On 18/01/17 23:51, Baicar, Tyler wrote:
On 1/18/2017 7:50 AM, James Morse wrote:
On 12/01/17 18:15, Tyler Baicar wrote:
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
There are two other things that need changing to make the in_nmi() code path
work on arm64.
Always reserve the virtual-address-space forcing GHES_IOREMAP_PAGES to be 2
regardless of CONFIG_HAVE_ACPI_APEI_NMI. This is almost revert of
594c7255dce7a13cac50cf2470cc56e2c3b0494e (but that did a few other things too).
Looks simple enough, should I force it to 2 in all cases, or add a check for
similar to the check for CONFIG_HAVE_ACPI_APEI_NMI?
Its just address space not actual memory it is reserving right? I think just
reserve two pages all the time to save eye-sore #ifdefs!

Okay, will do!
We also need to fix ghes_ioremap_pfn_nmi() to use arch_apei_get_mem_attribute()
and not assume PAGE_KERNEL.
So just change the call to ioremap_page_range to:

ioremap_page_range(vaddr, vaddr + PAGE_SIZE, pfn << PAGE_SHIFT,
(you need to give arch_apei_get_mem_attribute() the address...) copying whatever
ghes_ioremap_pfn_irq() does a few lines down is probably best.
Sounds good, I'll make the changes in my next patchset.


Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.