linux-mips.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Palmer Dabbelt <palmer@dabbelt.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Arnd Bergmann <arnd@arndb.de>,
	guoren@kernel.org, monstr@monstr.eu, green.hu@gmail.com,
	deanbo422@gmail.com, gxt@pku.edu.cn, x86@kernel.org,
	linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
	linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
	nios2-dev@lists.rocketboards.org, openrisc@lists.librecores.org,
	linux-parisc@vger.kernel.org, linux-riscv@lists.infradead.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org,
	linux-mtd@lists.infradead.org, linux-arch@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 11/21] asm-generic: don't provide ioremap for CONFIG_MMU
Date: Wed, 06 Nov 2019 10:11:37 -0800 (PST)	[thread overview]
Message-ID: <mhng-33ea9141-2440-4a2d-8133-62094486fc48@palmer-si-x1c4> (raw)
In-Reply-To: <20191029064834.23438-12-hch@lst.de>

On Mon, 28 Oct 2019 23:48:24 PDT (-0700), Christoph Hellwig wrote:
> All MMU-enabled ports have a non-trivial ioremap and should thus provide
> the prototype for their implementation instead of providing a generic
> one unless a different symbol is not defined.  Note that this only
> affects sparc32 nds32 as all others do provide their own version.
>
> Also update the kerneldoc comments in asm-generic/io.h to explain the
> situation around the default ioremap* implementations correctly.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  arch/nds32/include/asm/io.h    |  2 ++
>  arch/sparc/include/asm/io_32.h |  1 +
>  include/asm-generic/io.h       | 29 ++++++++---------------------
>  3 files changed, 11 insertions(+), 21 deletions(-)
>
> diff --git a/arch/nds32/include/asm/io.h b/arch/nds32/include/asm/io.h
> index 16f262322b8f..fb0e8a24c7af 100644
> --- a/arch/nds32/include/asm/io.h
> +++ b/arch/nds32/include/asm/io.h
> @@ -6,6 +6,7 @@
>
>  #include <linux/types.h>
>
> +void __iomem *ioremap(phys_addr_t phys_addr, size_t size);
>  extern void iounmap(volatile void __iomem *addr);
>  #define __raw_writeb __raw_writeb
>  static inline void __raw_writeb(u8 val, volatile void __iomem *addr)
> @@ -80,4 +81,5 @@ static inline u32 __raw_readl(const volatile void __iomem *addr)
>  #define writew(v,c)	({ __iowmb(); writew_relaxed((v),(c)); })
>  #define writel(v,c)	({ __iowmb(); writel_relaxed((v),(c)); })
>  #include <asm-generic/io.h>
> +
>  #endif /* __ASM_NDS32_IO_H */
> diff --git a/arch/sparc/include/asm/io_32.h b/arch/sparc/include/asm/io_32.h
> index df2dc1784673..9a52d9506f80 100644
> --- a/arch/sparc/include/asm/io_32.h
> +++ b/arch/sparc/include/asm/io_32.h
> @@ -127,6 +127,7 @@ static inline void sbus_memcpy_toio(volatile void __iomem *dst,
>   * Bus number may be embedded in the higher bits of the physical address.
>   * This is why we have no bus number argument to ioremap().
>   */
> +void __iomem *ioremap(phys_addr_t offset, size_t size);
>  void iounmap(volatile void __iomem *addr);
>  /* Create a virtual mapping cookie for an IO port range */
>  void __iomem *ioport_map(unsigned long port, unsigned int nr);
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index a98ed6325727..6a5edc23afe2 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -922,28 +922,16 @@ static inline void *phys_to_virt(unsigned long address)
>  /**
>   * DOC: ioremap() and ioremap_*() variants
>   *
> - * If you have an IOMMU your architecture is expected to have both ioremap()
> - * and iounmap() implemented otherwise the asm-generic helpers will provide a
> - * direct mapping.
> + * Architectures with an MMU are expected to provide ioremap() and iounmap()
> + * themselves.  For NOMMU architectures we provide a default nop-op
> + * implementation that expect that the physical address used for MMIO are
> + * already marked as uncached, and can be used as kernel virtual addresses.
>   *
> - * There are ioremap_*() call variants, if you have no IOMMU we naturally will
> - * default to direct mapping for all of them, you can override these defaults.
> - * If you have an IOMMU you are highly encouraged to provide your own
> - * ioremap variant implementation as there currently is no safe architecture
> - * agnostic default. To avoid possible improper behaviour default asm-generic
> - * ioremap_*() variants all return NULL when an IOMMU is available. If you've
> - * defined your own ioremap_*() variant you must then declare your own
> - * ioremap_*() variant as defined to itself to avoid the default NULL return.
> + * ioremap_wc() and ioremap_wt() can provide more relaxed caching attributes
> + * for specific drivers if the architecture choses to implement them.  If they
> + * are not implemented we fall back to plain ioremap.
>   */
>  #ifndef CONFIG_MMU
> -
> -/*
> - * Change "struct page" to physical address.
> - *
> - * This implementation is for the no-MMU case only... if you have an MMU
> - * you'll need to provide your own definitions.
> - */
> -
>  #ifndef ioremap
>  #define ioremap ioremap
>  static inline void __iomem *ioremap(phys_addr_t offset, size_t size)
> @@ -954,14 +942,13 @@ static inline void __iomem *ioremap(phys_addr_t offset, size_t size)
>
>  #ifndef iounmap
>  #define iounmap iounmap
> -
>  static inline void iounmap(void __iomem *addr)
>  {
>  }
>  #endif
>  #endif /* CONFIG_MMU */
> +
>  #ifndef ioremap_nocache
> -void __iomem *ioremap(phys_addr_t phys_addr, size_t size);
>  #define ioremap_nocache ioremap_nocache
>  static inline void __iomem *ioremap_nocache(phys_addr_t offset, size_t size)
>  {

It looks like the difference in prototype between the architectures is between

    void __iomem *ioremap(resource_size_t, size_t)
    void __iomem *ioremap(phys_addr_t, size_t)
    void __iomem *ioremap(phys_addr_t, unsigned long)
    void __iomem *ioremap(unsigned long, unsigned long)

shouldn't they all just be that first one?  In other words, wouldn't it be 
better to always provide the generic ioremap prototype and unify the ports 
instead?

  reply	other threads:[~2019-11-06 18:11 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-29  6:48 generic ioremap (and lots of cleanups) v3 Christoph Hellwig
2019-10-29  6:48 ` [PATCH 01/21] arm: remove ioremap_cached Christoph Hellwig
2019-11-11 10:33   ` Arnd Bergmann
2019-10-29  6:48 ` [PATCH 02/21] unicore32: " Christoph Hellwig
2019-10-29  6:48 ` [PATCH 03/21] ia64: rename ioremap_nocache to ioremap_uc Christoph Hellwig
2019-11-11 10:36   ` Arnd Bergmann
2019-10-29  6:48 ` [PATCH 04/21] hexagon: clean up ioremap Christoph Hellwig
2019-10-29  6:48 ` [PATCH 05/21] alpha: remove the unused __ioremap wrapper Christoph Hellwig
2019-10-29  6:48 ` [PATCH 06/21] nios2: remove __ioremap Christoph Hellwig
2019-10-29  6:48 ` [PATCH 07/21] parisc: " Christoph Hellwig
2019-11-05 14:29   ` Helge Deller
2019-10-29  6:48 ` [PATCH 08/21] x86: Clean up ioremap() Christoph Hellwig
2019-10-30 10:39   ` Thomas Gleixner
2019-10-29  6:48 ` [PATCH 09/21] xtensa: clean up ioremap Christoph Hellwig
2019-10-29  6:48 ` [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU Christoph Hellwig
2019-11-06 17:56   ` Palmer Dabbelt
2019-11-11 10:09   ` Arnd Bergmann
2019-11-11 10:15     ` Christoph Hellwig
2019-11-11 10:27       ` Arnd Bergmann
2019-11-11 10:29         ` Christoph Hellwig
2019-11-11 19:33           ` Arnd Bergmann
2019-10-29  6:48 ` [PATCH 11/21] asm-generic: don't provide ioremap for CONFIG_MMU Christoph Hellwig
2019-11-06 18:11   ` Palmer Dabbelt [this message]
2019-11-06 18:16     ` Geert Uytterhoeven
2019-11-06 18:28       ` Christoph Hellwig
2019-11-11 10:31       ` Arnd Bergmann
2019-11-11 10:29   ` Arnd Bergmann
2019-10-29  6:48 ` [PATCH 12/21] arch: rely on asm-generic/io.h for default ioremap_* definitions Christoph Hellwig
2019-11-07 15:29   ` Palmer Dabbelt
2019-11-11 10:10   ` Arnd Bergmann
2019-10-29  6:48 ` [PATCH 13/21] m68k: rename __iounmap and mark it static Christoph Hellwig
2019-10-30  8:51   ` Geert Uytterhoeven
2019-10-29  6:48 ` [PATCH 14/21] hexagon: remove __iounmap Christoph Hellwig
2019-10-29  6:48 ` [PATCH 15/21] nios2: " Christoph Hellwig
2019-10-29  6:48 ` [PATCH 16/21] sh: " Christoph Hellwig
2019-10-29  6:48 ` [PATCH 17/21] lib: provide a simple generic ioremap implementation Christoph Hellwig
2019-11-07 15:29   ` Palmer Dabbelt
2019-11-11 10:10   ` Arnd Bergmann
2019-10-29  6:48 ` [PATCH 18/21] riscv: use the generic ioremap code Christoph Hellwig
2019-10-29  6:48 ` [PATCH 19/21] nds32: use generic ioremap Christoph Hellwig
2019-11-12  8:51   ` Greentime Hu
2019-10-29  6:48 ` [PATCH 20/21] csky: remove ioremap_cache Christoph Hellwig
2019-10-29  6:48 ` [PATCH 21/21] csky: use generic ioremap Christoph Hellwig
2019-11-05  1:31 ` generic ioremap (and lots of cleanups) v3 Christoph Hellwig
2019-11-07 20:47 ` generic-iomap tree for linux-next Christoph Hellwig
2019-11-08  2:20   ` Stephen Rothwell
2019-11-08  4:52     ` Stephen Rothwell
2019-11-08  5:14       ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2019-10-17 17:45 generic ioremap (and lots of cleanups) v2 Christoph Hellwig
2019-10-17 17:45 ` [PATCH 11/21] asm-generic: don't provide ioremap for CONFIG_MMU 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=mhng-33ea9141-2440-4a2d-8133-62094486fc48@palmer-si-x1c4 \
    --to=palmer@dabbelt.com \
    --cc=arnd@arndb.de \
    --cc=deanbo422@gmail.com \
    --cc=green.hu@gmail.com \
    --cc=guoren@kernel.org \
    --cc=gxt@pku.edu.cn \
    --cc=hch@lst.de \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-hexagon@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=monstr@monstr.eu \
    --cc=nios2-dev@lists.rocketboards.org \
    --cc=openrisc@lists.librecores.org \
    --cc=sparclinux@vger.kernel.org \
    --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 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).