Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753870AbbG0Jy6 (ORCPT <rfc822;w@1wt.eu>);
	Mon, 27 Jul 2015 05:54:58 -0400
Received: from mga01.intel.com ([192.55.52.88]:35313 "EHLO mga01.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752391AbbG0Jy5 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 27 Jul 2015 05:54:57 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.15,552,1432623600"; 
   d="scan'208";a="736133826"
Message-ID: <1437990891.22168.20.camel@intel.com>
Subject: Re: [PATCH V7 4/5] arm64: apei: implement
 arch_apei_get_mem_attributes()
From: Matt Fleming <matt.fleming@intel.com>
To: Will Deacon <will.deacon@arm.com>
CC: Catalin Marinas <Catalin.Marinas@arm.com>,
        "Jonathan (Zhixiong) Zhang" <zjzhang@codeaurora.org>,
        "fu.wei@linaro.org" <fu.wei@linaro.org>,
        "al.stone@linaro.org" <al.stone@linaro.org>,
        "rjw@rjwysocki.net" <rjw@rjwysocki.net>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>
Date: Mon, 27 Jul 2015 10:54:51 +0100
In-Reply-To: <20150727094520.GB3358@arm.com>
References: <1437515960-16812-1-git-send-email-zjzhang@codeaurora.org>
	 <1437515960-16812-5-git-send-email-zjzhang@codeaurora.org>
	 <20150724145707.GD12569@arm.com>
	 <20150724162149.GX3550@e104818-lin.cambridge.arm.com>
	 <20150724162600.GA21177@arm.com> <1437989891.22168.15.camel@intel.com>
	 <20150727094520.GB3358@arm.com>
Organization: Intel Corporation (UK) Ltd. - Registered No. 1134945 - Pipers
 Way, Swindon SN3 1RJ
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.12.11 (3.12.11-1.fc21) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Originating-IP: [163.33.239.180]
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1605
Lines: 43

On Mon, 2015-07-27 at 10:45 +0100, Will Deacon wrote:
> 
> That bit's fine. The weird bit is:
> 
>   pgprot_t prot;
> 
>   prot = efi_mem_attributes(addr);
> 
> Since that's putting the arch-independent format into the pg_prot.

Oops, missed that. Yeah that's funky.

> > I don't see how you can do that any other way than by using pgprot_t.
> > 
> > Really, the problem here is that ioremap_page_caller() has no notion of
> > "map this range in a firmware-compatible manner". If we could do, for
> > example,
> > 
> > 	ioremap_page_range(vaddr, vend, paddr, PAGE_FW_COMPAT);
> > 
> > that would allow the innards of the arch-ioremap to figure out exactly
> > how to map this range so that the firmware could access it coherently.
> > 
> > I suggested this previously but it didn't gain any traction.
> 
> Yeah, or just ioremap_efi.
> 
> </me runs away>

Someone beat you to it ;-)

arch/x86/include/asm/efi.h:#define efi_ioremap(addr, size, type, attr)	ioremap_cache(addr, size)
arch/x86/include/asm/efi.h:extern void __iomem *__init efi_ioremap(unsigned long addr, unsigned long size,
arch/x86/platform/efi/efi.c:		va = efi_ioremap(md->phys_addr, size,
arch/x86/platform/efi/efi_64.c:void __iomem *__init efi_ioremap(unsigned long phys_addr, unsigned long size,
arch/x86/platform/efi/efi_64.c:		efi_ioremap(top, size - (top - phys_addr), type, attribute);


--
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/