From: toshi.kani@hp.com (Toshi Kani)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 08/25] arch: introduce memremap()
Date: Wed, 29 Jul 2015 15:11:14 -0600 [thread overview]
Message-ID: <1438204274.3214.421.camel@hp.com> (raw)
In-Reply-To: <1438203638.3214.418.camel@hp.com>
On Wed, 2015-07-29 at 15:00 -0600, Toshi Kani wrote:
> On Wed, 2015-07-29 at 11:33 -0700, Dan Williams wrote:
> > On Wed, Jul 29, 2015 at 11:27 AM, Luis R. Rodriguez <mcgrof@suse.com>
> > wrote:
> > > On Wed, Jul 29, 2015 at 08:50:04AM +0200, Christoph Hellwig wrote:
> > > > On Mon, Jul 27, 2015 at 04:26:03PM -0700, Dan Williams wrote:
> > > > > Oh, because all we have at this point is ioremap_cache() which
> > > > > silently falls back. It's not until the introduction of
> > > > > arch_memremp() where we update the arch code to break that
> > > > > behavior.
> > > >
> > > > Ok, makes sense. Might be worth to document in the changelog.
> > > >
> > > > > That said, I think it may be beneficial to allow a fallback if
> > > > > the
> > > > > user cares. So maybe memremap() can call plain ioremap() if
> > > > > MEMREMAP_STRICT is not set and none of the other mapping types
> > > > > are
> > > > > satisfied.
> > > >
> > > > Is there a real use case for it? Fallback APIs always seem
> > > > confusing
> > > > and it might make more sense to do this in the caller(s) that
> > > > actually
> > > > need it.
> > >
> > > It seems semantics-wise we are trying to separate these two really,
> > > so
> > > I agree
> > > with this. Having a fallback would onloy make things more complicated
> > >
> > > for any
> > > sanitizer / checker / etc, and I don't think the practical gains of
> > > having a
> > > fallback outweight the gains of having a clear semantic separation on
> > >
> > > intended
> > > memory type and interactions with it.
> > >
> >
> > Yup, consider it dropped. Drivers that want fallback behavior can do
> > it explicitly.
>
> I agree in general. However, for the drivers to be able to fall back
> properly, they will need to know the cache type they can fall back with.
> ioremap() falls back to the cache type of an existing mapping to avoid
> aliasing.
Never mind... In this context, we are talking about fallback in case of "
API not implemented" on arch. I was talking about fallback in case of
aliasing.
Thanks,
-Toshi
next prev parent reply other threads:[~2015-07-29 21:11 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-25 2:37 [PATCH v2 00/25] replace ioremap_{cache|wt} with memremap Dan Williams
2015-07-25 2:38 ` [PATCH v2 01/25] mm, x86: Fix warning in ioremap RAM check Dan Williams
2015-07-25 2:38 ` [PATCH v2 02/25] mm, x86: Remove region_is_ram() call from ioremap Dan Williams
2015-07-25 2:38 ` [PATCH v2 03/25] mm: Fix bugs in region_is_ram() Dan Williams
2015-07-25 2:38 ` [PATCH v2 04/25] mm: enhance region_is_ram() to distinguish 'unknown' vs 'mixed' Dan Williams
2015-07-27 22:50 ` Luis R. Rodriguez
2015-07-28 21:33 ` Toshi Kani
2015-07-25 2:38 ` [PATCH v2 05/25] arch, drivers: don't include <asm/io.h> directly, use <linux/io.h> instead Dan Williams
2015-07-25 2:38 ` [PATCH v2 06/25] cleanup IORESOURCE_CACHEABLE vs ioremap() Dan Williams
2015-07-25 2:38 ` [PATCH v2 07/25] intel_iommu: fix leaked ioremap mapping Dan Williams
2015-07-25 2:38 ` [PATCH v2 08/25] arch: introduce memremap() Dan Williams
2015-07-26 17:25 ` Christoph Hellwig
2015-07-26 17:49 ` Dan Williams
2015-07-27 5:12 ` Christoph Hellwig
2015-07-27 5:12 ` Christoph Hellwig
2015-07-27 23:26 ` Dan Williams
2015-07-29 6:50 ` Christoph Hellwig
2015-07-29 18:27 ` Luis R. Rodriguez
2015-07-29 18:33 ` Dan Williams
2015-07-29 21:00 ` Toshi Kani
2015-07-29 21:11 ` Toshi Kani [this message]
2015-07-29 21:43 ` Luis R. Rodriguez
2015-07-29 21:47 ` Dan Williams
2015-07-29 21:52 ` Luis R. Rodriguez
2015-07-30 0:00 ` Toshi Kani
2015-08-11 21:30 ` Luis R. Rodriguez
2015-08-11 22:40 ` Toshi Kani
2015-08-11 22:52 ` Luis R. Rodriguez
2015-08-11 23:13 ` Dan Williams
2016-04-21 12:47 ` Luis R. Rodriguez
2015-07-27 23:17 ` Luis R. Rodriguez
2015-07-27 23:31 ` Dan Williams
2015-07-27 23:43 ` Luis R. Rodriguez
2015-07-28 0:32 ` Dan Williams
2015-07-25 2:38 ` [PATCH v2 09/25] arm: switch from ioremap_cache to memremap Dan Williams
2015-07-25 2:38 ` [PATCH v2 10/25] x86: " Dan Williams
2015-07-25 2:38 ` [PATCH v2 11/25] gma500: switch from acpi_os_ioremap to ioremap Dan Williams
2015-07-25 2:39 ` [PATCH v2 12/25] i915: " Dan Williams
2015-07-27 7:50 ` [Intel-gfx] " Daniel Vetter
2015-07-25 2:39 ` [PATCH v2 13/25] acpi: switch from ioremap_cache to memremap Dan Williams
2015-07-25 23:55 ` Rafael J. Wysocki
2015-07-25 2:39 ` [PATCH v2 14/25] toshiba laptop: replace ioremap_cache with ioremap Dan Williams
2015-07-25 2:39 ` [PATCH v2 15/25] memconsole: fix __iomem mishandling, switch to memremap Dan Williams
2015-07-25 22:02 ` Sergei Shtylyov
2015-07-25 2:39 ` [PATCH v2 16/25] visorbus: switch from ioremap_cache " Dan Williams
2015-07-25 2:39 ` [PATCH v2 17/25] intel-iommu: " Dan Williams
2015-08-03 14:27 ` Joerg Roedel
2015-07-25 2:39 ` [PATCH v2 18/25] libnvdimm, pmem: " Dan Williams
2015-07-28 22:51 ` Ross Zwisler
2015-07-28 23:06 ` Dan Williams
2015-07-25 2:39 ` [PATCH v2 19/25] pxa2xx-flash: " Dan Williams
2015-10-02 17:51 ` Brian Norris
2015-10-09 21:33 ` Dan Williams
2015-07-25 2:39 ` [PATCH v2 20/25] sfi: " Dan Williams
2015-07-25 2:39 ` [PATCH v2 21/25] fbdev: switch from ioremap_wt " Dan Williams
2015-07-25 2:40 ` [PATCH v2 22/25] pmem: " Dan Williams
2015-07-29 19:12 ` Ross Zwisler
2015-07-25 2:40 ` [PATCH v2 23/25] arch: remove ioremap_cache, replace with arch_memremap Dan Williams
2015-07-26 17:31 ` Christoph Hellwig
2015-07-25 2:40 ` [PATCH v2 24/25] arch: remove ioremap_wt, " Dan Williams
2015-07-26 17:31 ` Christoph Hellwig
2015-07-27 8:03 ` Christoph Hellwig
2015-07-29 22:21 ` Dan Williams
2015-07-25 2:40 ` [PATCH v2 25/25] pmem: convert to generic memremap Dan Williams
2015-07-26 17:33 ` Christoph Hellwig
2015-07-26 18:11 ` Dan Williams
2015-07-27 5:14 ` Christoph Hellwig
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=1438204274.3214.421.camel@hp.com \
--to=toshi.kani@hp.com \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).