2019-11-25 19:29:42

by Christoph Hellwig

[permalink] [raw]
Subject: [GIT PULL] generic ioremap for 5.5

Hi Linus,

this pull requests add the remaining bits for an entirely generic ioremap
and iounmap to lib/ioremap.c, and to facilitate that cleans up the giant
mess of weird ioremap variants we had with no users outside the arch
code. For now just the three newest ports use the code, but there is
more than a handful others that can be converted without too much work.

There are two conflicts with the riscv tree - one is a trivial makefile
context one with the nommu support, and the other is the split of the
riscv <asm/io.h> which means that the removals in this pull request need
to be applied to the new location that they were moved to in the riscv
tree.

The following changes since commit 31f4f5b495a62c9a8b15b1c3581acd5efeb9af8c:

Linux 5.4-rc7 (2019-11-10 16:17:15 -0800)

are available in the Git repository at:

git://git.infradead.org/users/hch/ioremap.git tags/ioremap-5.5

for you to fetch changes up to eafee59440623e06b0ce4a0e49f814a8cf31d8ca:

nds32: use generic ioremap (2019-11-12 11:37:58 +0100)

----------------------------------------------------------------
generic ioremap support

- clean up various obsolete ioremap and iounmap variants
- add a new generic ioremap implementation and switch csky, nds32 and
riscv over to it

----------------------------------------------------------------
Christoph Hellwig (21):
arm: remove ioremap_cached
unicore32: remove ioremap_cached
ia64: rename ioremap_nocache to ioremap_uc
hexagon: clean up ioremap
alpha: remove the unused __ioremap wrapper
nios2: remove __ioremap
parisc: remove __ioremap
x86: Clean up ioremap()
xtensa: clean up ioremap
asm-generic: ioremap_uc should behave the same with and without MMU
asm-generic: don't provide ioremap for CONFIG_MMU
arch: rely on asm-generic/io.h for default ioremap_* definitions
m68k: rename __iounmap and mark it static
hexagon: remove __iounmap
nios2: remove __iounmap
sh: remove __iounmap
lib: provide a simple generic ioremap implementation
riscv: use the generic ioremap code
csky: remove ioremap_cache
csky: use generic ioremap
nds32: use generic ioremap

arch/alpha/include/asm/io.h | 6 ---
arch/arc/include/asm/io.h | 4 --
arch/arm/include/asm/io.h | 7 ---
arch/arm/mm/ioremap.c | 4 --
arch/arm/mm/mmu.c | 2 +-
arch/arm/mm/nommu.c | 4 --
arch/arm64/include/asm/io.h | 2 -
arch/csky/Kconfig | 1 +
arch/csky/include/asm/io.h | 11 ++--
arch/csky/include/asm/pgtable.h | 4 ++
arch/csky/mm/ioremap.c | 52 -------------------
arch/hexagon/include/asm/io.h | 18 ++-----
arch/hexagon/kernel/hexagon_ksyms.c | 4 +-
arch/hexagon/mm/ioremap.c | 4 +-
arch/ia64/include/asm/io.h | 5 +-
arch/ia64/mm/ioremap.c | 4 +-
arch/m68k/include/asm/kmap.h | 1 -
arch/m68k/mm/kmap.c | 100 ++++++++++++++++++------------------
arch/microblaze/include/asm/io.h | 3 --
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 ----------------------
arch/nios2/include/asm/io.h | 25 +--------
arch/nios2/mm/ioremap.c | 23 +++------
arch/openrisc/include/asm/io.h | 1 -
arch/parisc/include/asm/io.h | 11 +---
arch/parisc/mm/ioremap.c | 10 ++--
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/io.h | 13 -----
arch/riscv/include/asm/pgtable.h | 6 +++
arch/riscv/mm/Makefile | 1 -
arch/riscv/mm/ioremap.c | 84 ------------------------------
arch/s390/include/asm/io.h | 4 --
arch/sh/include/asm/io.h | 9 +---
arch/sh/mm/ioremap.c | 4 +-
arch/sparc/include/asm/io_32.h | 1 +
arch/unicore32/include/asm/io.h | 4 +-
arch/unicore32/mm/ioremap.c | 8 ---
arch/x86/include/asm/io.h | 7 +--
arch/x86/mm/ioremap.c | 8 +--
arch/x86/mm/pageattr.c | 4 +-
arch/xtensa/include/asm/io.h | 12 +----
include/asm-generic/io.h | 89 +++++++++++++-------------------
lib/Kconfig | 3 ++
lib/ioremap.c | 39 ++++++++++++++
47 files changed, 189 insertions(+), 487 deletions(-)
delete mode 100644 arch/nds32/mm/ioremap.c
delete mode 100644 arch/riscv/mm/ioremap.c


2019-11-28 19:03:55

by Linus Torvalds

[permalink] [raw]
Subject: Re: [GIT PULL] generic ioremap for 5.5

[ Added PaulW ]

On Mon, Nov 25, 2019 at 11:28 AM Christoph Hellwig <[email protected]> wrote:
>
> There are two conflicts with the riscv tree - one is a trivial makefile
> context one with the nommu support, and the other is the split of the
> riscv <asm/io.h> which means that the removals in this pull request need
> to be applied to the new location that they were moved to in the riscv
> tree.

The conflict was trivial to fix up, but since I don't do RISC-V
cross-builds, I'd like PaulW to please check that there weren't any
surprising semantic issues too - or that I didn't mess up.

Paul? (It's not actually pushed out yet, it's still building, but the
ioremap merge should be there in a moment)

Linus

2019-11-28 19:21:48

by pr-tracker-bot

[permalink] [raw]
Subject: Re: [GIT PULL] generic ioremap for 5.5

The pull request you sent on Mon, 25 Nov 2019 20:27:58 +0100:

> git://git.infradead.org/users/hch/ioremap.git tags/ioremap-5.5

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a308a7102215a582fc474375648965bc5692894b

Thank you!

--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

2019-12-03 02:54:03

by Paul Walmsley

[permalink] [raw]
Subject: Re: [GIT PULL] generic ioremap for 5.5

On Thu, 28 Nov 2019, Linus Torvalds wrote:

> On Mon, Nov 25, 2019 at 11:28 AM Christoph Hellwig <[email protected]> wrote:
> >
> > There are two conflicts with the riscv tree - one is a trivial makefile
> > context one with the nommu support, and the other is the split of the
> > riscv <asm/io.h> which means that the removals in this pull request need
> > to be applied to the new location that they were moved to in the riscv
> > tree.
>
> The conflict was trivial to fix up, but since I don't do RISC-V
> cross-builds, I'd like PaulW to please check that there weren't any
> surprising semantic issues too - or that I didn't mess up.
>
> Paul? (It's not actually pushed out yet, it's still building, but the
> ioremap merge should be there in a moment)

Looks good to me, and passes basic tests with both QEMU and hardware.

thanks,

- Paul