[v3,2/2] arch/*/io.h: remove ioremap_uc in some architectures
Commit Message
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(-)
Comments
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
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
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
"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
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.
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
@@ -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()
---------------
@@ -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)
{
@@ -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,
@@ -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)
@@ -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
@@ -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
@@ -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))
@@ -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
@@ -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)