Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759236AbbFBNg6 (ORCPT ); Tue, 2 Jun 2015 09:36:58 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:34128 "EHLO mail-wi0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759176AbbFBNgv (ORCPT ); Tue, 2 Jun 2015 09:36:51 -0400 Date: Tue, 2 Jun 2015 14:36:47 +0100 From: Matt Fleming To: "Jonathan (Zhixiong) Zhang" Cc: Matt Fleming , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, leif.lindholm@linaro.org, al.stone@linaro.org, fu.wei@linaro.org, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linaro-acpi@lists.linaro.org, vgandhi@codeaurora.org, Tony Luck Subject: Re: [PATCH V2 1/3] efi: arch, x86: arch, ia64: move efi_mem_attributes() Message-ID: <20150602133647.GC6826@codeblueprint.co.uk> References: <1433185940-24770-1-git-send-email-zjzhang@codeaurora.org> <1433185940-24770-2-git-send-email-zjzhang@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1433185940-24770-2-git-send-email-zjzhang@codeaurora.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2990 Lines: 98 (Cc'ing Tony for ia64 input) On Mon, 01 Jun, at 12:12:18PM, Jonathan (Zhixiong) Zhang wrote: > From: "Jonathan (Zhixiong) Zhang" > > Both x86 and ia64 implemented efi_mem_attributs(), which is architecture > agnositc. This function is moved from arch/x86 and arch/ia64 to > drivers/firmware/efi. > > Signed-off-by: Jonathan (Zhixiong) Zhang > --- > arch/ia64/kernel/efi.c | 11 ----------- > arch/x86/platform/efi/efi.c | 18 ------------------ > drivers/firmware/efi/efi.c | 18 ++++++++++++++++++ > 3 files changed, 18 insertions(+), 29 deletions(-) > > diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c > index c52d7540dc05..ef20ec784b04 100644 > --- a/arch/ia64/kernel/efi.c > +++ b/arch/ia64/kernel/efi.c > @@ -771,17 +771,6 @@ efi_mem_type (unsigned long phys_addr) > } > > u64 > -efi_mem_attributes (unsigned long phys_addr) > -{ > - efi_memory_desc_t *md = efi_memory_descriptor(phys_addr); > - > - if (md) > - return md->attribute; > - return 0; > -} > -EXPORT_SYMBOL(efi_mem_attributes); > - > -u64 > efi_mem_attribute (unsigned long phys_addr, unsigned long size) > { > unsigned long end = phys_addr + size; > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c > index 02744df576d5..10bd5289c593 100644 > --- a/arch/x86/platform/efi/efi.c > +++ b/arch/x86/platform/efi/efi.c > @@ -926,24 +926,6 @@ u32 efi_mem_type(unsigned long phys_addr) > return 0; > } > > -u64 efi_mem_attributes(unsigned long phys_addr) > -{ > - efi_memory_desc_t *md; > - void *p; > - > - if (!efi_enabled(EFI_MEMMAP)) > - return 0; > - > - for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) { > - md = p; > - if ((md->phys_addr <= phys_addr) && > - (phys_addr < (md->phys_addr + > - (md->num_pages << EFI_PAGE_SHIFT)))) > - return md->attribute; > - } > - return 0; > -} > - > static int __init arch_parse_efi_cmdline(char *str) > { > if (parse_option_str(str, "old_map")) > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c > index 3061bb8629dc..86da85368778 100644 > --- a/drivers/firmware/efi/efi.c > +++ b/drivers/firmware/efi/efi.c > @@ -517,3 +517,21 @@ char * __init efi_md_typeattr_format(char *buf, size_t size, > attr & EFI_MEMORY_UC ? "UC" : ""); > return buf; > } > + > +u64 efi_mem_attributes(unsigned long phys_addr) > +{ > + efi_memory_desc_t *md; > + void *p; > + > + if (!efi_enabled(EFI_MEMMAP)) > + return 0; > + Umm... ia64 doesn't appear to set EFI_MEMMAP. So doesn't this change actively break ia64? While I like the idea of de-duplication, the two implementations of efi_mem_attributes() are not equivalent. -- Matt Fleming, Intel Open Source Technology Center -- 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/