All of lore.kernel.org
 help / color / mirror / Atom feed
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,
	kbuild test robot <fengguang.wu@intel.com>,
	hch@lst.de, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 05/10] arch: unify ioremap prototypes and macro aliases
Date: Tue, 21 Jul 2015 15:34:57 +0200	[thread overview]
Message-ID: <20150721133457.GC8902@lst.de> (raw)
In-Reply-To: <20150720001759.30857.23753.stgit@dwillia2-desk3.amr.corp.intel.com>

On Sun, Jul 19, 2015 at 08:18:00PM -0400, Dan Williams wrote:
> Some archs define the first parameter to ioremap() as unsigned long,
> while the balance define it as resource_size_t, similar confusion exists
> for the type of the 'size' parameter.  Unify on (resource_size_t,
> unsigned long) to enable passing ioremap function pointers.  Also, some
> archs use function-like macros for defining ioremap aliases, but
> asm-generic/io.h expects object-like macros, unify on the latter.
> 
> Move all handling of ioremap aliasing (i.e. ioremap_wt => ioremap) to
> include/linux/io.h.  Add a check to lib/devres.c to warn at compile time
> if an arch violates type expectations.

I don't think devres really has aything to do with this code.

> Kill ARCH_HAS_IOREMAP_WC and ARCH_HAS_IOREMAP_WT in favor of just
> testing for ioremap_wc, and ioremap_wt being defined.  This arrangement
> allows drivers to know when ioremap_<foo> are being re-directed to plain
> ioremap.  A later patch uses this arrangement to implement support for
> strict mappings.
> 
> Acked-by: Christoph Hellwig <hch@lst.de>

I only ACKed this as a band-aid to get the pmem code in.  Now that
we got that in with a less invasive hack I don't see any reasons to
do this over doing the proper common prototypes and per-arch runtime checks
of flags variant.

WARNING: multiple messages have this Message-ID (diff)
From: hch@lst.de (Christoph Hellwig)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 05/10] arch: unify ioremap prototypes and macro aliases
Date: Tue, 21 Jul 2015 15:34:57 +0200	[thread overview]
Message-ID: <20150721133457.GC8902@lst.de> (raw)
In-Reply-To: <20150720001759.30857.23753.stgit@dwillia2-desk3.amr.corp.intel.com>

On Sun, Jul 19, 2015 at 08:18:00PM -0400, Dan Williams wrote:
> Some archs define the first parameter to ioremap() as unsigned long,
> while the balance define it as resource_size_t, similar confusion exists
> for the type of the 'size' parameter.  Unify on (resource_size_t,
> unsigned long) to enable passing ioremap function pointers.  Also, some
> archs use function-like macros for defining ioremap aliases, but
> asm-generic/io.h expects object-like macros, unify on the latter.
> 
> Move all handling of ioremap aliasing (i.e. ioremap_wt => ioremap) to
> include/linux/io.h.  Add a check to lib/devres.c to warn at compile time
> if an arch violates type expectations.

I don't think devres really has aything to do with this code.

> Kill ARCH_HAS_IOREMAP_WC and ARCH_HAS_IOREMAP_WT in favor of just
> testing for ioremap_wc, and ioremap_wt being defined.  This arrangement
> allows drivers to know when ioremap_<foo> are being re-directed to plain
> ioremap.  A later patch uses this arrangement to implement support for
> strict mappings.
> 
> Acked-by: Christoph Hellwig <hch@lst.de>

I only ACKed this as a band-aid to get the pmem code in.  Now that
we got that in with a less invasive hack I don't see any reasons to
do this over doing the proper common prototypes and per-arch runtime checks
of flags variant.

  reply	other threads:[~2015-07-21 13:35 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 [this message]
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
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=20150721133457.GC8902@lst.de \
    --to=hch@lst.de \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=dan.j.williams@intel.com \
    --cc=fengguang.wu@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.