All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: arnd@arndb.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com,
	tglx@linutronix.de, ross.zwisler@linux.intel.com,
	akpm@linux-foundation.org, jgross@suse.com, x86@kernel.org,
	toshi.kani@hp.com, linux-nvdimm@lists.01.org,
	benh@kernel.crashing.org, konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, stefan.bader@canonical.com,
	luto@amacapital.net, linux-mm@kvack.org, geert@linux-m68k.org,
	ralf@linux-mips.org, hmh@hmh.eng.br, mpe@ellerman.id.au,
	tj@kernel.org, paulus@samba.org, hch@lst.de
Subject: Re: [PATCH v5 2/6] arch: unify ioremap prototypes and macro aliases
Date: Thu, 9 Jul 2015 20:54:41 +0200	[thread overview]
Message-ID: <20150709185441.GE7021@wotan.suse.de> (raw)
In-Reply-To: <20150622082427.35954.73529.stgit@dwillia2-desk3.jf.intel.com>

On Mon, Jun 22, 2015 at 04:24:27AM -0400, Dan Williams wrote:
> diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
> index d8f8622fa044..4789b1cec313 100644
> --- a/include/asm-generic/iomap.h
> +++ b/include/asm-generic/iomap.h
> @@ -62,14 +62,6 @@ extern void __iomem *ioport_map(unsigned long port, unsigned int nr);
>  extern void ioport_unmap(void __iomem *);
>  #endif
>  
> -#ifndef ARCH_HAS_IOREMAP_WC
> -#define ioremap_wc ioremap_nocache
> -#endif
> -
> -#ifndef ARCH_HAS_IOREMAP_WT
> -#define ioremap_wt ioremap_nocache
> -#endif
> -
>  #ifdef CONFIG_PCI
>  /* Destroy a virtual mapping cookie for a PCI BAR (memory or IO) */
>  struct pci_dev;

While at it we should also detangle ioremap() variants default implementations
from requiring !CONFIG_MMU, so to be clear, if you have CONFIG_MMU you should
implement ioremap() and iounmap(), then additionally if you have a way to
support an ioremap_*() variant you should do so as well. You can
include asm-generic/iomap.h to help complete ioremap_*() variants you may not
have defined but note below.

***Big fat note**: this however assumes we have a *safe* general ioremap() to
default to for all architectures but for a slew of reasons we cannot have this
today and further discussion is needed to see if it may be possible one day. In
the meantime we must then settle to advocate architecture developers to
provide their own ioremap_*() variant implementations. We can do this two ways:

  1) make new defaults return NULL - to avoid improper behaviour
  2) revisit current default implementations on asm-generic for
     ioremap_*() variants and vet that they are safe for each architecture
     actually using them, if they are safe tuck under each arch its own
     mapping. After all this then convert default to return NULL. This
     will prevent future issues with other architectures.
  3) long term: work towards the lofty objective of defining an architecturally
     sane iorema_*() variant default. This can only be done once all the
     semantics of all the others are well established.

I'll provide a small demo patch with a very specific fix. We can either
address this as separate work prior to your patchset or mesh this work
together.

  Luis

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: arnd@arndb.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com,
	tglx@linutronix.de, ross.zwisler@linux.intel.com,
	akpm@linux-foundation.org, jgross@suse.com, x86@kernel.org,
	toshi.kani@hp.com, linux-nvdimm@ml01.01.org,
	benh@kernel.crashing.org, konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, stefan.bader@canonical.com,
	luto@amacapital.net, linux-mm@kvack.org, geert@linux-m68k.org,
	ralf@linux-mips.org, hmh@hmh.eng.br, mpe@ellerman.id.au,
	tj@kernel.org, paulus@samba.org, hch@lst.de
Subject: Re: [PATCH v5 2/6] arch: unify ioremap prototypes and macro aliases
Date: Thu, 9 Jul 2015 20:54:41 +0200	[thread overview]
Message-ID: <20150709185441.GE7021@wotan.suse.de> (raw)
In-Reply-To: <20150622082427.35954.73529.stgit@dwillia2-desk3.jf.intel.com>

On Mon, Jun 22, 2015 at 04:24:27AM -0400, Dan Williams wrote:
> diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
> index d8f8622fa044..4789b1cec313 100644
> --- a/include/asm-generic/iomap.h
> +++ b/include/asm-generic/iomap.h
> @@ -62,14 +62,6 @@ extern void __iomem *ioport_map(unsigned long port, unsigned int nr);
>  extern void ioport_unmap(void __iomem *);
>  #endif
>  
> -#ifndef ARCH_HAS_IOREMAP_WC
> -#define ioremap_wc ioremap_nocache
> -#endif
> -
> -#ifndef ARCH_HAS_IOREMAP_WT
> -#define ioremap_wt ioremap_nocache
> -#endif
> -
>  #ifdef CONFIG_PCI
>  /* Destroy a virtual mapping cookie for a PCI BAR (memory or IO) */
>  struct pci_dev;

While at it we should also detangle ioremap() variants default implementations
from requiring !CONFIG_MMU, so to be clear, if you have CONFIG_MMU you should
implement ioremap() and iounmap(), then additionally if you have a way to
support an ioremap_*() variant you should do so as well. You can
include asm-generic/iomap.h to help complete ioremap_*() variants you may not
have defined but note below.

***Big fat note**: this however assumes we have a *safe* general ioremap() to
default to for all architectures but for a slew of reasons we cannot have this
today and further discussion is needed to see if it may be possible one day. In
the meantime we must then settle to advocate architecture developers to
provide their own ioremap_*() variant implementations. We can do this two ways:

  1) make new defaults return NULL - to avoid improper behaviour
  2) revisit current default implementations on asm-generic for
     ioremap_*() variants and vet that they are safe for each architecture
     actually using them, if they are safe tuck under each arch its own
     mapping. After all this then convert default to return NULL. This
     will prevent future issues with other architectures.
  3) long term: work towards the lofty objective of defining an architecturally
     sane iorema_*() variant default. This can only be done once all the
     semantics of all the others are well established.

I'll provide a small demo patch with a very specific fix. We can either
address this as separate work prior to your patchset or mesh this work
together.

  Luis

  parent reply	other threads:[~2015-07-09 18:54 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-22  8:24 [PATCH v5 0/6] pmem api, generic ioremap_cache, and memremap Dan Williams
2015-06-22  8:24 ` Dan Williams
2015-06-22  8:24 ` [PATCH v5 1/6] arch, drivers: don't include <asm/io.h> directly, use <linux/io.h> instead Dan Williams
2015-06-22  8:24   ` Dan Williams
2015-06-22 16:01   ` Christoph Hellwig
2015-06-22 16:01     ` Christoph Hellwig
2015-06-22  8:24 ` [PATCH v5 2/6] arch: unify ioremap prototypes and macro aliases Dan Williams
2015-06-22  8:24   ` Dan Williams
2015-06-22 16:10   ` Christoph Hellwig
2015-06-22 16:10     ` Christoph Hellwig
2015-06-22 17:12     ` Dan Williams
2015-06-22 17:12       ` Dan Williams
2015-06-23 10:07       ` Christoph Hellwig
2015-06-23 10:07         ` Christoph Hellwig
2015-06-23 15:04         ` Dan Williams
2015-06-23 15:04           ` Dan Williams
2015-06-24 12:24           ` Christoph Hellwig
2015-06-24 12:24             ` Christoph Hellwig
2015-06-30 22:57     ` Dan Williams
2015-06-30 22:57       ` Dan Williams
2015-06-30 22:57       ` Dan Williams
2015-07-01  6:23       ` Christoph Hellwig
2015-07-01  6:23         ` Christoph Hellwig
2015-07-01  6:23         ` Christoph Hellwig
2015-07-01  6:55         ` Geert Uytterhoeven
2015-07-01  6:55           ` Geert Uytterhoeven
2015-07-01  6:55           ` Geert Uytterhoeven
2015-07-01  6:59           ` Christoph Hellwig
2015-07-01  6:59             ` Christoph Hellwig
2015-07-01  6:59             ` Christoph Hellwig
2015-07-01  7:19             ` Geert Uytterhoeven
2015-07-01  7:19               ` Geert Uytterhoeven
2015-07-01  7:19               ` Geert Uytterhoeven
2015-07-01  7:28               ` Christoph Hellwig
2015-07-01  7:28                 ` Christoph Hellwig
2015-07-01  7:28                 ` Christoph Hellwig
2015-07-07  9:50                 ` Luis R. Rodriguez
2015-07-07  9:50                   ` Luis R. Rodriguez
2015-07-07  9:50                   ` Luis R. Rodriguez
2015-07-07 10:13                   ` Russell King - ARM Linux
2015-07-07 10:13                     ` Russell King - ARM Linux
2015-07-07 10:13                     ` Russell King - ARM Linux
2015-07-07 10:27                     ` Geert Uytterhoeven
2015-07-07 10:27                       ` Geert Uytterhoeven
2015-07-07 10:27                       ` Geert Uytterhoeven
2015-07-07 16:07                     ` Luis R. Rodriguez
2015-07-07 16:07                       ` Luis R. Rodriguez
2015-07-07 16:07                       ` Luis R. Rodriguez
2015-07-07 23:10                       ` Toshi Kani
2015-07-07 23:10                         ` Toshi Kani
2015-07-07 23:10                         ` Toshi Kani
2015-07-09  1:40                         ` Luis R. Rodriguez
2015-07-09  1:40                           ` Luis R. Rodriguez
2015-07-09  1:40                           ` Luis R. Rodriguez
2015-07-09 23:43                           ` Toshi Kani
2015-07-09 23:43                             ` Toshi Kani
2015-07-09 23:43                             ` Toshi Kani
2015-07-01  8:09           ` Russell King - ARM Linux
2015-07-01  8:09             ` Russell King - ARM Linux
2015-07-01  8:09             ` Russell King - ARM Linux
2015-07-01 16:47             ` Dan Williams
2015-07-01 16:47               ` Dan Williams
2015-07-01 16:47               ` Dan Williams
2015-07-09 18:54   ` Luis R. Rodriguez [this message]
2015-07-09 18:54     ` Luis R. Rodriguez
2015-06-22  8:24 ` [PATCH v5 3/6] cleanup IORESOURCE_CACHEABLE vs ioremap() Dan Williams
2015-06-22  8:24   ` Dan Williams
2015-06-22  8:24 ` [PATCH v5 4/6] devm: fix ioremap_cache() usage Dan Williams
2015-06-22  8:24   ` Dan Williams
2015-06-22  8:24 ` [PATCH v5 5/6] arch: introduce memremap_cache() and memremap_wt() Dan Williams
2015-06-22  8:24   ` Dan Williams
2015-06-22  8:24 ` [PATCH v5 6/6] arch, x86: pmem api for ensuring durability of persistent memory updates Dan Williams
2015-06-22  8:24   ` Dan Williams
2015-06-22 16:17   ` Christoph Hellwig
2015-06-22 16:17     ` Christoph Hellwig
2015-06-22 17:51     ` Dan Williams
2015-06-22 17:51       ` Dan Williams
2015-06-23 10:09       ` Christoph Hellwig
2015-06-23 10:09         ` Christoph Hellwig
2015-06-23 10:39     ` Richard Weinberger
2015-06-23 10:39       ` Richard Weinberger
2015-06-24 12:08       ` Christoph Hellwig
2015-06-24 12:08         ` Christoph Hellwig
2015-06-24 12:35         ` Richard Weinberger
2015-06-24 12:35           ` Richard Weinberger

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=20150709185441.GE7021@wotan.suse.de \
    --to=mcgrof@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=bp@alien8.de \
    --cc=dan.j.williams@intel.com \
    --cc=geert@linux-m68k.org \
    --cc=hch@lst.de \
    --cc=hmh@hmh.eng.br \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=ralf@linux-mips.org \
    --cc=ross.zwisler@linux.intel.com \
    --cc=stefan.bader@canonical.com \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --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.