Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754859AbbGTSW4 (ORCPT ); Mon, 20 Jul 2015 14:22:56 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:52517 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753470AbbGTSWy (ORCPT ); Mon, 20 Jul 2015 14:22:54 -0400 Subject: Re: [PATCH V5 3/4] arm64: apei: implement arch_apei_get_mem_attributes() To: Will Deacon 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> <20150717094314.GE18994@arm.com> 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" From: "Zhang, Jonathan Zhixiong" Message-ID: <55AD3C7C.2010906@codeaurora.org> Date: Mon, 20 Jul 2015 11:22:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150717094314.GE18994@arm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2698 Lines: 57 Thanks for the clarification, Will. On 7/17/2015 2:43 AM, Will Deacon wrote: > 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)? Great. Will do. > > Will > -- Jonathan (Zhixiong) Zhang The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- 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/