Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757344AbbGQJnU (ORCPT ); Fri, 17 Jul 2015 05:43:20 -0400 Received: from foss.arm.com ([217.140.101.70]:47878 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755154AbbGQJnR (ORCPT ); Fri, 17 Jul 2015 05:43:17 -0400 Date: Fri, 17 Jul 2015 10:43:14 +0100 From: Will Deacon To: "Zhang, Jonathan Zhixiong" Cc: Catalin Marinas , "fu.wei@linaro.org" , "al.stone@linaro.org" , "bp @ alien8 . de Matt Fleming" , "rjw@rjwysocki.net" , "linux-kernel@vger.kernel.org" , "linaro-acpi@lists.linaro.org" Subject: Re: [PATCH V5 3/4] arm64: apei: implement arch_apei_get_mem_attributes() Message-ID: <20150717094314.GE18994@arm.com> References: <1436920316-18127-1-git-send-email-zjzhang@codeaurora.org> <1436920316-18127-4-git-send-email-zjzhang@codeaurora.org> <20150716171853.GO26390@arm.com> <55A85C3C.9050906@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55A85C3C.9050906@codeaurora.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2418 Lines: 47 On Fri, Jul 17, 2015 at 02:37:00AM +0100, Zhang, Jonathan Zhixiong wrote: > On 7/16/2015 10:18 AM, Will Deacon wrote: > > On Wed, Jul 15, 2015 at 01:31:55AM +0100, Jonathan (Zhixiong) Zhang wrote: > >> +pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr) > >> +{ > >> + if (efi_mem_attributes(addr) & EFI_MEMORY_UC) > >> + return PROT_DEVICE_nGnRE; > >> + else > >> + return PAGE_KERNEL; > >> +} > > > > Do we really need a new file and out-of-line call for this? > We have a choice of either adding this function to > arch/arm64/kernel/acpi.c, or creating > arch/arm64/kernel/apei.c. As we continue to work on firmware first > HW error handling for arm64, more arm64 specific APEI related functions > may need to be implemented, thus I think it would be good to create > arch/arm64/kernel/apei.c. That being said, to date we have found > the needs to have only two arm64 specific APEI related functions. > The other one can be found in LEG kernel, through this commit: > aa2d69c88b27 ACPI, APEI, ARM64: APEI initial support for aarch64 > My understanding is that Linaro will work on to upstream that commit. I > do not strongly prefer either choice. > > When APEI ghes driver maps the memory region that has error record > updated by firmware, it executes in IRQ, timer or SEA handler. Since > ioremap() can not be used in atomic context, so APEI implements a > special version of atomic ioremap function calling ioremap_page_range(). > On the other hand, x86 and ARM64 have different ways to define pgprot_t > for page that needs to be accessed with uncached property. x86 defines > PAGE_KERNEL_NOCACHE, while arm64 defines PROT_DEVICE_nGnRE. Therefore > arch specific implementation is needed. > There are other ways to achieve such needs. V3 of this > patch set tried another way [1]. I think the current way makes the most > sense, since it made generic APEI code to stay generic (no knowledge > about EFI, no arch dependent ifdefs). I understand what you're doing and my concern was much simpler than you seem to imagine. Put another way: why can't arch_apei_get_mem_attribute be a static inline in a header file (like acpi_os_ioremap in asm/acpi.h)? Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/