($INBOX_DIR/description missing)
 help / color / Atom feed
* Re: [PATCH 07/21] parisc: remove __ioremap
       [not found] ` <20191029064834.23438-8-hch@lst.de>
@ 2019-11-05 14:29   ` Helge Deller
  0 siblings, 0 replies; 23+ messages in thread
From: Helge Deller @ 2019-11-05 14:29 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Arnd Bergmann, Guo Ren, Michal Simek, Greentime Hu, Vincent Chen,
	Guan Xuetao, x86, linux-alpha, linux-snps-arc, linux-arm-kernel,
	linux-hexagon, linux-ia64, linux-m68k, linux-mips, nios2-dev,
	openrisc, linux-parisc, linux-riscv, linux-s390, linux-sh,
	sparclinux, linux-mtd, linux-arch, linux-kernel

On 29.10.19 07:48, Christoph Hellwig wrote:
> __ioremap is always called with the _PAGE_NO_CACHE, so fold the whole
> thing and rename it to ioremap.  This also allows to remove the special
> EISA quirk to force _PAGE_NO_CACHE.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Acked-by: Helge Deller <deller@gmx.de>

Helge

> ---
>  arch/parisc/include/asm/io.h | 11 +----------
>  arch/parisc/mm/ioremap.c     | 10 ++++------
>  2 files changed, 5 insertions(+), 16 deletions(-)
>
> diff --git a/arch/parisc/include/asm/io.h b/arch/parisc/include/asm/io.h
> index 93d37010b375..46212b52c23e 100644
> --- a/arch/parisc/include/asm/io.h
> +++ b/arch/parisc/include/asm/io.h
> @@ -127,16 +127,7 @@ static inline void gsc_writeq(unsigned long long val, unsigned long addr)
>  /*
>   * The standard PCI ioremap interfaces
>   */
> -
> -extern void __iomem * __ioremap(unsigned long offset, unsigned long size, unsigned long flags);
> -
> -/* Most machines react poorly to I/O-space being cacheable... Instead let's
> - * define ioremap() in terms of ioremap_nocache().
> - */
> -static inline void __iomem * ioremap(unsigned long offset, unsigned long size)
> -{
> -	return __ioremap(offset, size, _PAGE_NO_CACHE);
> -}
> +void __iomem *ioremap(unsigned long offset, unsigned long size);
>  #define ioremap_nocache(off, sz)	ioremap((off), (sz))
>  #define ioremap_wc			ioremap_nocache
>  #define ioremap_uc			ioremap_nocache
> diff --git a/arch/parisc/mm/ioremap.c b/arch/parisc/mm/ioremap.c
> index f29f682352f0..6e7c005aa09b 100644
> --- a/arch/parisc/mm/ioremap.c
> +++ b/arch/parisc/mm/ioremap.c
> @@ -25,7 +25,7 @@
>   * have to convert them into an offset in a page-aligned mapping, but the
>   * caller shouldn't need to know that small detail.
>   */
> -void __iomem * __ioremap(unsigned long phys_addr, unsigned long size, unsigned long flags)
> +void __iomem *ioremap(unsigned long phys_addr, unsigned long size)
>  {
>  	void __iomem *addr;
>  	struct vm_struct *area;
> @@ -36,10 +36,8 @@ void __iomem * __ioremap(unsigned long phys_addr, unsigned long size, unsigned l
>  	unsigned long end = phys_addr + size - 1;
>  	/* Support EISA addresses */
>  	if ((phys_addr >= 0x00080000 && end < 0x000fffff) ||
> -	    (phys_addr >= 0x00500000 && end < 0x03bfffff)) {
> +	    (phys_addr >= 0x00500000 && end < 0x03bfffff))
>  		phys_addr |= F_EXTEND(0xfc000000);
> -		flags |= _PAGE_NO_CACHE;
> -	}
>  #endif
>
>  	/* Don't allow wraparound or zero size */
> @@ -65,7 +63,7 @@ void __iomem * __ioremap(unsigned long phys_addr, unsigned long size, unsigned l
>  	}
>
>  	pgprot = __pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_DIRTY |
> -			  _PAGE_ACCESSED | flags);
> +			  _PAGE_ACCESSED | _PAGE_NO_CACHE);
>
>  	/*
>  	 * Mappings have to be page-aligned
> @@ -90,7 +88,7 @@ void __iomem * __ioremap(unsigned long phys_addr, unsigned long size, unsigned l
>
>  	return (void __iomem *) (offset + (char __iomem *)addr);
>  }
> -EXPORT_SYMBOL(__ioremap);
> +EXPORT_SYMBOL(ioremap);
>
>  void iounmap(const volatile void __iomem *io_addr)
>  {
>


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU
       [not found] ` <20191029064834.23438-11-hch@lst.de>
@ 2019-11-06 17:56   ` Palmer Dabbelt
  2019-11-11 10:09   ` Arnd Bergmann
  1 sibling, 0 replies; 23+ messages in thread
From: Palmer Dabbelt @ 2019-11-06 17:56 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Arnd Bergmann, guoren, monstr, green.hu, deanbo422, gxt, x86,
	linux-alpha, linux-snps-arc, linux-arm-kernel, linux-hexagon,
	linux-ia64, linux-m68k, linux-mips, nios2-dev, openrisc,
	linux-parisc, linux-riscv, linux-s390, linux-sh, sparclinux,
	linux-xtensa, linux-mtd, linux-arch, linux-kernel

On Mon, 28 Oct 2019 23:48:23 PDT (-0700), Christoph Hellwig wrote:
> Whatever reason there is for the existence of ioremap_uc, and the fact
> that it returns NULL by default on architectures with an MMU applies
> equally to nommu architectures, so don't provide different defaults.
>
> In practice the difference is meaningless as the only portable driver
> that uses ioremap_uc is atyfb which probably doesn't show up on nommu
> devices.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  include/asm-generic/io.h | 36 ++++++++++++++++--------------------
>  1 file changed, 16 insertions(+), 20 deletions(-)
>
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index d02806513670..a98ed6325727 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -935,18 +935,7 @@ static inline void *phys_to_virt(unsigned long address)
>   * defined your own ioremap_*() variant you must then declare your own
>   * ioremap_*() variant as defined to itself to avoid the default NULL return.
>   */
> -
> -#ifdef CONFIG_MMU
> -
> -#ifndef ioremap_uc
> -#define ioremap_uc ioremap_uc
> -static inline void __iomem *ioremap_uc(phys_addr_t offset, size_t size)
> -{
> -	return NULL;
> -}
> -#endif
> -
> -#else /* !CONFIG_MMU */
> +#ifndef CONFIG_MMU
>
>  /*
>   * Change "struct page" to physical address.
> @@ -980,14 +969,6 @@ static inline void __iomem *ioremap_nocache(phys_addr_t offset, size_t size)
>  }
>  #endif
>
> -#ifndef ioremap_uc
> -#define ioremap_uc ioremap_uc
> -static inline void __iomem *ioremap_uc(phys_addr_t offset, size_t size)
> -{
> -	return ioremap_nocache(offset, size);
> -}
> -#endif
> -
>  #ifndef ioremap_wc
>  #define ioremap_wc ioremap_wc
>  static inline void __iomem *ioremap_wc(phys_addr_t offset, size_t size)
> @@ -1004,6 +985,21 @@ static inline void __iomem *ioremap_wt(phys_addr_t offset, size_t size)
>  }
>  #endif
>
> +/*
> + * ioremap_uc is special in that we do require an explicit architecture
> + * implementation.  In general you do now want to use this function in a

Presumably that's supposed to be "do not want to use"?

> + * driver and use plain ioremap, which is uncached by default.  Similarly
> + * architectures should not implement it unless they have a very good
> + * reason.
> + */
> +#ifndef ioremap_uc
> +#define ioremap_uc ioremap_uc
> +static inline void __iomem *ioremap_uc(phys_addr_t offset, size_t size)
> +{
> +	return NULL;
> +}
> +#endif
> +
>  #ifdef CONFIG_HAS_IOPORT_MAP
>  #ifndef CONFIG_GENERIC_IOMAP
>  #ifndef ioport_map

With the fix:

Reviewed-by: Palmer Dabbelt <palmer@dabbelt.com>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 11/21] asm-generic: don't provide ioremap for CONFIG_MMU
       [not found] ` <20191029064834.23438-12-hch@lst.de>
@ 2019-11-06 18:11   ` Palmer Dabbelt
  2019-11-06 18:16     ` Geert Uytterhoeven
  2019-11-11 10:29   ` Arnd Bergmann
  1 sibling, 1 reply; 23+ messages in thread
From: Palmer Dabbelt @ 2019-11-06 18:11 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Arnd Bergmann, guoren, monstr, green.hu, deanbo422, gxt, x86,
	linux-alpha, linux-snps-arc, linux-arm-kernel, linux-hexagon,
	linux-ia64, linux-m68k, linux-mips, nios2-dev, openrisc,
	linux-parisc, linux-riscv, linux-s390, linux-sh, sparclinux,
	linux-xtensa, linux-mtd, linux-arch, linux-kernel

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?

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 11/21] asm-generic: don't provide ioremap for CONFIG_MMU
  2019-11-06 18:11   ` [PATCH 11/21] asm-generic: don't provide ioremap for CONFIG_MMU Palmer Dabbelt
@ 2019-11-06 18:16     ` Geert Uytterhoeven
  2019-11-06 18:28       ` Christoph Hellwig
  2019-11-11 10:31       ` Arnd Bergmann
  0 siblings, 2 replies; 23+ messages in thread
From: Geert Uytterhoeven @ 2019-11-06 18:16 UTC (permalink / raw)
  To: Palmer Dabbelt
  Cc: Christoph Hellwig, linux-ia64, Linux-sh list,
	Linux Kernel Mailing List, Guo Ren, sparclinux, linux-riscv,
	Vincent Chen, Linux-Arch, linux-s390,
	open list:QUALCOMM HEXAGON...,
	the arch/x86 maintainers, arcml, linux-xtensa, Arnd Bergmann,
	linux-m68k, Openrisc, Greentime Hu, MTD Maling List, Guan Xuetao,
	Linux ARM, Michal Simek, Parisc List, linux-mips, alpha,
	nios2-dev

Hi Palmer,

On Wed, Nov 6, 2019 at 7:11 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> 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?

Agreed. But I'd go for the second one.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 11/21] asm-generic: don't provide ioremap for CONFIG_MMU
  2019-11-06 18:16     ` Geert Uytterhoeven
@ 2019-11-06 18:28       ` Christoph Hellwig
  2019-11-11 10:31       ` Arnd Bergmann
  1 sibling, 0 replies; 23+ messages in thread
From: Christoph Hellwig @ 2019-11-06 18:28 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Palmer Dabbelt, Christoph Hellwig, linux-ia64, Linux-sh list,
	Linux Kernel Mailing List, Guo Ren, sparclinux, linux-riscv,
	Vincent Chen, Linux-Arch, linux-s390,
	open list:QUALCOMM HEXAGON...,
	the arch/x86 maintainers, arcml, linux-xtensa, Arnd Bergmann,
	linux-m68k, Openrisc, Greentime Hu, MTD Maling List, Guan Xuetao,
	Linux ARM, Michal Simek, Parisc List, linux-mips, alpha,
	nios2-dev

On Wed, Nov 06, 2019 at 07:16:38PM +0100, Geert Uytterhoeven wrote:
> > 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?
> 
> Agreed. But I'd go for the second one.

Eventually we should unify it and only have a single prototype.
But we have lots of implementations including inline functions, so
this will take a few more steps.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 12/21] arch: rely on asm-generic/io.h for default ioremap_* definitions
       [not found] ` <20191029064834.23438-13-hch@lst.de>
@ 2019-11-07 15:29   ` Palmer Dabbelt
  2019-11-11 10:10   ` Arnd Bergmann
  1 sibling, 0 replies; 23+ messages in thread
From: Palmer Dabbelt @ 2019-11-07 15:29 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Arnd Bergmann, guoren, monstr, green.hu, deanbo422, gxt, x86,
	linux-alpha, linux-snps-arc, linux-arm-kernel, linux-hexagon,
	linux-ia64, linux-m68k, linux-mips, nios2-dev, openrisc,
	linux-parisc, linux-riscv, linux-s390, linux-sh, sparclinux,
	linux-xtensa, linux-mtd, linux-arch, linux-kernel

On Mon, 28 Oct 2019 23:48:25 PDT (-0700), Christoph Hellwig wrote:
> Various architectures that use asm-generic/io.h still defined their
> own default versions of ioremap_nocache, ioremap_wt and ioremap_wc
> that point back to plain ioremap directly or indirectly.  Remove these
> definitions and rely on asm-generic/io.h instead.  For this to work
> the backup ioremap_* defintions needs to be changed to purely cpp
> macros instea of inlines to cover for architectures like openrisc
> that only define ioremap after including <asm-generic/io.h>.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  arch/arc/include/asm/io.h        |  4 ----
>  arch/arm/include/asm/io.h        |  1 -
>  arch/arm64/include/asm/io.h      |  2 --
>  arch/csky/include/asm/io.h       |  1 -
>  arch/ia64/include/asm/io.h       |  1 -
>  arch/microblaze/include/asm/io.h |  3 ---
>  arch/nios2/include/asm/io.h      |  4 ----
>  arch/openrisc/include/asm/io.h   |  1 -
>  arch/riscv/include/asm/io.h      | 10 ----------
>  arch/s390/include/asm/io.h       |  4 ----
>  arch/x86/include/asm/io.h        |  1 -
>  arch/xtensa/include/asm/io.h     |  4 ----
>  include/asm-generic/io.h         | 18 +++---------------
>  13 files changed, 3 insertions(+), 51 deletions(-)
>
> diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
> index 72f7929736f8..8f777d6441a5 100644
> --- a/arch/arc/include/asm/io.h
> +++ b/arch/arc/include/asm/io.h
> @@ -34,10 +34,6 @@ static inline void ioport_unmap(void __iomem *addr)
>
>  extern void iounmap(const void __iomem *addr);
>
> -#define ioremap_nocache(phy, sz)	ioremap(phy, sz)
> -#define ioremap_wc(phy, sz)		ioremap(phy, sz)
> -#define ioremap_wt(phy, sz)		ioremap(phy, sz)
> -
>  /*
>   * io{read,write}{16,32}be() macros
>   */
> diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
> index 924f9dd502ed..aefdabdbeb84 100644
> --- a/arch/arm/include/asm/io.h
> +++ b/arch/arm/include/asm/io.h
> @@ -392,7 +392,6 @@ static inline void memcpy_toio(volatile void __iomem *to, const void *from,
>   */
>  void __iomem *ioremap(resource_size_t res_cookie, size_t size);
>  #define ioremap ioremap
> -#define ioremap_nocache ioremap
>
>  /*
>   * Do not use ioremap_cache for mapping memory. Use memremap instead.
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 323cb306bd28..4e531f57147d 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -167,9 +167,7 @@ extern void iounmap(volatile void __iomem *addr);
>  extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
>
>  #define ioremap(addr, size)		__ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRE))
> -#define ioremap_nocache(addr, size)	__ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRE))
>  #define ioremap_wc(addr, size)		__ioremap((addr), (size), __pgprot(PROT_NORMAL_NC))
> -#define ioremap_wt(addr, size)		__ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRE))
>
>  /*
>   * PCI configuration space mapping function.
> diff --git a/arch/csky/include/asm/io.h b/arch/csky/include/asm/io.h
> index 80d071e2567f..a4b9fb616faa 100644
> --- a/arch/csky/include/asm/io.h
> +++ b/arch/csky/include/asm/io.h
> @@ -42,7 +42,6 @@ extern void iounmap(void *addr);
>
>  #define ioremap(addr, size)		__ioremap((addr), (size), pgprot_noncached(PAGE_KERNEL))
>  #define ioremap_wc(addr, size)		__ioremap((addr), (size), pgprot_writecombine(PAGE_KERNEL))
> -#define ioremap_nocache(addr, size)	ioremap((addr), (size))
>  #define ioremap_cache			ioremap_cache
>
>  #include <asm-generic/io.h>
> diff --git a/arch/ia64/include/asm/io.h b/arch/ia64/include/asm/io.h
> index fec9df9609ed..3d666a11a2de 100644
> --- a/arch/ia64/include/asm/io.h
> +++ b/arch/ia64/include/asm/io.h
> @@ -263,7 +263,6 @@ static inline void __iomem * ioremap_cache (unsigned long phys_addr, unsigned lo
>  	return ioremap(phys_addr, size);
>  }
>  #define ioremap ioremap
> -#define ioremap_nocache ioremap
>  #define ioremap_cache ioremap_cache
>  #define ioremap_uc ioremap_uc
>  #define iounmap iounmap
> diff --git a/arch/microblaze/include/asm/io.h b/arch/microblaze/include/asm/io.h
> index 86c95b2a1ce1..d33c61737b8b 100644
> --- a/arch/microblaze/include/asm/io.h
> +++ b/arch/microblaze/include/asm/io.h
> @@ -39,9 +39,6 @@ extern resource_size_t isa_mem_base;
>  extern void iounmap(volatile void __iomem *addr);
>
>  extern void __iomem *ioremap(phys_addr_t address, unsigned long size);
> -#define ioremap_nocache(addr, size)		ioremap((addr), (size))
> -#define ioremap_wc(addr, size)			ioremap((addr), (size))
> -#define ioremap_wt(addr, size)			ioremap((addr), (size))
>
>  #endif /* CONFIG_MMU */
>
> diff --git a/arch/nios2/include/asm/io.h b/arch/nios2/include/asm/io.h
> index 74ab34aa6731..d108937c321e 100644
> --- a/arch/nios2/include/asm/io.h
> +++ b/arch/nios2/include/asm/io.h
> @@ -33,10 +33,6 @@ static inline void iounmap(void __iomem *addr)
>  	__iounmap(addr);
>  }
>
> -#define ioremap_nocache ioremap
> -#define ioremap_wc ioremap
> -#define ioremap_wt ioremap
> -
>  /* Pages to physical address... */
>  #define page_to_phys(page)	virt_to_phys(page_to_virt(page))
>
> diff --git a/arch/openrisc/include/asm/io.h b/arch/openrisc/include/asm/io.h
> index 5b81a96ab85e..e18f038b2a6d 100644
> --- a/arch/openrisc/include/asm/io.h
> +++ b/arch/openrisc/include/asm/io.h
> @@ -25,7 +25,6 @@
>  #define PIO_OFFSET		0
>  #define PIO_MASK		0
>
> -#define ioremap_nocache ioremap
>  #include <asm-generic/io.h>
>  #include <asm/pgtable.h>
>
> diff --git a/arch/riscv/include/asm/io.h b/arch/riscv/include/asm/io.h
> index fc1189ad3777..c1de6875cc77 100644
> --- a/arch/riscv/include/asm/io.h
> +++ b/arch/riscv/include/asm/io.h
> @@ -15,16 +15,6 @@
>  #include <asm/mmiowb.h>
>
>  extern void __iomem *ioremap(phys_addr_t offset, unsigned long size);
> -
> -/*
> - * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't
> - * change the properties of memory regions.  This should be fixed by the
> - * upcoming platform spec.
> - */
> -#define ioremap_nocache(addr, size) ioremap((addr), (size))
> -#define ioremap_wc(addr, size) ioremap((addr), (size))
> -#define ioremap_wt(addr, size) ioremap((addr), (size))
> -
>  extern void iounmap(volatile void __iomem *addr);
>
>  /* Generic IO read/write.  These perform native-endian accesses. */
> diff --git a/arch/s390/include/asm/io.h b/arch/s390/include/asm/io.h
> index ca421614722f..5a16f500515a 100644
> --- a/arch/s390/include/asm/io.h
> +++ b/arch/s390/include/asm/io.h
> @@ -26,10 +26,6 @@ void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr);
>
>  #define IO_SPACE_LIMIT 0
>
> -#define ioremap_nocache(addr, size)	ioremap(addr, size)
> -#define ioremap_wc			ioremap_nocache
> -#define ioremap_wt			ioremap_nocache
> -
>  void __iomem *ioremap(unsigned long offset, unsigned long size);
>  void iounmap(volatile void __iomem *addr);
>
> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> index 6b5cc41319a7..9997521fc5cd 100644
> --- a/arch/x86/include/asm/io.h
> +++ b/arch/x86/include/asm/io.h
> @@ -205,7 +205,6 @@ extern void __iomem *ioremap_encrypted(resource_size_t phys_addr, unsigned long
>   */
>  void __iomem *ioremap(resource_size_t offset, unsigned long size);
>  #define ioremap ioremap
> -#define ioremap_nocache ioremap
>
>  extern void iounmap(volatile void __iomem *addr);
>  #define iounmap iounmap
> diff --git a/arch/xtensa/include/asm/io.h b/arch/xtensa/include/asm/io.h
> index 441fb56926a7..54188e69b988 100644
> --- a/arch/xtensa/include/asm/io.h
> +++ b/arch/xtensa/include/asm/io.h
> @@ -52,10 +52,6 @@ static inline void __iomem *ioremap_cache(unsigned long offset,
>  }
>  #define ioremap_cache ioremap_cache
>
> -#define ioremap_nocache ioremap
> -#define ioremap_wc ioremap
> -#define ioremap_wt ioremap
> -
>  static inline void iounmap(volatile void __iomem *addr)
>  {
>  	unsigned long va = (unsigned long) addr;
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index 6a5edc23afe2..4e45e1cb6560 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -949,27 +949,15 @@ static inline void iounmap(void __iomem *addr)
>  #endif /* CONFIG_MMU */
>
>  #ifndef ioremap_nocache
> -#define ioremap_nocache ioremap_nocache
> -static inline void __iomem *ioremap_nocache(phys_addr_t offset, size_t size)
> -{
> -	return ioremap(offset, size);
> -}
> +#define ioremap_nocache ioremap
>  #endif
>
>  #ifndef ioremap_wc
> -#define ioremap_wc ioremap_wc
> -static inline void __iomem *ioremap_wc(phys_addr_t offset, size_t size)
> -{
> -	return ioremap_nocache(offset, size);
> -}
> +#define ioremap_wc ioremap
>  #endif
>
>  #ifndef ioremap_wt
> -#define ioremap_wt ioremap_wt
> -static inline void __iomem *ioremap_wt(phys_addr_t offset, size_t size)
> -{
> -	return ioremap_nocache(offset, size);
> -}
> +#define ioremap_wt ioremap
>  #endif
>
>  /*

Reviewed-by: Palmer Dabbelt <palmer@dabbelt.com>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 17/21] lib: provide a simple generic ioremap implementation
       [not found] ` <20191029064834.23438-18-hch@lst.de>
@ 2019-11-07 15:29   ` Palmer Dabbelt
  2019-11-11 10:10   ` Arnd Bergmann
  1 sibling, 0 replies; 23+ messages in thread
From: Palmer Dabbelt @ 2019-11-07 15:29 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Arnd Bergmann, guoren, monstr, green.hu, deanbo422, gxt, x86,
	linux-alpha, linux-snps-arc, linux-arm-kernel, linux-hexagon,
	linux-ia64, linux-m68k, linux-mips, nios2-dev, openrisc,
	linux-parisc, linux-riscv, linux-s390, linux-sh, sparclinux,
	linux-xtensa, linux-mtd, linux-arch, linux-kernel

On Mon, 28 Oct 2019 23:48:30 PDT (-0700), Christoph Hellwig wrote:
> A lot of architectures reuse the same simple ioremap implementation, so
> start lifting the most simple variant to lib/ioremap.c.  It provides
> ioremap_prot and iounmap, plus a default ioremap that uses prot_noncached,
> although that can be overridden by asm/io.h.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  include/asm-generic/io.h | 20 ++++++++++++++++----
>  lib/Kconfig              |  3 +++
>  lib/ioremap.c            | 39 +++++++++++++++++++++++++++++++++++++++
>  3 files changed, 58 insertions(+), 4 deletions(-)
>
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index 4e45e1cb6560..4a661fdd1937 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -923,9 +923,10 @@ static inline void *phys_to_virt(unsigned long address)
>   * DOC: ioremap() and ioremap_*() variants
>   *
>   * 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.
> + * themselves or rely on GENERIC_IOREMAP.  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.
>   *
>   * ioremap_wc() and ioremap_wt() can provide more relaxed caching attributes
>   * for specific drivers if the architecture choses to implement them.  If they
> @@ -946,7 +947,18 @@ static inline void iounmap(void __iomem *addr)
>  {
>  }
>  #endif
> -#endif /* CONFIG_MMU */
> +#elif defined(CONFIG_GENERIC_IOREMAP)
> +#include <asm/pgtable.h>
> +
> +void __iomem *ioremap_prot(phys_addr_t addr, size_t size, unsigned long prot);
> +void iounmap(volatile void __iomem *addr);
> +
> +static inline void __iomem *ioremap(phys_addr_t addr, size_t size)
> +{
> +	/* _PAGE_IOREMAP needs to be supplied by the architecture */
> +	return ioremap_prot(addr, size, _PAGE_IOREMAP);
> +}
> +#endif /* !CONFIG_MMU || CONFIG_GENERIC_IOREMAP */
>
>  #ifndef ioremap_nocache
>  #define ioremap_nocache ioremap
> diff --git a/lib/Kconfig b/lib/Kconfig
> index 183f92a297ca..afc78aaf2b25 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -638,6 +638,9 @@ config STRING_SELFTEST
>
>  endmenu
>
> +config GENERIC_IOREMAP
> +	bool
> +
>  config GENERIC_LIB_ASHLDI3
>  	bool
>
> diff --git a/lib/ioremap.c b/lib/ioremap.c
> index 0a2ffadc6d71..3f0e18543de8 100644
> --- a/lib/ioremap.c
> +++ b/lib/ioremap.c
> @@ -231,3 +231,42 @@ int ioremap_page_range(unsigned long addr,
>
>  	return err;
>  }
> +
> +#ifdef CONFIG_GENERIC_IOREMAP
> +void __iomem *ioremap_prot(phys_addr_t addr, size_t size, unsigned long prot)
> +{
> +	unsigned long offset, vaddr;
> +	phys_addr_t last_addr;
> +	struct vm_struct *area;
> +
> +	/* Disallow wrap-around or zero size */
> +	last_addr = addr + size - 1;
> +	if (!size || last_addr < addr)
> +		return NULL;
> +
> +	/* Page-align mappings */
> +	offset = addr & (~PAGE_MASK);
> +	addr -= offset;
> +	size = PAGE_ALIGN(size + offset);
> +
> +	area = get_vm_area_caller(size, VM_IOREMAP,
> +			__builtin_return_address(0));
> +	if (!area)
> +		return NULL;
> +	vaddr = (unsigned long)area->addr;
> +
> +	if (ioremap_page_range(vaddr, vaddr + size, addr, __pgprot(prot))) {
> +		free_vm_area(area);
> +		return NULL;
> +	}
> +
> +	return (void __iomem *)(vaddr + offset);
> +}
> +EXPORT_SYMBOL(ioremap_prot);
> +
> +void iounmap(volatile void __iomem *addr)
> +{
> +	vunmap((void *)((unsigned long)addr & PAGE_MASK));
> +}
> +EXPORT_SYMBOL(iounmap);
> +#endif /* CONFIG_GENERIC_IOREMAP */

Reviewed-by: Palmer Dabbelt <palmer@dabbelt.com>

Thanks!  This should let us get rid of arch/riscv/mm/ioremap.c.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* generic-iomap tree for linux-next
       [not found] <20191029064834.23438-1-hch@lst.de>
       [not found] ` <20191029064834.23438-8-hch@lst.de>
       [not found] ` <20191029064834.23438-18-hch@lst.de>
@ 2019-11-07 20:47 ` Christoph Hellwig
  2019-11-08  2:20   ` Stephen Rothwell
       [not found] ` <20191029064834.23438-11-hch@lst.de>
                   ` (5 subsequent siblings)
  8 siblings, 1 reply; 23+ messages in thread
From: Christoph Hellwig @ 2019-11-07 20:47 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Arnd Bergmann, Guo Ren, Michal Simek, Greentime Hu, Vincent Chen,
	Guan Xuetao, x86, linux-arch, linux-s390, linux-ia64,
	linux-parisc, linux-sh, linux-hexagon, linux-xtensa, linux-mips,
	linux-kernel, linux-m68k, openrisc, linux-mtd, linux-alpha,
	sparclinux, nios2-dev, linux-riscv, linux-snps-arc,
	linux-arm-kernel

Hi Stephen,

can you add the generic-ioremap tree:

   git://git.infradead.org/users/hch/ioremap.git

to linux-next? 

Thanks!

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: generic-iomap tree for linux-next
  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
  0 siblings, 1 reply; 23+ messages in thread
From: Stephen Rothwell @ 2019-11-08  2:20 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Arnd Bergmann, Guo Ren, Michal Simek, Greentime Hu, Vincent Chen,
	Guan Xuetao, x86, linux-arch, linux-s390, linux-ia64,
	linux-parisc, linux-sh, linux-hexagon, linux-xtensa, linux-mips,
	linux-kernel, linux-m68k, openrisc, linux-mtd, linux-alpha,
	sparclinux, nios2-dev, linux-riscv, linux-snps-arc,
	linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 287 bytes --]

Hi Christoph,

On Thu, 7 Nov 2019 21:47:43 +0100 Christoph Hellwig <hch@lst.de> wrote:
>
> can you add the generic-ioremap tree:
> 
>    git://git.infradead.org/users/hch/ioremap.git
> 
> to linux-next? 

I assume you mean the for-next branch?
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: generic-iomap tree for linux-next
  2019-11-08  2:20   ` Stephen Rothwell
@ 2019-11-08  4:52     ` Stephen Rothwell
  2019-11-08  5:14       ` Christoph Hellwig
  0 siblings, 1 reply; 23+ messages in thread
From: Stephen Rothwell @ 2019-11-08  4:52 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Arnd Bergmann, Guo Ren, Michal Simek, Greentime Hu, Vincent Chen,
	Guan Xuetao, x86, linux-arch, linux-s390, linux-ia64,
	linux-parisc, linux-sh, linux-hexagon, linux-xtensa, linux-mips,
	linux-kernel, linux-m68k, openrisc, linux-mtd, linux-alpha,
	sparclinux, nios2-dev, linux-riscv, linux-snps-arc,
	linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]

Hi Christoph,

On Fri, 8 Nov 2019 13:20:00 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Thu, 7 Nov 2019 21:47:43 +0100 Christoph Hellwig <hch@lst.de> wrote:
> >
> > can you add the generic-ioremap tree:
> > 
> >    git://git.infradead.org/users/hch/ioremap.git
> > 
> > to linux-next?   
> 
> I assume you mean the for-next branch?

With that assumption, added from today.

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgement of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
     * submitted under GPL v2 (or later) and include the Contributor's
        Signed-off-by,
     * posted to the relevant mailing list,
     * reviewed by you (or another maintainer of your subsystem tree),
     * successfully unit tested, and 
     * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

-- 
Cheers,
Stephen Rothwell 
sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: generic-iomap tree for linux-next
  2019-11-08  4:52     ` Stephen Rothwell
@ 2019-11-08  5:14       ` Christoph Hellwig
  0 siblings, 0 replies; 23+ messages in thread
From: Christoph Hellwig @ 2019-11-08  5:14 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christoph Hellwig, Arnd Bergmann, Guo Ren, Michal Simek,
	Greentime Hu, Vincent Chen, Guan Xuetao, x86, linux-arch,
	linux-s390, linux-ia64, linux-parisc, linux-sh, linux-hexagon,
	linux-xtensa, linux-mips, linux-kernel, linux-m68k, openrisc,
	linux-mtd, linux-alpha, sparclinux, nios2-dev, linux-riscv,
	linux-snps-arc, linux-arm-kernel

On Fri, Nov 08, 2019 at 03:52:48PM +1100, Stephen Rothwell wrote:
> Hi Christoph,
> 
> On Fri, 8 Nov 2019 13:20:00 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Thu, 7 Nov 2019 21:47:43 +0100 Christoph Hellwig <hch@lst.de> wrote:
> > >
> > > can you add the generic-ioremap tree:
> > > 
> > >    git://git.infradead.org/users/hch/ioremap.git
> > > 
> > > to linux-next?   
> > 
> > I assume you mean the for-next branch?
> 
> With that assumption, added from today.

Yes, and thanks!

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU
       [not found] ` <20191029064834.23438-11-hch@lst.de>
  2019-11-06 17:56   ` [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU Palmer Dabbelt
@ 2019-11-11 10:09   ` Arnd Bergmann
  2019-11-11 10:15     ` Christoph Hellwig
  1 sibling, 1 reply; 23+ messages in thread
From: Arnd Bergmann @ 2019-11-11 10:09 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Guo Ren, Michal Simek, Greentime Hu, Vincent Chen, Guan Xuetao,
	the arch/x86 maintainers, alpha,
	open list:SYNOPSYS ARC ARCHITECTURE, Linux ARM,
	open list:QUALCOMM HEXAGON...,
	linux-ia64, linux-m68k, linux-mips,
	moderated list:NIOS2 ARCHITECTURE, openrisc, Parisc List,
	linux-riscv, linux-s390, Linux-sh list, sparclinux, linux-xtensa,
	linux-mtd, linux-arch, linux-kernel

On Tue, Oct 29, 2019 at 7:49 AM Christoph Hellwig <hch@lst.de> wrote:
>
> Whatever reason there is for the existence of ioremap_uc, and the fact
> that it returns NULL by default on architectures with an MMU applies
> equally to nommu architectures, so don't provide different defaults.

Makes sense.

> In practice the difference is meaningless as the only portable driver
> that uses ioremap_uc is atyfb which probably doesn't show up on nommu
> devices.



> +/*
> + * ioremap_uc is special in that we do require an explicit architecture
> + * implementation.  In general you do now want to use this function in a
> + * driver and use plain ioremap, which is uncached by default.  Similarly
> + * architectures should not implement it unless they have a very good
> + * reason.
> + */
> +#ifndef ioremap_uc
> +#define ioremap_uc ioremap_uc
> +static inline void __iomem *ioremap_uc(phys_addr_t offset, size_t size)
> +{
> +       return NULL;
> +}
> +#endif

Maybe we could move the definition into the atyfb driver itself?

As I understand it, the difference between ioremap()/ioremap_nocache()
and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5,
Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86,
PentiumIII, Athlon, VIA C7)  those three are meant to be synonyms
anyway.

      Arnd

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 12/21] arch: rely on asm-generic/io.h for default ioremap_* definitions
       [not found] ` <20191029064834.23438-13-hch@lst.de>
  2019-11-07 15:29   ` [PATCH 12/21] arch: rely on asm-generic/io.h for default ioremap_* definitions Palmer Dabbelt
@ 2019-11-11 10:10   ` Arnd Bergmann
  1 sibling, 0 replies; 23+ messages in thread
From: Arnd Bergmann @ 2019-11-11 10:10 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Guo Ren, Michal Simek, Greentime Hu, Vincent Chen, Guan Xuetao,
	the arch/x86 maintainers, alpha,
	open list:SYNOPSYS ARC ARCHITECTURE, Linux ARM,
	open list:QUALCOMM HEXAGON...,
	linux-ia64, linux-m68k, linux-mips,
	moderated list:NIOS2 ARCHITECTURE, openrisc, Parisc List,
	linux-riscv, linux-s390, Linux-sh list, sparclinux, linux-xtensa,
	linux-mtd, linux-arch, linux-kernel

On Tue, Oct 29, 2019 at 7:49 AM Christoph Hellwig <hch@lst.de> wrote:
>
> Various architectures that use asm-generic/io.h still defined their
> own default versions of ioremap_nocache, ioremap_wt and ioremap_wc
> that point back to plain ioremap directly or indirectly.  Remove these
> definitions and rely on asm-generic/io.h instead.  For this to work
> the backup ioremap_* defintions needs to be changed to purely cpp
> macros instea of inlines to cover for architectures like openrisc
> that only define ioremap after including <asm-generic/io.h>.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 17/21] lib: provide a simple generic ioremap implementation
       [not found] ` <20191029064834.23438-18-hch@lst.de>
  2019-11-07 15:29   ` [PATCH 17/21] lib: provide a simple generic ioremap implementation Palmer Dabbelt
@ 2019-11-11 10:10   ` Arnd Bergmann
  1 sibling, 0 replies; 23+ messages in thread
From: Arnd Bergmann @ 2019-11-11 10:10 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Guo Ren, Michal Simek, Greentime Hu, Vincent Chen, Guan Xuetao,
	the arch/x86 maintainers, alpha,
	open list:SYNOPSYS ARC ARCHITECTURE, Linux ARM,
	open list:QUALCOMM HEXAGON...,
	linux-ia64, linux-m68k, linux-mips,
	moderated list:NIOS2 ARCHITECTURE, openrisc, Parisc List,
	linux-riscv, linux-s390, Linux-sh list, sparclinux, linux-xtensa,
	linux-mtd, linux-arch, linux-kernel

On Tue, Oct 29, 2019 at 7:49 AM Christoph Hellwig <hch@lst.de> wrote:
>
> A lot of architectures reuse the same simple ioremap implementation, so
> start lifting the most simple variant to lib/ioremap.c.  It provides
> ioremap_prot and iounmap, plus a default ioremap that uses prot_noncached,
> although that can be overridden by asm/io.h.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU
  2019-11-11 10:09   ` Arnd Bergmann
@ 2019-11-11 10:15     ` Christoph Hellwig
  2019-11-11 10:27       ` Arnd Bergmann
  0 siblings, 1 reply; 23+ messages in thread
From: Christoph Hellwig @ 2019-11-11 10:15 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Christoph Hellwig, Guo Ren, Michal Simek, Greentime Hu,
	Vincent Chen, Guan Xuetao, the arch/x86 maintainers, alpha,
	open list:SYNOPSYS ARC ARCHITECTURE, Linux ARM,
	open list:QUALCOMM HEXAGON...,
	linux-ia64, linux-m68k, linux-mips,
	moderated list:NIOS2 ARCHITECTURE, openrisc, Parisc List,
	linux-riscv, linux-s390, Linux-sh list, sparclinux, linux-xtensa,
	linux-mtd, linux-arch, linux-kernel

On Mon, Nov 11, 2019 at 11:09:05AM +0100, Arnd Bergmann wrote:
> Maybe we could move the definition into the atyfb driver itself?
> 
> As I understand it, the difference between ioremap()/ioremap_nocache()
> and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5,
> Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86,
> PentiumIII, Athlon, VIA C7)  those three are meant to be synonyms
> anyway.

That's not how I understood it.  Based on the code and the UC-
explanation ioremap_uc always overrides the MTRR, which can still
be present on more modern x86 systems.  In fact I remember a patch
floating around very recently adding another ioremap_uc caller in
some Atom platform device driver that works around buggy MTRR
tables.  Also this series actually adds a new override and a few
callers for ia64 platform code, which works very similar to x86
based on the comments in the code.  That being said I'm not sure
the callers in ia64 are really required, but it was the safest thing
to do as part of this cleanup.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU
  2019-11-11 10:15     ` Christoph Hellwig
@ 2019-11-11 10:27       ` Arnd Bergmann
  2019-11-11 10:29         ` Christoph Hellwig
  0 siblings, 1 reply; 23+ messages in thread
From: Arnd Bergmann @ 2019-11-11 10:27 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Guo Ren, Michal Simek, Greentime Hu, Vincent Chen, Guan Xuetao,
	the arch/x86 maintainers, alpha,
	open list:SYNOPSYS ARC ARCHITECTURE, Linux ARM,
	open list:QUALCOMM HEXAGON...,
	linux-ia64, linux-m68k, linux-mips,
	moderated list:NIOS2 ARCHITECTURE, openrisc, Parisc List,
	linux-riscv, linux-s390, Linux-sh list, sparclinux, linux-xtensa,
	linux-mtd, linux-arch, linux-kernel

On Mon, Nov 11, 2019 at 11:15 AM Christoph Hellwig <hch@lst.de> wrote:
>
> On Mon, Nov 11, 2019 at 11:09:05AM +0100, Arnd Bergmann wrote:
> > Maybe we could move the definition into the atyfb driver itself?
> >
> > As I understand it, the difference between ioremap()/ioremap_nocache()
> > and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5,
> > Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86,
> > PentiumIII, Athlon, VIA C7)  those three are meant to be synonyms
> > anyway.
>
> That's not how I understood it.  Based on the code and the UC-
> explanation ioremap_uc always overrides the MTRR, which can still
> be present on more modern x86 systems.

As I understand, the point is that on PAT-enabled systems, the
normal ioremap() *also* overrides the MTRR, citing from
Documentation/x86/pat.rst:

  ====  =======  ===  =========================  =====================
  MTRR  Non-PAT  PAT  Linux ioremap value        Effective memory type
  ====  =======  ===  =========================  =====================
        PAT                                        Non-PAT |  PAT
        |PCD                                               |
        ||PWT                                              |
        |||                                                |
  WC    000      WB   _PAGE_CACHE_MODE_WB             WC   |   WC
  WC    001      WC   _PAGE_CACHE_MODE_WC             WC*  |   WC
  WC    010      UC-  _PAGE_CACHE_MODE_UC_MINUS       WC*  |   UC
  WC    011      UC   _PAGE_CACHE_MODE_UC             UC   |   UC
  ====  =======  ===  =========================  =====================

> In fact I remember a patch
> floating around very recently adding another ioremap_uc caller in
> some Atom platform device driver that works around buggy MTRR
> tables.  Also this series actually adds a new override and a few
> callers for ia64 platform code, which works very similar to x86
> based on the comments in the code.  That being said I'm not sure
> the callers in ia64 are really required, but it was the safest thing
> to do as part of this cleanup.

Ok, fair enough. Let's just go with your version for now, if only to not
hold your series up more. I'd still suggest we change atyfb to only
use ioremap_uc() on i386 and maybe ia64. I can send a patch for that.

      Arnd

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU
  2019-11-11 10:27       ` Arnd Bergmann
@ 2019-11-11 10:29         ` Christoph Hellwig
  2019-11-11 19:33           ` Arnd Bergmann
  0 siblings, 1 reply; 23+ messages in thread
From: Christoph Hellwig @ 2019-11-11 10:29 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Christoph Hellwig, Guo Ren, Michal Simek, Greentime Hu,
	Vincent Chen, Guan Xuetao, the arch/x86 maintainers, alpha,
	open list:SYNOPSYS ARC ARCHITECTURE, Linux ARM,
	open list:QUALCOMM HEXAGON...,
	linux-ia64, linux-m68k, linux-mips,
	moderated list:NIOS2 ARCHITECTURE, openrisc, Parisc List,
	linux-riscv, linux-s390, Linux-sh list, sparclinux, linux-xtensa,
	linux-mtd, linux-arch, linux-kernel

On Mon, Nov 11, 2019 at 11:27:27AM +0100, Arnd Bergmann wrote:
> Ok, fair enough. Let's just go with your version for now, if only to not
> hold your series up more. I'd still suggest we change atyfb to only
> use ioremap_uc() on i386 and maybe ia64. I can send a patch for that.

I don't think we even need it on ia64.  But lets kick off a dicussion
with the atyfb, x86 and ia64 maintainers after this series is in.
Which was kinda my plan anyway.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 11/21] asm-generic: don't provide ioremap for CONFIG_MMU
       [not found] ` <20191029064834.23438-12-hch@lst.de>
  2019-11-06 18:11   ` [PATCH 11/21] asm-generic: don't provide ioremap for CONFIG_MMU Palmer Dabbelt
@ 2019-11-11 10:29   ` Arnd Bergmann
  1 sibling, 0 replies; 23+ messages in thread
From: Arnd Bergmann @ 2019-11-11 10:29 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Guo Ren, Michal Simek, Greentime Hu, Vincent Chen, Guan Xuetao,
	the arch/x86 maintainers, alpha,
	open list:SYNOPSYS ARC ARCHITECTURE, Linux ARM,
	open list:QUALCOMM HEXAGON...,
	linux-ia64, linux-m68k, linux-mips,
	moderated list:NIOS2 ARCHITECTURE, openrisc, Parisc List,
	linux-riscv, linux-s390, Linux-sh list, sparclinux, linux-xtensa,
	linux-mtd, linux-arch, linux-kernel

On Tue, Oct 29, 2019 at 7:49 AM Christoph Hellwig <hch@lst.de> 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>

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 11/21] asm-generic: don't provide ioremap for CONFIG_MMU
  2019-11-06 18:16     ` Geert Uytterhoeven
  2019-11-06 18:28       ` Christoph Hellwig
@ 2019-11-11 10:31       ` Arnd Bergmann
  1 sibling, 0 replies; 23+ messages in thread
From: Arnd Bergmann @ 2019-11-11 10:31 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Palmer Dabbelt, Christoph Hellwig, linux-ia64, Linux-sh list,
	Linux Kernel Mailing List, Guo Ren, sparclinux, linux-riscv,
	Vincent Chen, Linux-Arch, linux-s390,
	open list:QUALCOMM HEXAGON...,
	the arch/x86 maintainers, arcml, linux-xtensa, linux-m68k,
	Openrisc, Greentime Hu, MTD Maling List, Guan Xuetao, Linux ARM,
	Michal Simek, Parisc List, linux-mips, alpha,
	moderated list:NIOS2 ARCHITECTURE

On Wed, Nov 6, 2019 at 7:16 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Palmer,
>
> On Wed, Nov 6, 2019 at 7:11 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> > 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?
>
> Agreed. But I'd go for the second one.

Right, phys_addr_t is the correct type here, resource_size_t is just a generic
type that is at least as long as any resource, and usually the same as
phys_addr_t, which is supposed to be used for physical addresses.

      Arnd

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 01/21] arm: remove ioremap_cached
       [not found] ` <20191029064834.23438-2-hch@lst.de>
@ 2019-11-11 10:33   ` Arnd Bergmann
  0 siblings, 0 replies; 23+ messages in thread
From: Arnd Bergmann @ 2019-11-11 10:33 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Guo Ren, Michal Simek, Greentime Hu, Vincent Chen, Guan Xuetao,
	the arch/x86 maintainers, alpha,
	open list:SYNOPSYS ARC ARCHITECTURE, Linux ARM,
	open list:QUALCOMM HEXAGON...,
	linux-ia64, linux-m68k, linux-mips,
	moderated list:NIOS2 ARCHITECTURE, openrisc, Parisc List,
	linux-riscv, linux-s390, Linux-sh list, sparclinux, linux-xtensa,
	linux-mtd, linux-arch, linux-kernel

On Tue, Oct 29, 2019 at 7:48 AM Christoph Hellwig <hch@lst.de> wrote:
>
> No users of ioremap_cached are left, remove it.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 03/21] ia64: rename ioremap_nocache to ioremap_uc
       [not found] ` <20191029064834.23438-4-hch@lst.de>
@ 2019-11-11 10:36   ` Arnd Bergmann
  0 siblings, 0 replies; 23+ messages in thread
From: Arnd Bergmann @ 2019-11-11 10:36 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Guo Ren, Michal Simek, Greentime Hu, Vincent Chen, Guan Xuetao,
	the arch/x86 maintainers, alpha,
	open list:SYNOPSYS ARC ARCHITECTURE, Linux ARM,
	open list:QUALCOMM HEXAGON...,
	linux-ia64, linux-m68k, linux-mips,
	moderated list:NIOS2 ARCHITECTURE, openrisc, Parisc List,
	linux-riscv, linux-s390, Linux-sh list, sparclinux, linux-xtensa,
	linux-mtd, linux-arch, linux-kernel

On Tue, Oct 29, 2019 at 7:48 AM Christoph Hellwig <hch@lst.de> wrote:
>
> On ia64 ioremap_nocache fails if attributes don't match.  Not other
> architectures does this, and we plan to get rid of ioremap_nocache.
> So get rid of the special semantics and define ioremap_nocache in
> terms of ioremap as no portable driver could rely on the behavior
> anyway.
>
> However x86 implements ioremap_uc in a similar way as the ia64
> version of ioremap_nocache, in that it ignores the firmware tables.
> Switch ia64 to override ioremap_uc instead.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Good idea,

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU
  2019-11-11 10:29         ` Christoph Hellwig
@ 2019-11-11 19:33           ` Arnd Bergmann
  0 siblings, 0 replies; 23+ messages in thread
From: Arnd Bergmann @ 2019-11-11 19:33 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Guo Ren, Michal Simek, Greentime Hu, Vincent Chen, Guan Xuetao,
	the arch/x86 maintainers, alpha,
	open list:SYNOPSYS ARC ARCHITECTURE, Linux ARM,
	open list:QUALCOMM HEXAGON...,
	linux-ia64, linux-m68k, linux-mips,
	moderated list:NIOS2 ARCHITECTURE, openrisc, Parisc List,
	linux-riscv, linux-s390, Linux-sh list, sparclinux, linux-xtensa,
	linux-mtd, linux-arch, linux-kernel

On Mon, Nov 11, 2019 at 11:29 AM Christoph Hellwig <hch@lst.de> wrote:
>
> On Mon, Nov 11, 2019 at 11:27:27AM +0100, Arnd Bergmann wrote:
> > Ok, fair enough. Let's just go with your version for now, if only to not
> > hold your series up more. I'd still suggest we change atyfb to only
> > use ioremap_uc() on i386 and maybe ia64. I can send a patch for that.
>
> I don't think we even need it on ia64.  But lets kick off a dicussion
> with the atyfb, x86 and ia64 maintainers after this series is in.
> Which was kinda my plan anyway.

I missed your reply and already sent my patch now. I guess it doesn't
hurt to discuss that in parallel. Anyway I think that this patch is the
last one you want an Ack from me for (let me know if I missed one), so

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH 19/21] nds32: use generic ioremap
       [not found] ` <20191029064834.23438-20-hch@lst.de>
@ 2019-11-12  8:51   ` Greentime Hu
  0 siblings, 0 replies; 23+ messages in thread
From: Greentime Hu @ 2019-11-12  8:51 UTC (permalink / raw)
  To: Christoph Hellwig, Nickhu, alankao
  Cc: Arnd Bergmann, Guo Ren, Michal Simek, Vincent Chen, Guan Xuetao,
	x86, linux-alpha, linux-snps-arc, linux-arm-kernel,
	linux-hexagon, linux-ia64, linux-m68k, linux-mips, nios2-dev,
	openrisc, linux-parisc, linux-riscv, linux-s390, linux-sh,
	sparclinux, linux-xtensa, linux-mtd, linux-arch,
	Linux Kernel Mailing List

Hi,

Christoph Hellwig <hch@lst.de> 於 2019年10月29日 週二 下午2:49寫道:
>
> Use the generic ioremap_prot and iounmap helpers.
>
> Note that the io.h include in pgtable.h had to be removed to not create
> an include loop.  As far as I can tell there was no need for it to
> start with.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  arch/nds32/Kconfig               |  1 +
>  arch/nds32/include/asm/io.h      |  3 +-
>  arch/nds32/include/asm/pgtable.h |  4 ++-
>  arch/nds32/mm/Makefile           |  3 +-
>  arch/nds32/mm/ioremap.c          | 62 --------------------------------
>  5 files changed, 6 insertions(+), 67 deletions(-)
>  delete mode 100644 arch/nds32/mm/ioremap.c
>
> diff --git a/arch/nds32/Kconfig b/arch/nds32/Kconfig
> index fbd68329737f..12c06a833b7c 100644
> --- a/arch/nds32/Kconfig
> +++ b/arch/nds32/Kconfig
> @@ -20,6 +20,7 @@ config NDS32
>         select GENERIC_CLOCKEVENTS
>         select GENERIC_IRQ_CHIP
>         select GENERIC_IRQ_SHOW
> +       select GENERIC_IOREMAP
>         select GENERIC_LIB_ASHLDI3
>         select GENERIC_LIB_ASHRDI3
>         select GENERIC_LIB_CMPDI2
> diff --git a/arch/nds32/include/asm/io.h b/arch/nds32/include/asm/io.h
> index fb0e8a24c7af..e57378d04006 100644
> --- a/arch/nds32/include/asm/io.h
> +++ b/arch/nds32/include/asm/io.h
> @@ -6,8 +6,6 @@
>
>  #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,6 +78,7 @@ static inline u32 __raw_readl(const volatile void __iomem *addr)
>  #define writeb(v,c)    ({ __iowmb(); writeb_relaxed((v),(c)); })
>  #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/nds32/include/asm/pgtable.h b/arch/nds32/include/asm/pgtable.h
> index 0588ec99725c..6fbf251cfc26 100644
> --- a/arch/nds32/include/asm/pgtable.h
> +++ b/arch/nds32/include/asm/pgtable.h
> @@ -12,7 +12,6 @@
>  #include <asm/nds32.h>
>  #ifndef __ASSEMBLY__
>  #include <asm/fixmap.h>
> -#include <asm/io.h>
>  #include <nds32_intrinsic.h>
>  #endif
>
> @@ -130,6 +129,9 @@ extern void __pgd_error(const char *file, int line, unsigned long val);
>  #define _PAGE_CACHE            _PAGE_C_MEM_WB
>  #endif
>
> +#define _PAGE_IOREMAP \
> +       (_PAGE_V | _PAGE_M_KRW | _PAGE_D | _PAGE_G | _PAGE_C_DEV)
> +
>  /*
>   * + Level 1 descriptor (PMD)
>   */
> diff --git a/arch/nds32/mm/Makefile b/arch/nds32/mm/Makefile
> index bd360e4583b5..897ecaf5cf54 100644
> --- a/arch/nds32/mm/Makefile
> +++ b/arch/nds32/mm/Makefile
> @@ -1,6 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0-only
> -obj-y                          := extable.o tlb.o \
> -                                  fault.o init.o ioremap.o mmap.o \
> +obj-y                          := extable.o tlb.o fault.o init.o mmap.o \
>                                     mm-nds32.o cacheflush.o proc.o
>
>  obj-$(CONFIG_ALIGNMENT_TRAP)   += alignment.o
> diff --git a/arch/nds32/mm/ioremap.c b/arch/nds32/mm/ioremap.c
> deleted file mode 100644
> index 690140bb23a2..000000000000
> --- a/arch/nds32/mm/ioremap.c
> +++ /dev/null
> @@ -1,62 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -// Copyright (C) 2005-2017 Andes Technology Corporation
> -
> -#include <linux/vmalloc.h>
> -#include <linux/io.h>
> -#include <linux/mm.h>
> -#include <asm/pgtable.h>
> -
> -void __iomem *ioremap(phys_addr_t phys_addr, size_t size);
> -
> -static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size,
> -                                     void *caller)
> -{
> -       struct vm_struct *area;
> -       unsigned long addr, offset, last_addr;
> -       pgprot_t prot;
> -
> -       /* Don't allow wraparound or zero size */
> -       last_addr = phys_addr + size - 1;
> -       if (!size || last_addr < phys_addr)
> -               return NULL;
> -
> -       /*
> -        * Mappings have to be page-aligned
> -        */
> -       offset = phys_addr & ~PAGE_MASK;
> -       phys_addr &= PAGE_MASK;
> -       size = PAGE_ALIGN(last_addr + 1) - phys_addr;
> -
> -       /*
> -        * Ok, go for it..
> -        */
> -       area = get_vm_area_caller(size, VM_IOREMAP, caller);
> -       if (!area)
> -               return NULL;
> -
> -       area->phys_addr = phys_addr;
> -       addr = (unsigned long)area->addr;
> -       prot = __pgprot(_PAGE_V | _PAGE_M_KRW | _PAGE_D |
> -                       _PAGE_G | _PAGE_C_DEV);
> -       if (ioremap_page_range(addr, addr + size, phys_addr, prot)) {
> -               vunmap((void *)addr);
> -               return NULL;
> -       }
> -       return (__force void __iomem *)(offset + (char *)addr);
> -
> -}
> -
> -void __iomem *ioremap(phys_addr_t phys_addr, size_t size)
> -{
> -       return __ioremap_caller(phys_addr, size,
> -                               __builtin_return_address(0));
> -}
> -
> -EXPORT_SYMBOL(ioremap);
> -
> -void iounmap(volatile void __iomem * addr)
> -{
> -       vunmap((void *)(PAGE_MASK & (unsigned long)addr));
> -}
> -
> -EXPORT_SYMBOL(iounmap);

Acked-by: Greentime Hu <green.hu@gmail.com>
Looks good to me.

^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, back to index

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20191029064834.23438-1-hch@lst.de>
     [not found] ` <20191029064834.23438-8-hch@lst.de>
2019-11-05 14:29   ` [PATCH 07/21] parisc: remove __ioremap Helge Deller
     [not found] ` <20191029064834.23438-18-hch@lst.de>
2019-11-07 15:29   ` [PATCH 17/21] lib: provide a simple generic ioremap implementation Palmer Dabbelt
2019-11-11 10:10   ` Arnd Bergmann
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
     [not found] ` <20191029064834.23438-11-hch@lst.de>
2019-11-06 17:56   ` [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU 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
     [not found] ` <20191029064834.23438-13-hch@lst.de>
2019-11-07 15:29   ` [PATCH 12/21] arch: rely on asm-generic/io.h for default ioremap_* definitions Palmer Dabbelt
2019-11-11 10:10   ` Arnd Bergmann
     [not found] ` <20191029064834.23438-12-hch@lst.de>
2019-11-06 18:11   ` [PATCH 11/21] asm-generic: don't provide ioremap for CONFIG_MMU Palmer Dabbelt
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
     [not found] ` <20191029064834.23438-2-hch@lst.de>
2019-11-11 10:33   ` [PATCH 01/21] arm: remove ioremap_cached Arnd Bergmann
     [not found] ` <20191029064834.23438-4-hch@lst.de>
2019-11-11 10:36   ` [PATCH 03/21] ia64: rename ioremap_nocache to ioremap_uc Arnd Bergmann
     [not found] ` <20191029064834.23438-20-hch@lst.de>
2019-11-12  8:51   ` [PATCH 19/21] nds32: use generic ioremap Greentime Hu

($INBOX_DIR/description missing)

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-m68k/0 linux-m68k/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-m68k linux-m68k/ https://lore.kernel.org/linux-m68k \
		linux-m68k@vger.kernel.org
	public-inbox-index linux-m68k

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-m68k


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git