From: Brian Norris <computersforpeace@gmail.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Dan Williams <dan.j.williams@intel.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
linux-mtd@lists.infradead.org,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
David Woodhouse <dwmw2@infradead.org>,
Robert Jarzmik <robert.jarzmik@free.fr>
Subject: Re: [PATCH v3 0/4] fix memremap on ARM
Date: Fri, 4 Mar 2016 16:15:25 -0800 [thread overview]
Message-ID: <20160305001525.GD55664@google.com> (raw)
In-Reply-To: <CAKv+Gu_SFO81PniDNYjfz6OqbBXdmi0Z3GWO=OBAc0p1v4_JBQ@mail.gmail.com>
On Fri, Mar 04, 2016 at 08:16:56PM +0100, Ard Biesheuvel wrote:
> On 4 March 2016 at 19:34, Dan Williams <dan.j.williams@intel.com> wrote:
> > On Fri, Mar 4, 2016 at 1:48 AM, Ard Biesheuvel
> > <ard.biesheuvel@linaro.org> wrote:
> >> This is something I ran into while working on support for the UEFI
> >> memory attributes and ESRT tables. In both cases, these tables are
> >> passed to the kernel in memory which is guaranteed to be below 4 GB,
> >> but may be outside of the kernel direct mapping. (UEFI typically
> >> attempts to allocate from the top down, which means such tables are
> >> highly likely to be in highmem for any system with more than 760 MB
> >> of system RAM)
> >>
> >> The recently introduced memremap() is a very useful abstraction for
> >> accessing such tables, because it is generic, and already attempts to
> >> do the right thing with respect to regions that may already have been
> >> mapped directly. However, it falls back to ioremap_cache() for mapping
> >> high memory, which is not allowed on ARM for system RAM, and also results
> >> in the region to be mapped with different attributes depending on whether
> >> it is covered by lowmem or not.
> >>
> >> So instead, create an arch specific hook 'arch_memremap_wb(), and
> >> implement it for ARM using the same memory attributes used for the
> >> linear mapping. Note that memremap will only call this hook for regions
> >> that are not already mapped permanently.
> >>
> >> Since this change results in memremap() to use attributes different from
> >> the ones used by ioremap_cache(), revert the change to pxa2xx-flash that
> >> moved it to memremap.
> >>
> >> Changes since v2:
> >> - add patch to bring back ioremap_cached() on ARM
> >> - switch pxa2xx-flash back to ioremap_cached() not ioremap_cache()
> >> - use arch_ioremap_caller not __arm_ioremap_caller() in patch #4
> >> - deal with __iomem annotation of arch_ioremap_caller (patch #4)
> >>
> >> Changes since v1/rfc:
> >> - new patch #1 that reverts the ioremap_cache->memremap conversion for the
> >> pxa2xx-flash driver
> >> - added Dan's ack to patch #2
> >>
> >> Ard Biesheuvel (4):
> >> ARM: reintroduce ioremap_cached() for creating cached I/O mappings
> >> mtd: pxa2xx-flash: switch back from memremap to ioremap_cached
> >> memremap: add arch specific hook for MEMREMAP_WB mappings
> >> ARM: memremap: implement arch_memremap_wb()
> >>
> >> arch/arm/include/asm/io.h | 12 ++++++++++++
> >> arch/arm/mm/ioremap.c | 16 ++++++++++++++--
> >> drivers/mtd/maps/pxa2xx-flash.c | 6 +++---
> >> kernel/memremap.c | 11 ++++++++---
> >> 4 files changed, 37 insertions(+), 8 deletions(-)
> >>
> >
> > For the series:
> >
> > Acked-by: Dan Williams <dan.j.williams@intel.com>
>
> Thanks Dan,
>
> With the added patch #1, I think it now makes the most sense for
> Russell to take the whole series via the ARM tree.
>
> @Brian, David: any objections?
Nope. For the MTD part:
Acked-by: Brian Norris <computersforpeace@gmail.com>
Regards,
Brian
WARNING: multiple messages have this Message-ID (diff)
From: computersforpeace@gmail.com (Brian Norris)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 0/4] fix memremap on ARM
Date: Fri, 4 Mar 2016 16:15:25 -0800 [thread overview]
Message-ID: <20160305001525.GD55664@google.com> (raw)
In-Reply-To: <CAKv+Gu_SFO81PniDNYjfz6OqbBXdmi0Z3GWO=OBAc0p1v4_JBQ@mail.gmail.com>
On Fri, Mar 04, 2016 at 08:16:56PM +0100, Ard Biesheuvel wrote:
> On 4 March 2016 at 19:34, Dan Williams <dan.j.williams@intel.com> wrote:
> > On Fri, Mar 4, 2016 at 1:48 AM, Ard Biesheuvel
> > <ard.biesheuvel@linaro.org> wrote:
> >> This is something I ran into while working on support for the UEFI
> >> memory attributes and ESRT tables. In both cases, these tables are
> >> passed to the kernel in memory which is guaranteed to be below 4 GB,
> >> but may be outside of the kernel direct mapping. (UEFI typically
> >> attempts to allocate from the top down, which means such tables are
> >> highly likely to be in highmem for any system with more than 760 MB
> >> of system RAM)
> >>
> >> The recently introduced memremap() is a very useful abstraction for
> >> accessing such tables, because it is generic, and already attempts to
> >> do the right thing with respect to regions that may already have been
> >> mapped directly. However, it falls back to ioremap_cache() for mapping
> >> high memory, which is not allowed on ARM for system RAM, and also results
> >> in the region to be mapped with different attributes depending on whether
> >> it is covered by lowmem or not.
> >>
> >> So instead, create an arch specific hook 'arch_memremap_wb(), and
> >> implement it for ARM using the same memory attributes used for the
> >> linear mapping. Note that memremap will only call this hook for regions
> >> that are not already mapped permanently.
> >>
> >> Since this change results in memremap() to use attributes different from
> >> the ones used by ioremap_cache(), revert the change to pxa2xx-flash that
> >> moved it to memremap.
> >>
> >> Changes since v2:
> >> - add patch to bring back ioremap_cached() on ARM
> >> - switch pxa2xx-flash back to ioremap_cached() not ioremap_cache()
> >> - use arch_ioremap_caller not __arm_ioremap_caller() in patch #4
> >> - deal with __iomem annotation of arch_ioremap_caller (patch #4)
> >>
> >> Changes since v1/rfc:
> >> - new patch #1 that reverts the ioremap_cache->memremap conversion for the
> >> pxa2xx-flash driver
> >> - added Dan's ack to patch #2
> >>
> >> Ard Biesheuvel (4):
> >> ARM: reintroduce ioremap_cached() for creating cached I/O mappings
> >> mtd: pxa2xx-flash: switch back from memremap to ioremap_cached
> >> memremap: add arch specific hook for MEMREMAP_WB mappings
> >> ARM: memremap: implement arch_memremap_wb()
> >>
> >> arch/arm/include/asm/io.h | 12 ++++++++++++
> >> arch/arm/mm/ioremap.c | 16 ++++++++++++++--
> >> drivers/mtd/maps/pxa2xx-flash.c | 6 +++---
> >> kernel/memremap.c | 11 ++++++++---
> >> 4 files changed, 37 insertions(+), 8 deletions(-)
> >>
> >
> > For the series:
> >
> > Acked-by: Dan Williams <dan.j.williams@intel.com>
>
> Thanks Dan,
>
> With the added patch #1, I think it now makes the most sense for
> Russell to take the whole series via the ARM tree.
>
> @Brian, David: any objections?
Nope. For the MTD part:
Acked-by: Brian Norris <computersforpeace@gmail.com>
Regards,
Brian
next prev parent reply other threads:[~2016-03-05 0:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-04 9:48 [PATCH v3 0/4] fix memremap on ARM Ard Biesheuvel
2016-03-04 9:48 ` Ard Biesheuvel
2016-03-04 9:48 ` [PATCH v3 1/4] ARM: reintroduce ioremap_cached() for creating cached I/O mappings Ard Biesheuvel
2016-03-04 9:48 ` Ard Biesheuvel
2016-03-04 9:48 ` [PATCH v3 2/4] mtd: pxa2xx-flash: switch back from memremap to ioremap_cached Ard Biesheuvel
2016-03-04 9:48 ` Ard Biesheuvel
2016-03-04 9:48 ` [PATCH v3 3/4] memremap: add arch specific hook for MEMREMAP_WB mappings Ard Biesheuvel
2016-03-04 9:48 ` Ard Biesheuvel
2016-03-04 9:48 ` [PATCH v3 4/4] ARM: memremap: implement arch_memremap_wb() Ard Biesheuvel
2016-03-04 9:48 ` Ard Biesheuvel
2016-03-04 18:34 ` [PATCH v3 0/4] fix memremap on ARM Dan Williams
2016-03-04 18:34 ` Dan Williams
2016-03-04 19:16 ` Ard Biesheuvel
2016-03-04 19:16 ` Ard Biesheuvel
2016-03-05 0:15 ` Brian Norris [this message]
2016-03-05 0:15 ` Brian Norris
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=20160305001525.GD55664@google.com \
--to=computersforpeace@gmail.com \
--cc=ard.biesheuvel@linaro.org \
--cc=dan.j.williams@intel.com \
--cc=dwmw2@infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux@arm.linux.org.uk \
--cc=robert.jarzmik@free.fr \
/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.