From: Will Deacon <will.deacon@arm.com>
To: Matt Fleming <matt.fleming@intel.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>
Subject: Re: [PATCH V7 4/5] arm64: apei: implement arch_apei_get_mem_attributes()
Date: Mon, 27 Jul 2015 10:45:20 +0100 [thread overview]
Message-ID: <20150727094520.GB3358@arm.com> (raw)
In-Reply-To: <1437989891.22168.15.camel@intel.com>
On Mon, Jul 27, 2015 at 10:38:11AM +0100, Matt Fleming wrote:
> On Fri, 2015-07-24 at 17:26 +0100, Will Deacon wrote:
> > On Fri, Jul 24, 2015 at 05:21:49PM +0100, Catalin Marinas wrote:
> > > On Fri, Jul 24, 2015 at 03:57:08PM +0100, Will Deacon wrote:
> > > > On Tue, Jul 21, 2015 at 10:59:19PM +0100, Jonathan (Zhixiong) Zhang wrote:
> > > > > diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> > > > > +static inline pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
> > > > > +{
> > > > > + pgprot_t prot;
> > > > > +
> > > > > + prot = efi_mem_attributes(addr);
> > > > > + if (prot & EFI_MEMORY_UC)
> > > > > + return PROT_DEVICE_nGnRnE;
> > > > > + if (prot & EFI_MEMORY_WC)
> > > > > + return PROT_NORMAL_NC;
> > > >
> > > > Can we not use pgprot_noncached and pgprot_writecombine for these two?
> > >
> > > Actually, why do we even use pgprot_t for prot here? EFI_MEMORY_* don't
> > > have anything to do with the arch-specific pgprot_t.
> >
> > Good point; the pgprot_t confused me, so my suggestion is much use after
> > ll. We're better off with a u64 to avoid further confusion.
>
> Isn't the whole point of arch_apei_get_mem_attribute() to turn an
> arch-independent memory attribute (EFI_MEMORY_*) into an arch-specific
> value to pass to ioremap_page_range()?
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.
> 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>
Will
next prev parent reply other threads:[~2015-07-27 9:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-21 21:59 [PATCH V7 0/5] map GHES memory region according to EFI memory map Jonathan (Zhixiong) Zhang
[not found] ` <1437515960-16812-1-git-send-email-zjzhang-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-07-21 21:59 ` [PATCH V7 1/5] efi: x86: rearrange efi_mem_attributes() Jonathan (Zhixiong) Zhang
2015-07-21 21:59 ` Jonathan (Zhixiong) Zhang
2015-07-21 21:59 ` [PATCH V7 2/5] x86: acpi: implement arch_apei_get_mem_attributes() Jonathan (Zhixiong) Zhang
2015-07-21 21:59 ` [PATCH V7 3/5] arm64: mm: add PROT_DEVICE_nGnRnE and PROT_NORMAL_WT Jonathan (Zhixiong) Zhang
2015-07-24 2:52 ` Hanjun Guo
2015-07-24 16:15 ` Catalin Marinas
2015-07-24 16:26 ` Will Deacon
2015-07-24 16:34 ` Catalin Marinas
2015-07-24 19:02 ` Zhang, Jonathan Zhixiong
2015-07-27 10:22 ` Catalin Marinas
2015-07-21 21:59 ` [PATCH V7 4/5] arm64: apei: implement arch_apei_get_mem_attributes() Jonathan (Zhixiong) Zhang
2015-07-24 2:59 ` Hanjun Guo
2015-07-24 19:25 ` Zhang, Jonathan Zhixiong
2015-07-24 14:57 ` Will Deacon
2015-07-24 16:21 ` Catalin Marinas
2015-07-24 16:26 ` Will Deacon
2015-07-24 18:46 ` Zhang, Jonathan Zhixiong
2015-07-27 9:38 ` Matt Fleming
2015-07-27 9:45 ` Will Deacon [this message]
2015-07-27 9:54 ` Matt Fleming
2015-07-29 0:58 ` Zhang, Jonathan Zhixiong
2015-07-21 21:59 ` [PATCH V7 5/5] acpi, apei: use appropriate pgprot_t to map GHES memory Jonathan (Zhixiong) Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150727094520.GB3358@arm.com \
--to=will.deacon@arm.com \
--cc=Catalin.Marinas@arm.com \
--cc=al.stone@linaro.org \
--cc=fu.wei@linaro.org \
--cc=linaro-acpi@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.fleming@intel.com \
--cc=rjw@rjwysocki.net \
--cc=zjzhang@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.