• Baoquan He's avatar
    asm-generic/iomap.h: remove ARCH_HAS_IOREMAP_xx macros · 0b1f77e7
    Baoquan He authored
    Patch series "mm: ioremap: Convert architectures to take GENERIC_IOREMAP
    way", v8.
    
    Motivation and implementation:
    ==============================
    Currently, many architecutres have't taken the standard GENERIC_IOREMAP
    way to implement ioremap_prot(), iounmap(), and ioremap_xx(), but make
    these functions specifically under each arch's folder.  Those cause many
    duplicated code of ioremap() and iounmap().
    
    In this patchset, firstly introduce generic_ioremap_prot() and
    generic_iounmap() to extract the generic code for GENERIC_IOREMAP.  By
    taking GENERIC_IOREMAP method, the generic generic_ioremap_prot(),
    generic_iounmap(), and their generic wrapper ioremap_prot(), ioremap() and
    iounmap() are all visible and available to arch.  Arch needs to provide
    wrapper functions to override the generic version if there's arch specific
    handling in its corresponding ioremap_prot(), ioremap() or iounmap(). 
    With these changes, duplicated ioremap/iounmap() code uder ARCH-es are
    removed, and the equivalent functioality is kept as before.
    
    Background info:
    ================
    
    1) The converting more architectures to take GENERIC_IOREMAP way is
       suggested by Christoph in below discussion:
       https://lore.kernel.org/all/Yp7h0Jv6vpgt6xdZ@infradead.org/T/#u
    
    2) In the previous v1 to v3, it's basically further action after arm64
       has converted to GENERIC_IOREMAP way in below patchset.  It's done by
       adding hook ioremap_allowed() and iounmap_allowed() in ARCH to add ARCH
       specific handling the middle of ioremap_prot() and iounmap().
    
    [PATCH v5 0/6] arm64: Cleanup ioremap() and support ioremap_prot()
    https://lore.kernel.org/all/20220607125027.44946-1-wangkefeng.wang@huawei.com/T/#u
    
    Later, during v3 reviewing, Christophe Leroy suggested to introduce
    generic_ioremap_prot() and generic_iounmap() to generic codes, and ARCH
    can provide wrapper function ioremap_prot(), ioremap() or iounmap() if
    needed.  Christophe made a RFC patchset as below to specially demonstrate
    his idea.  This is what v4 and now v5 is doing.
    
    [RFC PATCH 0/8] mm: ioremap: Convert architectures to take GENERIC_IOREMAP way
    https://lore.kernel.org/all/cover.1665568707.git.christophe.leroy@csgroup.eu/T/#u
    
    Testing:
    ========
    In v8, I only applied this patchset onto the latest linus's tree to build
    and run on arm64 and s390.
    
    
    This patch (of 19):
    
    Let's use '#define ioremap_xx' and "#ifdef ioremap_xx" instead.
    
    To remove defined ARCH_HAS_IOREMAP_xx macros in <asm/io.h> of each ARCH,
    the ARCH's own ioremap_wc|wt|np definition need be above "#include
    <asm-generic/iomap.h>.  Otherwise the redefinition error would be seen
    during compiling.  So the relevant adjustments are made to avoid compiling
    error:
    
      loongarch:
      - doesn't include <asm-generic/iomap.h>, defining ARCH_HAS_IOREMAP_WC
        is redundant, so simply remove it.
    
      m68k:
      - selected GENERIC_IOMAP, <asm-generic/iomap.h> has been added in
        <asm-generic/io.h>, and <asm/kmap.h> is included above
        <asm-generic/iomap.h>, so simply remove ARCH_HAS_IOREMAP_WT defining.
    
      mips:
      - move "#include <asm-generic/iomap.h>" below ioremap_wc definition
        in <asm/io.h>
    
      powerpc:
      - remove "#include <asm-generic/iomap.h>" in <asm/io.h> because it's
        duplicated with the one in <asm-generic/io.h>, let's rely on the
        latter.
    
      x86:
      - selected GENERIC_IOMAP, remove #include <asm-generic/iomap.h> in
        the middle of <asm/io.h>. Let's rely on <asm-generic/io.h>.
    
    Link: https://lkml.kernel.org/r/20230706154520.11257-2-bhe@redhat.comSigned-off-by: default avatarBaoquan He <bhe@redhat.com>
    Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
    Reviewed-by: default avatarMike Rapoport (IBM) <rppt@kernel.org>
    Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
    Cc: Alexander Gordeev <agordeev@linux.ibm.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
    Cc: David Laight <David.Laight@ACULAB.COM>
    Cc: Helge Deller <deller@gmx.de>
    Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: Niklas Schnelle <schnelle@linux.ibm.com>
    Cc: Stafford Horne <shorne@gmail.com>
    Cc: Brian Cain <bcain@quicinc.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
    Cc: Chris Zankel <chris@zankel.net>
    Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
    Cc: Heiko Carstens <hca@linux.ibm.com>
    Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
    Cc: Jonas Bonn <jonas@southpole.se>
    Cc: Max Filippov <jcmvbkbc@gmail.com>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Nicholas Piggin <npiggin@gmail.com>
    Cc: Rich Felker <dalias@libc.org>
    Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
    Cc: Sven Schnelle <svens@linux.ibm.com>
    Cc: Vasily Gorbik <gor@linux.ibm.com>
    Cc: Vineet Gupta <vgupta@kernel.org>
    Cc: Will Deacon <will@kernel.org>
    Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    0b1f77e7
io_mm.h 12.9 KB