linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v3 0/2] arch/*/io.h: remove ioremap_uc in some architectures
@ 2023-03-03 10:28 Baoquan He
  2023-03-03 10:28 ` [PATCH v3 1/2] mips: add <asm-generic/io.h> including Baoquan He
  2023-03-03 10:28 ` [PATCH v3 2/2] arch/*/io.h: remove ioremap_uc in some architectures Baoquan He
  0 siblings, 2 replies; 11+ messages in thread
From: Baoquan He @ 2023-03-03 10:28 UTC (permalink / raw)
  To: linux-kernel; +Cc: linux-arch, linux-mm, arnd, geert, mcgrof, hch, Baoquan He

This patchset tries to remove ioremap_uc() in the current architectures
except of x86 and ia64. They will use the default ioremap_uc definition
in <asm-generic/io.h> which returns NULL. If any arch sees a breakage
caused by the default ioremap_uc(), it can provide a sepcific one for its
own usage. This is done in patch 2.

To get rid of all of them other than x86 and ia64, add asm-generic/io.h
to asm/io.h of mips ARCH. With this adding, we can get rid of the
ioremap_uc() in mips too. Adding asm-generic/io.h is done in patch 1.

v2->v3:
  - In patch 1, move those macro definition of functio near its function 
    declaration according to Arnd's suggestion. And remove the unneeded
    change in asm/mmiowb.h introduced in old version.
  - In patch 2, clean up and rewrite the messy document related to
    ioremap_uc() in Documentation/driver-api/device-io.rst.
v1->v2:
  - Update log of patch 2, and document related to ioremap_uc()
    according to Geert's comment.
  - Add Geert's Acked-by.

Baoquan He (2):
  mips: add <asm-generic/io.h> including
  arch/*/io.h: remove ioremap_uc in some architectures

 Documentation/driver-api/device-io.rst | 14 +++--
 arch/alpha/include/asm/io.h            |  1 -
 arch/hexagon/include/asm/io.h          |  3 -
 arch/m68k/include/asm/kmap.h           |  1 -
 arch/mips/include/asm/io.h             | 79 +++++++++++++++++++++++---
 arch/parisc/include/asm/io.h           |  2 -
 arch/powerpc/include/asm/io.h          |  1 -
 arch/sh/include/asm/io.h               |  2 -
 arch/sparc/include/asm/io_64.h         |  1 -
 9 files changed, 79 insertions(+), 25 deletions(-)

-- 
2.34.1


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

* [PATCH v3 1/2] mips: add <asm-generic/io.h> including
  2023-03-03 10:28 [PATCH v3 0/2] arch/*/io.h: remove ioremap_uc in some architectures Baoquan He
@ 2023-03-03 10:28 ` Baoquan He
  2023-03-03 12:40   ` Arnd Bergmann
  2023-03-03 10:28 ` [PATCH v3 2/2] arch/*/io.h: remove ioremap_uc in some architectures Baoquan He
  1 sibling, 1 reply; 11+ messages in thread
From: Baoquan He @ 2023-03-03 10:28 UTC (permalink / raw)
  To: linux-kernel
  Cc: linux-arch, linux-mm, arnd, geert, mcgrof, hch, Baoquan He,
	Thomas Bogendoerfer, Helge Deller, Serge Semin, Florian Fainelli,
	Huacai Chen, Jiaxun Yang, linux-mips

With the adding, some default ioremap_xx methods defined in
asm-generic/io.h can be used. E.g the default ioremap_uc() returning
NULL.

Signed-off-by: Baoquan He <bhe@redhat.com>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Helge Deller <deller@gmx.de>
Cc: Serge Semin <fancer.lancer@gmail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Huacai Chen <chenhuacai@kernel.org>
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: linux-mips@vger.kernel.org
---
 arch/mips/include/asm/io.h | 78 ++++++++++++++++++++++++++++++++++----
 1 file changed, 70 insertions(+), 8 deletions(-)

diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index cec8347f0b85..6756baadba6c 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -126,6 +126,7 @@ static inline phys_addr_t virt_to_phys(const volatile void *x)
  *     almost all conceivable cases a device driver should not be using
  *     this function
  */
+#define phys_to_virt phys_to_virt
 static inline void * phys_to_virt(unsigned long address)
 {
 	return __va(address);
@@ -359,6 +360,27 @@ __BUILD_MEMORY_PFX(__raw_, q, u64, 0)
 __BUILD_MEMORY_PFX(__mem_, q, u64, 0)
 #endif
 
+#define readb readb
+#define readw readw
+#define readl readl
+#define writeb writeb
+#define writew writew
+#define writel writel
+
+#ifdef CONFIG_64BIT
+#define readq readq
+#define writeq writeq
+#define __raw_readq __raw_readq
+#define __raw_writeq __raw_writeq
+#endif
+
+#define __raw_readb __raw_readb
+#define __raw_readw __raw_readw
+#define __raw_readl __raw_readl
+#define __raw_writeb __raw_writeb
+#define __raw_writew __raw_writew
+#define __raw_writel __raw_writel
+
 #define __BUILD_IOPORT_PFX(bus, bwlq, type)				\
 	__BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0,)			\
 	__BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0, _p)
@@ -374,6 +396,27 @@ BUILDIO_IOPORT(l, u32)
 BUILDIO_IOPORT(q, u64)
 #endif
 
+#define inb inb
+#define inw inw
+#define inl inl
+#define inb_p inb_p
+#define inw_p inw_p
+#define inl_p inl_p
+
+#define outb outb
+#define outw outw
+#define outl outl
+#define outb_p outb_p
+#define outw_p outw_p
+#define outl_p outl_p
+
+#ifdef CONFIG_64BIT
+#define inq inq
+#define outq outq
+#define inq_p inq_p
+#define outq_p outq_p
+#endif
+
 #define __BUILDIO(bwlq, type)						\
 									\
 __BUILD_MEMORY_SINGLE(____raw_, bwlq, type, 1, 0, 0)
@@ -412,14 +455,6 @@ __BUILDIO(q, u64)
 #define writeq_be(val, addr)						\
 	__raw_writeq(cpu_to_be64((val)), (__force unsigned *)(addr))
 
-/*
- * Some code tests for these symbols
- */
-#ifdef CONFIG_64BIT
-#define readq				readq
-#define writeq				writeq
-#endif
-
 #define __BUILD_MEMORY_STRING(bwlq, type)				\
 									\
 static inline void writes##bwlq(volatile void __iomem *mem,		\
@@ -480,14 +515,39 @@ BUILDSTRING(l, u32)
 BUILDSTRING(q, u64)
 #endif
 
+#define insb insb
+#define insw insw
+#define insl insl
+#define outsb outsb
+#define outsw outsw
+#define outsl outsl
+
+#define readsb readsb
+#define readsw readsw
+#define readsl readsl
+#define writesb writesb
+#define writesw writesw
+#define writesl writesl
+
+#ifdef CONFIG_64BIT
+#define insq insq
+#define readsq readsq
+#define readsq readsq
+#define writesq writesq
+#endif
+
+
+#define memset_io memset_io
 static inline void memset_io(volatile void __iomem *addr, unsigned char val, int count)
 {
 	memset((void __force *) addr, val, count);
 }
+#define memcpy_fromio memcpy_fromio
 static inline void memcpy_fromio(void *dst, const volatile void __iomem *src, int count)
 {
 	memcpy(dst, (void __force *) src, count);
 }
+#define memcpy_toio memcpy_toio
 static inline void memcpy_toio(volatile void __iomem *dst, const void *src, int count)
 {
 	memcpy((void __force *) dst, src, count);
@@ -556,4 +616,6 @@ extern void (*_dma_cache_inv)(unsigned long start, unsigned long size);
 
 void __ioread64_copy(void *to, const void __iomem *from, size_t count);
 
+#include <asm-generic/io.h>
+
 #endif /* _ASM_IO_H */
-- 
2.34.1


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

* [PATCH v3 2/2] arch/*/io.h: remove ioremap_uc in some architectures
  2023-03-03 10:28 [PATCH v3 0/2] arch/*/io.h: remove ioremap_uc in some architectures Baoquan He
  2023-03-03 10:28 ` [PATCH v3 1/2] mips: add <asm-generic/io.h> including Baoquan He
@ 2023-03-03 10:28 ` Baoquan He
  2023-03-05  9:23   ` Michael Ellerman
  1 sibling, 1 reply; 11+ messages in thread
From: Baoquan He @ 2023-03-03 10:28 UTC (permalink / raw)
  To: linux-kernel
  Cc: linux-arch, linux-mm, arnd, geert, mcgrof, hch, Baoquan He,
	linux-alpha, linux-hexagon, linux-m68k, linux-mips, linux-parisc,
	linuxppc-dev, linux-sh, sparclinux

ioremap_uc() is only meaningful on old x86-32 systems with the PAT
extension, and on ia64 with its slightly unconventional ioremap()
behavior, everywhere else this is the same as ioremap() anyway.

Here, remove the ioremap_uc() definition in architecutures other
than x86 and ia64. These architectures all have asm-generic/io.h
included and will have the default ioremap_uc() definition which
returns NULL.

Note: This changes the existing behaviour and could break code
calling ioremap_uc(). If any ARCH meets this breakage and really
needs a specific ioremap_uc() for its own usage, one ioremap_uc()
can be added in the ARCH.

Link: https://lore.kernel.org/all/20191112105507.GA7122@lst.de/#t
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Baoquan He <bhe@redhat.com>
Cc: linux-alpha@vger.kernel.org
Cc: linux-hexagon@vger.kernel.org
Cc: linux-m68k@lists.linux-m68k.org
Cc: linux-mips@vger.kernel.org
Cc: linux-parisc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-sh@vger.kernel.org
Cc: sparclinux@vger.kernel.org

---
 Documentation/driver-api/device-io.rst | 14 +++++++++-----
 arch/alpha/include/asm/io.h            |  1 -
 arch/hexagon/include/asm/io.h          |  3 ---
 arch/m68k/include/asm/kmap.h           |  1 -
 arch/mips/include/asm/io.h             |  1 -
 arch/parisc/include/asm/io.h           |  2 --
 arch/powerpc/include/asm/io.h          |  1 -
 arch/sh/include/asm/io.h               |  2 --
 arch/sparc/include/asm/io_64.h         |  1 -
 9 files changed, 9 insertions(+), 17 deletions(-)

diff --git a/Documentation/driver-api/device-io.rst b/Documentation/driver-api/device-io.rst
index 4d2baac0311c..12c2ebbaa41e 100644
--- a/Documentation/driver-api/device-io.rst
+++ b/Documentation/driver-api/device-io.rst
@@ -408,11 +408,15 @@ functions for details on the CPU side of things.
 ioremap_uc()
 ------------
 
-ioremap_uc() behaves like ioremap() except that on the x86 architecture without
-'PAT' mode, it marks memory as uncached even when the MTRR has designated
-it as cacheable, see Documentation/x86/pat.rst.
-
-Portable drivers should avoid the use of ioremap_uc().
+ioremap_uc() will be obsoleted since it's only expected on x86 and ia64.
+X86 non-PAT system marks memory as uncached even when the MTRR has designated
+it as cacheable in ioremap_uc()(see Documentation/x86/pat.rst). Ia64 system
+need check if attributes match, otherwise fails. Other than these two
+architectures, ioremap_uc() will default to NULL. Any architectures which
+meets breakage by ioremap_uc() returning NULL should provide a specific
+implementation to override the default version.
+
+Portable drivers should avoid the use of ioremap_uc(), use ioremap() instead.
 
 ioremap_cache()
 ---------------
diff --git a/arch/alpha/include/asm/io.h b/arch/alpha/include/asm/io.h
index 7aeaf7c30a6f..076f0e4e7f1e 100644
--- a/arch/alpha/include/asm/io.h
+++ b/arch/alpha/include/asm/io.h
@@ -308,7 +308,6 @@ static inline void __iomem *ioremap(unsigned long port, unsigned long size)
 }
 
 #define ioremap_wc ioremap
-#define ioremap_uc ioremap
 
 static inline void iounmap(volatile void __iomem *addr)
 {
diff --git a/arch/hexagon/include/asm/io.h b/arch/hexagon/include/asm/io.h
index dcd9cbbf5934..b9847472f25c 100644
--- a/arch/hexagon/include/asm/io.h
+++ b/arch/hexagon/include/asm/io.h
@@ -176,9 +176,6 @@ static inline void writel(u32 data, volatile void __iomem *addr)
 #define _PAGE_IOREMAP (_PAGE_PRESENT | _PAGE_READ | _PAGE_WRITE | \
 		       (__HEXAGON_C_DEV << 6))
 
-#define ioremap_uc(addr, size) ioremap((addr), (size))
-
-
 #define __raw_writel writel
 
 static inline void memcpy_fromio(void *dst, const volatile void __iomem *src,
diff --git a/arch/m68k/include/asm/kmap.h b/arch/m68k/include/asm/kmap.h
index 4efb3efa593a..b778f015c917 100644
--- a/arch/m68k/include/asm/kmap.h
+++ b/arch/m68k/include/asm/kmap.h
@@ -25,7 +25,6 @@ static inline void __iomem *ioremap(unsigned long physaddr, unsigned long size)
 	return __ioremap(physaddr, size, IOMAP_NOCACHE_SER);
 }
 
-#define ioremap_uc ioremap
 #define ioremap_wt ioremap_wt
 static inline void __iomem *ioremap_wt(unsigned long physaddr,
 				       unsigned long size)
diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index 6756baadba6c..da0a625c3c6d 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -167,7 +167,6 @@ void iounmap(const volatile void __iomem *addr);
  */
 #define ioremap(offset, size)						\
 	ioremap_prot((offset), (size), _CACHE_UNCACHED)
-#define ioremap_uc		ioremap
 
 /*
  * ioremap_cache -	map bus memory into CPU space
diff --git a/arch/parisc/include/asm/io.h b/arch/parisc/include/asm/io.h
index 366537042465..48630c78714a 100644
--- a/arch/parisc/include/asm/io.h
+++ b/arch/parisc/include/asm/io.h
@@ -132,8 +132,6 @@ static inline void gsc_writeq(unsigned long long val, unsigned long addr)
 
 #define ioremap_wc(addr, size)  \
 	ioremap_prot((addr), (size), _PAGE_IOREMAP)
-#define ioremap_uc(addr, size)  \
-	ioremap_prot((addr), (size), _PAGE_IOREMAP)
 
 #define pci_iounmap			pci_iounmap
 
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 978d687edf32..7873fc83c82c 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -863,7 +863,6 @@ void __iomem *ioremap_wt(phys_addr_t address, unsigned long size);
 #endif
 
 void __iomem *ioremap_coherent(phys_addr_t address, unsigned long size);
-#define ioremap_uc(addr, size)		ioremap((addr), (size))
 #define ioremap_cache(addr, size) \
 	ioremap_prot((addr), (size), pgprot_val(PAGE_KERNEL))
 
diff --git a/arch/sh/include/asm/io.h b/arch/sh/include/asm/io.h
index b3a26b405c8d..12a892804082 100644
--- a/arch/sh/include/asm/io.h
+++ b/arch/sh/include/asm/io.h
@@ -278,8 +278,6 @@ unsigned long long poke_real_address_q(unsigned long long addr,
 	ioremap_prot((addr), (size), pgprot_val(PAGE_KERNEL))
 #endif /* CONFIG_MMU */
 
-#define ioremap_uc	ioremap
-
 /*
  * Convert a physical pointer to a virtual kernel pointer for /dev/mem
  * access
diff --git a/arch/sparc/include/asm/io_64.h b/arch/sparc/include/asm/io_64.h
index 9303270b22f3..d8ee1442f303 100644
--- a/arch/sparc/include/asm/io_64.h
+++ b/arch/sparc/include/asm/io_64.h
@@ -423,7 +423,6 @@ static inline void __iomem *ioremap(unsigned long offset, unsigned long size)
 	return (void __iomem *)offset;
 }
 
-#define ioremap_uc(X,Y)			ioremap((X),(Y))
 #define ioremap_wc(X,Y)			ioremap((X),(Y))
 #define ioremap_wt(X,Y)			ioremap((X),(Y))
 static inline void __iomem *ioremap_np(unsigned long offset, unsigned long size)
-- 
2.34.1


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

* Re: [PATCH v3 1/2] mips: add <asm-generic/io.h> including
  2023-03-03 10:28 ` [PATCH v3 1/2] mips: add <asm-generic/io.h> including Baoquan He
@ 2023-03-03 12:40   ` Arnd Bergmann
  2023-03-06  8:46     ` Baoquan He
  0 siblings, 1 reply; 11+ messages in thread
From: Arnd Bergmann @ 2023-03-03 12:40 UTC (permalink / raw)
  To: Baoquan He, linux-kernel
  Cc: Linux-Arch, linux-mm, Geert Uytterhoeven, Luis Chamberlain,
	Christoph Hellwig, Thomas Bogendoerfer, Helge Deller,
	Serge Semin, Florian Fainelli, Huacai Chen, Jiaxun Yang,
	linux-mips

On Fri, Mar 3, 2023, at 11:28, Baoquan He wrote:
> With the adding, some default ioremap_xx methods defined in
> asm-generic/io.h can be used. E.g the default ioremap_uc() returning
> NULL.
>
> Signed-off-by: Baoquan He <bhe@redhat.com>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Serge Semin <fancer.lancer@gmail.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Huacai Chen <chenhuacai@kernel.org>
> Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
> Cc: linux-mips@vger.kernel.org

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

I think this is all good. I had look at what cleanups we could do as
follow-ups:

> +#define phys_to_virt phys_to_virt
>  static inline void * phys_to_virt(unsigned long address)
>  {
>  	return __va(address);

This is the same as the asm-generic version, so the mips definition
is no longer needed.

> @@ -359,6 +360,27 @@ __BUILD_MEMORY_PFX(__raw_, q, u64, 0)
>  __BUILD_MEMORY_PFX(__mem_, q, u64, 0)
>  #endif
> 
> +#define readb readb
> +#define readw readw
> +#define readl readl
> +#define writeb writeb
> +#define writew writew
> +#define writel writel
> +
> +#ifdef CONFIG_64BIT
> +#define readq readq
> +#define writeq writeq
> +#define __raw_readq __raw_readq
> +#define __raw_writeq __raw_writeq
> +#endif
> +
> +#define __raw_readb __raw_readb
> +#define __raw_readw __raw_readw
> +#define __raw_readl __raw_readl
> +#define __raw_writeb __raw_writeb
> +#define __raw_writew __raw_writew
> +#define __raw_writel __raw_writel

The mips code defines the __raw variants with slightly different
semantics on both barriers and byteswap, which makes it impractical
to share any of the above.				

> +#define memset_io memset_io
>  static inline void memset_io(volatile void __iomem *addr, unsigned 
> char val, int count)
>  {
>  	memset((void __force *) addr, val, count);
>  }
> +#define memcpy_fromio memcpy_fromio
>  static inline void memcpy_fromio(void *dst, const volatile void 
> __iomem *src, int count)
>  {
>  	memcpy(dst, (void __force *) src, count);
>  }
> +#define memcpy_toio memcpy_toio

These are again the same as the generic version

    Arnd

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

* Re: [PATCH v3 2/2] arch/*/io.h: remove ioremap_uc in some architectures
  2023-03-03 10:28 ` [PATCH v3 2/2] arch/*/io.h: remove ioremap_uc in some architectures Baoquan He
@ 2023-03-05  9:23   ` Michael Ellerman
  2023-03-05  9:29     ` Geert Uytterhoeven
  0 siblings, 1 reply; 11+ messages in thread
From: Michael Ellerman @ 2023-03-05  9:23 UTC (permalink / raw)
  To: Baoquan He, linux-kernel
  Cc: linux-arch, linux-mm, arnd, geert, mcgrof, hch, Baoquan He,
	linux-alpha, linux-hexagon, linux-m68k, linux-mips, linux-parisc,
	linuxppc-dev, linux-sh, sparclinux

Baoquan He <bhe@redhat.com> writes:
> ioremap_uc() is only meaningful on old x86-32 systems with the PAT
> extension, and on ia64 with its slightly unconventional ioremap()
> behavior, everywhere else this is the same as ioremap() anyway.
>
> Here, remove the ioremap_uc() definition in architecutures other
> than x86 and ia64. These architectures all have asm-generic/io.h
> included and will have the default ioremap_uc() definition which
> returns NULL.
>
> Note: This changes the existing behaviour and could break code
> calling ioremap_uc(). If any ARCH meets this breakage and really
> needs a specific ioremap_uc() for its own usage, one ioremap_uc()
> can be added in the ARCH.

I see one use in:

drivers/video/fbdev/aty/atyfb_base.c:        par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);


Which isn't obviously x86/ia64 specific.

I'm pretty sure some powermacs (powerpc) use that driver.

Maybe that exact code path is only reachable on x86/ia64? But if so
please explain why.

Otherwise it looks like this series could break that driver on powerpc
at least.

cheers

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

* Re: [PATCH v3 2/2] arch/*/io.h: remove ioremap_uc in some architectures
  2023-03-05  9:23   ` Michael Ellerman
@ 2023-03-05  9:29     ` Geert Uytterhoeven
  2023-03-05 20:10       ` Arnd Bergmann
  0 siblings, 1 reply; 11+ messages in thread
From: Geert Uytterhoeven @ 2023-03-05  9:29 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Baoquan He, linux-kernel, linux-arch, linux-mm, arnd, mcgrof,
	hch, linux-alpha, linux-hexagon, linux-m68k, linux-mips,
	linux-parisc, linuxppc-dev, linux-sh, sparclinux

Hi Michael,

On Sun, Mar 5, 2023 at 10:23 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
> Baoquan He <bhe@redhat.com> writes:
> > ioremap_uc() is only meaningful on old x86-32 systems with the PAT
> > extension, and on ia64 with its slightly unconventional ioremap()
> > behavior, everywhere else this is the same as ioremap() anyway.
> >
> > Here, remove the ioremap_uc() definition in architecutures other
> > than x86 and ia64. These architectures all have asm-generic/io.h
> > included and will have the default ioremap_uc() definition which
> > returns NULL.
> >
> > Note: This changes the existing behaviour and could break code
> > calling ioremap_uc(). If any ARCH meets this breakage and really
> > needs a specific ioremap_uc() for its own usage, one ioremap_uc()
> > can be added in the ARCH.
>
> I see one use in:
>
> drivers/video/fbdev/aty/atyfb_base.c:        par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
>
>
> Which isn't obviously x86/ia64 specific.
>
> I'm pretty sure some powermacs (powerpc) use that driver.

I originally wrote that driver for CHRP, so yes.

> Maybe that exact code path is only reachable on x86/ia64? But if so
> please explain why.
>
> Otherwise it looks like this series could break that driver on powerpc
> at least.

Indeed.

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] 11+ messages in thread

* Re: [PATCH v3 2/2] arch/*/io.h: remove ioremap_uc in some architectures
  2023-03-05  9:29     ` Geert Uytterhoeven
@ 2023-03-05 20:10       ` Arnd Bergmann
  2023-03-07  0:58         ` Michael Ellerman
  0 siblings, 1 reply; 11+ messages in thread
From: Arnd Bergmann @ 2023-03-05 20:10 UTC (permalink / raw)
  To: Geert Uytterhoeven, Michael Ellerman
  Cc: Linux-Arch, Baoquan He, linux-sh, linux-m68k, linux-hexagon,
	linux-kernel, linux-mips, Christoph Hellwig, linux-mm,
	Luis Chamberlain, linux-parisc, linux-alpha, sparclinux,
	linuxppc-dev

On Sun, Mar 5, 2023, at 10:29, Geert Uytterhoeven wrote:
>
> On Sun, Mar 5, 2023 at 10:23 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
>> Maybe that exact code path is only reachable on x86/ia64? But if so
>> please explain why.
>>
>> Otherwise it looks like this series could break that driver on powerpc
>> at least.
>
> Indeed.

When I last looked into this, I sent a patch to use ioremap()
on non-x86:

https://lore.kernel.org/all/20191111192258.2234502-1-arnd@arndb.de/

    Arnd

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

* Re: [PATCH v3 1/2] mips: add <asm-generic/io.h> including
  2023-03-03 12:40   ` Arnd Bergmann
@ 2023-03-06  8:46     ` Baoquan He
  0 siblings, 0 replies; 11+ messages in thread
From: Baoquan He @ 2023-03-06  8:46 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-kernel, Linux-Arch, linux-mm, Geert Uytterhoeven,
	Luis Chamberlain, Christoph Hellwig, Thomas Bogendoerfer,
	Helge Deller, Serge Semin, Florian Fainelli, Huacai Chen,
	Jiaxun Yang, linux-mips

On 03/03/23 at 01:40pm, Arnd Bergmann wrote:
> On Fri, Mar 3, 2023, at 11:28, Baoquan He wrote:
> > With the adding, some default ioremap_xx methods defined in
> > asm-generic/io.h can be used. E.g the default ioremap_uc() returning
> > NULL.
> >
> > Signed-off-by: Baoquan He <bhe@redhat.com>
> > Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> > Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> > Cc: Helge Deller <deller@gmx.de>
> > Cc: Serge Semin <fancer.lancer@gmail.com>
> > Cc: Florian Fainelli <f.fainelli@gmail.com>
> > Cc: Huacai Chen <chenhuacai@kernel.org>
> > Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
> > Cc: linux-mips@vger.kernel.org
> 
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> 
> I think this is all good. I had look at what cleanups we could do as
> follow-ups:

Thanks a lot for careful reviewing and great suggestions.

> 
> > +#define phys_to_virt phys_to_virt
> >  static inline void * phys_to_virt(unsigned long address)
> >  {
> >  	return __va(address);
> 
> This is the same as the asm-generic version, so the mips definition
> is no longer needed.

Agree, I can clean this up with a followup patch.

> 
> > @@ -359,6 +360,27 @@ __BUILD_MEMORY_PFX(__raw_, q, u64, 0)
> >  __BUILD_MEMORY_PFX(__mem_, q, u64, 0)
> >  #endif
> > 
> > +#define readb readb
> > +#define readw readw
> > +#define readl readl
> > +#define writeb writeb
> > +#define writew writew
> > +#define writel writel
> > +
> > +#ifdef CONFIG_64BIT
> > +#define readq readq
> > +#define writeq writeq
> > +#define __raw_readq __raw_readq
> > +#define __raw_writeq __raw_writeq
> > +#endif
> > +
> > +#define __raw_readb __raw_readb
> > +#define __raw_readw __raw_readw
> > +#define __raw_readl __raw_readl
> > +#define __raw_writeb __raw_writeb
> > +#define __raw_writew __raw_writew
> > +#define __raw_writel __raw_writel
> 
> The mips code defines the __raw variants with slightly different
> semantics on both barriers and byteswap, which makes it impractical
> to share any of the above.				
> 
> > +#define memset_io memset_io
> >  static inline void memset_io(volatile void __iomem *addr, unsigned 
> > char val, int count)
> >  {
> >  	memset((void __force *) addr, val, count);
> >  }
> > +#define memcpy_fromio memcpy_fromio
> >  static inline void memcpy_fromio(void *dst, const volatile void 
> > __iomem *src, int count)
> >  {
> >  	memcpy(dst, (void __force *) src, count);
> >  }
> > +#define memcpy_toio memcpy_toio
> 
> These are again the same as the generic version

OK, can remove this with the above change.


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

* Re: [PATCH v3 2/2] arch/*/io.h: remove ioremap_uc in some architectures
  2023-03-05 20:10       ` Arnd Bergmann
@ 2023-03-07  0:58         ` Michael Ellerman
  2023-03-07  1:30           ` Baoquan He
  0 siblings, 1 reply; 11+ messages in thread
From: Michael Ellerman @ 2023-03-07  0:58 UTC (permalink / raw)
  To: Arnd Bergmann, Geert Uytterhoeven
  Cc: Linux-Arch, Baoquan He, linux-sh, linux-m68k, linux-hexagon,
	linux-kernel, linux-mips, Christoph Hellwig, linux-mm,
	Luis Chamberlain, linux-parisc, linux-alpha, sparclinux,
	linuxppc-dev

"Arnd Bergmann" <arnd@arndb.de> writes:
> On Sun, Mar 5, 2023, at 10:29, Geert Uytterhoeven wrote:
>> On Sun, Mar 5, 2023 at 10:23 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
>>> Maybe that exact code path is only reachable on x86/ia64? But if so
>>> please explain why.
>>>
>>> Otherwise it looks like this series could break that driver on powerpc
>>> at least.
>>
>> Indeed.
>
> When I last looked into this, I sent a patch to use ioremap()
> on non-x86:
>
> https://lore.kernel.org/all/20191111192258.2234502-1-arnd@arndb.de/

OK thanks.

Baoquan can you add that patch to the start of this series if/when you
post the next version?

cheers

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

* Re: [PATCH v3 2/2] arch/*/io.h: remove ioremap_uc in some architectures
  2023-03-07  0:58         ` Michael Ellerman
@ 2023-03-07  1:30           ` Baoquan He
  2023-03-07  7:17             ` Arnd Bergmann
  0 siblings, 1 reply; 11+ messages in thread
From: Baoquan He @ 2023-03-07  1:30 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Arnd Bergmann, Geert Uytterhoeven, Linux-Arch, linux-sh,
	linux-m68k, linux-hexagon, linux-kernel, linux-mips,
	Christoph Hellwig, linux-mm, Luis Chamberlain, linux-parisc,
	linux-alpha, sparclinux, linuxppc-dev

On 03/07/23 at 11:58am, Michael Ellerman wrote:
> "Arnd Bergmann" <arnd@arndb.de> writes:
> > On Sun, Mar 5, 2023, at 10:29, Geert Uytterhoeven wrote:
> >> On Sun, Mar 5, 2023 at 10:23 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
> >>> Maybe that exact code path is only reachable on x86/ia64? But if so
> >>> please explain why.
> >>>
> >>> Otherwise it looks like this series could break that driver on powerpc
> >>> at least.
> >>
> >> Indeed.
> >
> > When I last looked into this, I sent a patch to use ioremap()
> > on non-x86:
> >
> > https://lore.kernel.org/all/20191111192258.2234502-1-arnd@arndb.de/
> 
> OK thanks.
> 
> Baoquan can you add that patch to the start of this series if/when you
> post the next version?

Sure, will do. Wondering if we need make change to cover powerpc other
than x86 and ia64 in Arnd's patch as you and Geert pointed out.


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

* Re: [PATCH v3 2/2] arch/*/io.h: remove ioremap_uc in some architectures
  2023-03-07  1:30           ` Baoquan He
@ 2023-03-07  7:17             ` Arnd Bergmann
  0 siblings, 0 replies; 11+ messages in thread
From: Arnd Bergmann @ 2023-03-07  7:17 UTC (permalink / raw)
  To: Baoquan He, Michael Ellerman
  Cc: Geert Uytterhoeven, Linux-Arch, linux-sh, linux-m68k,
	linux-hexagon, linux-kernel, linux-mips, Christoph Hellwig,
	linux-mm, Luis Chamberlain, linux-parisc, linux-alpha,
	sparclinux, linuxppc-dev

On Tue, Mar 7, 2023, at 02:30, Baoquan He wrote:
> On 03/07/23 at 11:58am, Michael Ellerman wrote:
>> "Arnd Bergmann" <arnd@arndb.de> writes:
>> > On Sun, Mar 5, 2023, at 10:29, Geert Uytterhoeven wrote:
>> >> On Sun, Mar 5, 2023 at 10:23 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
>> >>> Maybe that exact code path is only reachable on x86/ia64? But if so
>> >>> please explain why.
>> >>>
>> >>> Otherwise it looks like this series could break that driver on powerpc
>> >>> at least.
>> >>
>> >> Indeed.
>> >
>> > When I last looked into this, I sent a patch to use ioremap()
>> > on non-x86:
>> >
>> > https://lore.kernel.org/all/20191111192258.2234502-1-arnd@arndb.de/
>> 
>> OK thanks.
>> 
>> Baoquan can you add that patch to the start of this series if/when you
>> post the next version?
>
> Sure, will do. Wondering if we need make change to cover powerpc other
> than x86 and ia64 in Arnd's patch as you and Geert pointed out.

The patch fixes the aty driver for all architectures, including the
ones that were already broken before your series with the 'return NULL'
version.

The only other callers of ioremap_uc() and devm_ioremap_uc() are
in architecture specific code and in drivers/mfd/intel-lpss.c, which
is x86 specific.

     Arnd

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

end of thread, other threads:[~2023-03-07  7:18 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-03 10:28 [PATCH v3 0/2] arch/*/io.h: remove ioremap_uc in some architectures Baoquan He
2023-03-03 10:28 ` [PATCH v3 1/2] mips: add <asm-generic/io.h> including Baoquan He
2023-03-03 12:40   ` Arnd Bergmann
2023-03-06  8:46     ` Baoquan He
2023-03-03 10:28 ` [PATCH v3 2/2] arch/*/io.h: remove ioremap_uc in some architectures Baoquan He
2023-03-05  9:23   ` Michael Ellerman
2023-03-05  9:29     ` Geert Uytterhoeven
2023-03-05 20:10       ` Arnd Bergmann
2023-03-07  0:58         ` Michael Ellerman
2023-03-07  1:30           ` Baoquan He
2023-03-07  7:17             ` Arnd Bergmann

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).