linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

  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).