From: Christoph Hellwig <hch@lst.de>
To: Dan Williams <dan.j.williams@intel.com>
Cc: tglx@linutronix.de, mingo@kernel.org, hpa@zytor.com,
linux-arch@vger.kernel.org, tony.luck@intel.com,
linux@arm.linux.org.uk, arnd@arndb.de, benh@kernel.crashing.org,
mcgrof@suse.com, x86@kernel.org, linux-kernel@vger.kernel.org,
ralf@linux-mips.org, geert@linux-m68k.org, toshi.kani@hp.com,
ross.zwisler@linux.intel.com, hch@lst.de,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 08/10] arch: introduce strict_ioremap
Date: Tue, 21 Jul 2015 15:30:51 +0200 [thread overview]
Message-ID: <20150721133051.GB8902@lst.de> (raw)
In-Reply-To: <20150720001817.30857.69287.stgit@dwillia2-desk3.amr.corp.intel.com>
On Sun, Jul 19, 2015 at 08:18:17PM -0400, Dan Williams wrote:
> In preparation for enabling memremap(), add support for strict mappings.
> strict_ioremap_<type>() returns NULL if the arch does not implement the
> mapping type, rather than falling back silently to ioremap().
Please don't introduce another large number of ioremap variants.
I think we should go straight to the ioremap_flags variant, although
I wonder if we should even bother with ioremap_flags for this use
case, given that we really want memremap-like semantics for anything
that isn't plain ioremap (and maybe ioremap_nocache).
Sorry or being the downer, but I really think we need to clean up this
mess deeply insted of trying to paper over it.
WARNING: multiple messages have this Message-ID (diff)
From: hch@lst.de (Christoph Hellwig)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 08/10] arch: introduce strict_ioremap
Date: Tue, 21 Jul 2015 15:30:51 +0200 [thread overview]
Message-ID: <20150721133051.GB8902@lst.de> (raw)
In-Reply-To: <20150720001817.30857.69287.stgit@dwillia2-desk3.amr.corp.intel.com>
On Sun, Jul 19, 2015 at 08:18:17PM -0400, Dan Williams wrote:
> In preparation for enabling memremap(), add support for strict mappings.
> strict_ioremap_<type>() returns NULL if the arch does not implement the
> mapping type, rather than falling back silently to ioremap().
Please don't introduce another large number of ioremap variants.
I think we should go straight to the ioremap_flags variant, although
I wonder if we should even bother with ioremap_flags for this use
case, given that we really want memremap-like semantics for anything
that isn't plain ioremap (and maybe ioremap_nocache).
Sorry or being the downer, but I really think we need to clean up this
mess deeply insted of trying to paper over it.
next prev parent reply other threads:[~2015-07-21 13:30 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-20 0:17 [PATCH 00/10] unify ioremap definitions and introduce memremap Dan Williams
2015-07-20 0:17 ` Dan Williams
2015-07-20 0:17 ` [PATCH 01/10] mm, x86: Fix warning in ioremap RAM check Dan Williams
2015-07-20 0:17 ` Dan Williams
2015-07-20 0:17 ` [PATCH 02/10] mm, x86: Remove region_is_ram() call from ioremap Dan Williams
2015-07-20 0:17 ` Dan Williams
2015-07-20 0:17 ` [PATCH 03/10] mm: Fix bugs in region_is_ram() Dan Williams
2015-07-20 0:17 ` Dan Williams
2015-07-20 0:17 ` [PATCH 04/10] arch, drivers: don't include <asm/io.h> directly, use <linux/io.h> instead Dan Williams
2015-07-20 0:17 ` Dan Williams
2015-07-20 0:18 ` [PATCH 05/10] arch: unify ioremap prototypes and macro aliases Dan Williams
2015-07-20 0:18 ` Dan Williams
2015-07-21 13:34 ` Christoph Hellwig
2015-07-21 13:34 ` Christoph Hellwig
2015-07-21 16:08 ` Dan Williams
2015-07-21 16:08 ` Dan Williams
2015-07-20 0:18 ` [PATCH 06/10] cleanup IORESOURCE_CACHEABLE vs ioremap() Dan Williams
2015-07-20 0:18 ` Dan Williams
2015-07-20 0:18 ` [PATCH 07/10] devm: fix ioremap_cache() usage Dan Williams
2015-07-20 0:18 ` Dan Williams
2015-07-20 0:18 ` [PATCH 08/10] arch: introduce strict_ioremap Dan Williams
2015-07-20 0:18 ` Dan Williams
2015-07-21 13:30 ` Christoph Hellwig [this message]
2015-07-21 13:30 ` Christoph Hellwig
2015-07-21 16:11 ` Dan Williams
2015-07-21 16:11 ` Dan Williams
2015-07-20 0:18 ` [PATCH 09/10] arch: introduce memremap() Dan Williams
2015-07-20 0:18 ` Dan Williams
2015-07-20 12:00 ` Mark Rutland
2015-07-20 12:00 ` Mark Rutland
2015-07-20 12:00 ` Mark Rutland
2015-07-20 14:39 ` Dan Williams
2015-07-20 14:39 ` Dan Williams
2015-07-20 14:39 ` Dan Williams
2015-07-20 15:56 ` Mark Rutland
2015-07-20 15:56 ` Mark Rutland
2015-07-20 15:56 ` Mark Rutland
2015-07-21 23:58 ` Luis R. Rodriguez
2015-07-21 23:58 ` Luis R. Rodriguez
2015-07-22 4:04 ` Dan Williams
2015-07-22 4:04 ` Dan Williams
2015-07-22 22:55 ` Luis R. Rodriguez
2015-07-22 22:55 ` Luis R. Rodriguez
2015-07-22 23:15 ` Dan Williams
2015-07-22 23:15 ` Dan Williams
2015-07-23 0:55 ` Luis R. Rodriguez
2015-07-23 0:55 ` Luis R. Rodriguez
2015-07-23 1:02 ` Dan Williams
2015-07-23 1:02 ` Dan Williams
2015-07-20 0:18 ` [PATCH 10/10] pmem: convert to generic memremap Dan Williams
2015-07-20 0:18 ` Dan Williams
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=20150721133051.GB8902@lst.de \
--to=hch@lst.de \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=dan.j.williams@intel.com \
--cc=geert@linux-m68k.org \
--cc=hpa@zytor.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mcgrof@suse.com \
--cc=mingo@kernel.org \
--cc=ralf@linux-mips.org \
--cc=ross.zwisler@linux.intel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=toshi.kani@hp.com \
--cc=x86@kernel.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.