linux-next: manual merge of the akpm-current tree with the risc-v tree

linux-next: manual merge of the akpm-current tree with the risc-v tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  arch/riscv/Kconfig

between commit:

  d95f1a542c3d ("RISC-V: Implement sparsemem")

from the risc-v tree and commit:

  f6a9089b8915 ("riscv: make mmap allocation top-down by default")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/riscv/Kconfig
index 572599cbf750,87dc5370becb..000000000000
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@@ -56,7 -54,18 +56,19 @@@ config RISC
  	select EDAC_SUPPORT
  	select ARCH_HAS_GIGANTIC_PAGE
  	select ARCH_WANT_HUGE_PMD_SHARE if 64BIT
 +	select SPARSEMEM_STATIC if 32BIT
+ 	select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
+ 	select HAVE_ARCH_MMAP_RND_BITS
+ 
+ config ARCH_MMAP_RND_BITS_MIN
+ 	default 18 if 64BIT
+ 	default 8
+ 
+ # max bits determined by the following formula:
+ #  VA_BITS - PAGE_SHIFT - 3
+ config ARCH_MMAP_RND_BITS_MAX
+ 	default 24 if 64BIT # SV39 based
+ 	default 17
  
  config MMU
  	def_bool y

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

linux-next: manual merge of the akpm-current tree with the risc-v tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  arch/riscv/Kconfig

between commits:

  d3c263cda1a5 ("riscv: Add KGDB support")
  ce66581cb6e9 ("riscv: Use the XML target descriptions to report 3 system registers")

from the risc-v tree and commit:

  bbb6dc9ac443 ("riscv: support DEBUG_WX")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/riscv/Kconfig
index 39f7a70cbd72,8576cc027b76..000000000000
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@@ -68,8 -67,7 +67,9 @@@ config RISC
  	select ARCH_HAS_GCOV_PROFILE_ALL
  	select HAVE_COPY_THREAD_TLS
  	select HAVE_ARCH_KASAN if MMU && 64BIT
 +	select HAVE_ARCH_KGDB
 +	select HAVE_ARCH_KGDB_QXFER_PKT
+ 	select ARCH_HAS_DEBUG_WX
  
  config ARCH_MMAP_RND_BITS_MIN
  	default 18 if 64BIT

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

linux-next: manual merge of the akpm-current tree with the risc-v tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  lib/Makefile

between commit:

  1a479f783857 ("lib: Add a generic version of devmem_is_allowed()")

from the risc-v tree and commit:

  d0bb028dd7f4 ("lib/test_bits.c: add tests of GENMASK")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc lib/Makefile
index 7bdda9ea53ab,591d10906354..000000000000
--- a/lib/Makefile
+++ b/lib/Makefile
@@@ -342,5 -317,4 +341,6 @@@ obj-$(CONFIG_OBJAGG) += objagg.
  # KUnit tests
  obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
  obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
+ obj-$(CONFIG_BITS_TEST) += test_bits.o
 +
 +obj-$(CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED) += devmem_is_allowed.o

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

linux-next: manual merge of the akpm-current tree with the risc-v tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  arch/riscv/mm/init.c

between commit:

  c29c38fa2a8b ("RISC-V: Remove any memblock representing unusable memory area")

from the risc-v tree and commits:

  3520eeb79142 ("arch, drivers: replace for_each_membock() with for_each_mem_range()")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

It also looks like there is a bug in that risc-v tree patch: mem_start
is used uninitialised in setup_bootmem().
-- 
Cheers,
Stephen Rothwell

diff --cc arch/riscv/mm/init.c
index 812a48c91a95,bc72bb6b5fe0..000000000000
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@@ -152,20 -141,25 +152,20 @@@ disable
  }
  #endif /* CONFIG_BLK_DEV_INITRD */
  
 -static phys_addr_t dtb_early_pa __initdata;
 -
  void __init setup_bootmem(void)
  {
- 	struct memblock_region *reg;
- 	phys_addr_t mem_start, end = 0;
 -	phys_addr_t mem_size = 0;
 -	phys_addr_t total_mem = 0;
+ 	phys_addr_t mem_start, start, end = 0;
  	phys_addr_t vmlinux_end = __pa_symbol(&_end);
  	phys_addr_t vmlinux_start = __pa_symbol(&_start);
+ 	u64 i;
  
  	/* Find the memory region containing the kernel */
- 	for_each_memblock(memory, reg) {
- 		end = reg->base + reg->size;
+ 	for_each_mem_range(i, &start, &end) {
+ 		phys_addr_t size = end - start;
 -		if (!total_mem)
 +		if (!mem_start)
- 			mem_start = reg->base;
- 		if (reg->base <= vmlinux_start && vmlinux_end <= end)
- 			BUG_ON(reg->size == 0);
+ 			mem_start = start;
+ 		if (start <= vmlinux_start && vmlinux_end <= end)
+ 			BUG_ON(size == 0);
 -		total_mem = total_mem + size;
  	}
  
  	/*
@@@ -542,18 -455,11 +533,18 @@@ static void __init setup_vm_final(void
  {
  	uintptr_t va, map_size;
  	phys_addr_t pa, start, end;
- 	struct memblock_region *reg;
+ 	u64 i;
  
 -	/* Set mmu_enabled flag */
 -	mmu_enabled = true;
 -
 +	/**
 +	 * MMU is enabled at this point. But page table setup is not complete yet.
 +	 * fixmap page table alloc functions should be used at this point
 +	 */
 +	pt_ops.alloc_pte = alloc_pte_fixmap;
 +	pt_ops.get_pte_virt = get_pte_virt_fixmap;
 +#ifndef __PAGETABLE_PMD_FOLDED
 +	pt_ops.alloc_pmd = alloc_pmd_fixmap;
 +	pt_ops.get_pmd_virt = get_pmd_virt_fixmap;
 +#endif
  	/* Setup swapper PGD for fixmap */
  	create_pgd_mapping(swapper_pg_dir, FIXADDR_START,
  			   __pa_symbol(fixmap_pgd_next),

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

Re: linux-next: manual merge of the akpm-current tree with the risc-v tree

[Palmer Dabbelt]

On Tue, 06 Oct 2020 03:39:06 PDT (-0700), Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
>   arch/riscv/mm/init.c
>
> between commit:
>
>   c29c38fa2a8b ("RISC-V: Remove any memblock representing unusable memory area")
>
> from the risc-v tree and commits:
>
>   3520eeb79142 ("arch, drivers: replace for_each_membock() with for_each_mem_range()")
>
> from the akpm-current tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> It also looks like there is a bug in that risc-v tree patch: mem_start
> is used uninitialised in setup_bootmem().
> -- 
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/riscv/mm/init.c
> index 812a48c91a95,bc72bb6b5fe0..000000000000
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@@ -152,20 -141,25 +152,20 @@@ disable
>   }
>   #endif /* CONFIG_BLK_DEV_INITRD */
>   
>  -static phys_addr_t dtb_early_pa __initdata;
>  -
>   void __init setup_bootmem(void)
>   {
> - 	struct memblock_region *reg;
> - 	phys_addr_t mem_start, end = 0;
>  -	phys_addr_t mem_size = 0;
>  -	phys_addr_t total_mem = 0;
> + 	phys_addr_t mem_start, start, end = 0;
>   	phys_addr_t vmlinux_end = __pa_symbol(&_end);
>   	phys_addr_t vmlinux_start = __pa_symbol(&_start);
> + 	u64 i;
>   
>   	/* Find the memory region containing the kernel */
> - 	for_each_memblock(memory, reg) {
> - 		end = reg->base + reg->size;
> + 	for_each_mem_range(i, &start, &end) {
> + 		phys_addr_t size = end - start;
>  -		if (!total_mem)
>  +		if (!mem_start)
> - 			mem_start = reg->base;
> - 		if (reg->base <= vmlinux_start && vmlinux_end <= end)
> - 			BUG_ON(reg->size == 0);
> + 			mem_start = start;
> + 		if (start <= vmlinux_start && vmlinux_end <= end)
> + 			BUG_ON(size == 0);
>  -		total_mem = total_mem + size;
>   	}
>   
>   	/*
> @@@ -542,18 -455,11 +533,18 @@@ static void __init setup_vm_final(void
>   {
>   	uintptr_t va, map_size;
>   	phys_addr_t pa, start, end;
> - 	struct memblock_region *reg;
> + 	u64 i;
>   
>  -	/* Set mmu_enabled flag */
>  -	mmu_enabled = true;
>  -
>  +	/**
>  +	 * MMU is enabled at this point. But page table setup is not complete yet.
>  +	 * fixmap page table alloc functions should be used at this point
>  +	 */
>  +	pt_ops.alloc_pte = alloc_pte_fixmap;
>  +	pt_ops.get_pte_virt = get_pte_virt_fixmap;
>  +#ifndef __PAGETABLE_PMD_FOLDED
>  +	pt_ops.alloc_pmd = alloc_pmd_fixmap;
>  +	pt_ops.get_pmd_virt = get_pmd_virt_fixmap;
>  +#endif
>   	/* Setup swapper PGD for fixmap */
>   	create_pgd_mapping(swapper_pg_dir, FIXADDR_START,
>   			   __pa_symbol(fixmap_pgd_next),

Thanks for pointing this out.  Given that this is the tip of my for-next I'm
just going to drop it, we'll sort out the bug and the conflict.

Re: linux-next: manual merge of the akpm-current tree with the risc-v tree

[Atish Patra]

On Tue, 2020-10-06 at 21:32 -0700, Palmer Dabbelt wrote:
> On Tue, 06 Oct 2020 03:39:06 PDT (-0700), Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the akpm-current tree got a conflict
> > in:
> > 
> >   arch/riscv/mm/init.c
> > 
> > between commit:
> > 
> >   c29c38fa2a8b ("RISC-V: Remove any memblock representing unusable
> > memory area")
> > 
> > from the risc-v tree and commits:
> > 
> >   3520eeb79142 ("arch, drivers: replace for_each_membock() with
> > for_each_mem_range()")
> > 
> > from the akpm-current tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your
> > tree
> > is submitted for merging.  You may also want to consider
> > cooperating
> > with the maintainer of the conflicting tree to minimise any
> > particularly
> > complex conflicts.
> > 
> > It also looks like there is a bug in that risc-v tree patch:
> > mem_start
> > is used uninitialised in setup_bootmem().
> > -- 
> > Cheers,
> > Stephen Rothwell
> > 
> > diff --cc arch/riscv/mm/init.c
> > index 812a48c91a95,bc72bb6b5fe0..000000000000
> > --- a/arch/riscv/mm/init.c
> > +++ b/arch/riscv/mm/init.c
> > @@@ -152,20 -141,25 +152,20 @@@ disable
> >   }
> >   #endif /* CONFIG_BLK_DEV_INITRD */
> >   
> >  -static phys_addr_t dtb_early_pa __initdata;
> >  -
> >   void __init setup_bootmem(void)
> >   {
> > - 	struct memblock_region *reg;
> > - 	phys_addr_t mem_start, end = 0;
> >  -	phys_addr_t mem_size = 0;
> >  -	phys_addr_t total_mem = 0;
> > + 	phys_addr_t mem_start, start, end = 0;
> >   	phys_addr_t vmlinux_end = __pa_symbol(&_end);
> >   	phys_addr_t vmlinux_start = __pa_symbol(&_start);
> > + 	u64 i;
> >   
> >   	/* Find the memory region containing the kernel */
> > - 	for_each_memblock(memory, reg) {
> > - 		end = reg->base + reg->size;
> > + 	for_each_mem_range(i, &start, &end) {
> > + 		phys_addr_t size = end - start;
> >  -		if (!total_mem)
> >  +		if (!mem_start)
> > - 			mem_start = reg->base;
> > - 		if (reg->base <= vmlinux_start && vmlinux_end <= end)
> > - 			BUG_ON(reg->size == 0);
> > + 			mem_start = start;
> > + 		if (start <= vmlinux_start && vmlinux_end <= end)
> > + 			BUG_ON(size == 0);
> >  -		total_mem = total_mem + size;
> >   	}
> >   
> >   	/*
> > @@@ -542,18 -455,11 +533,18 @@@ static void __init
> > setup_vm_final(void
> >   {
> >   	uintptr_t va, map_size;
> >   	phys_addr_t pa, start, end;
> > - 	struct memblock_region *reg;
> > + 	u64 i;
> >   
> >  -	/* Set mmu_enabled flag */
> >  -	mmu_enabled = true;
> >  -
> >  +	/**
> >  +	 * MMU is enabled at this point. But page table setup is not
> > complete yet.
> >  +	 * fixmap page table alloc functions should be used at this
> > point
> >  +	 */
> >  +	pt_ops.alloc_pte = alloc_pte_fixmap;
> >  +	pt_ops.get_pte_virt = get_pte_virt_fixmap;
> >  +#ifndef __PAGETABLE_PMD_FOLDED
> >  +	pt_ops.alloc_pmd = alloc_pmd_fixmap;
> >  +	pt_ops.get_pmd_virt = get_pmd_virt_fixmap;
> >  +#endif
> >   	/* Setup swapper PGD for fixmap */
> >   	create_pgd_mapping(swapper_pg_dir, FIXADDR_START,
> >   			   __pa_symbol(fixmap_pgd_next),
> 
> Thanks for pointing this out.  Given that this is the tip of my for-
> next I'm
> just going to drop it, we'll sort out the bug and the conflict.

Thanks. I will rebase on top of next after fixing the bug and resend.

-- 
Regards,
Atish

Re: linux-next: manual merge of the akpm-current tree with the risc-v tree

[Atish Patra]

On Tue, 2020-10-06 at 21:48 -0700, Atish Patra wrote:
> On Tue, 2020-10-06 at 21:32 -0700, Palmer Dabbelt wrote:
> > On Tue, 06 Oct 2020 03:39:06 PDT (-0700), Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > Today's linux-next merge of the akpm-current tree got a conflict
> > > in:
> > > 
> > >   arch/riscv/mm/init.c
> > > 
> > > between commit:
> > > 
> > >   c29c38fa2a8b ("RISC-V: Remove any memblock representing
> > > unusable
> > > memory area")
> > > 
> > > from the risc-v tree and commits:
> > > 
> > >   3520eeb79142 ("arch, drivers: replace for_each_membock() with
> > > for_each_mem_range()")
> > > 
> > > from the akpm-current tree.
> > > 
> > > I fixed it up (see below) and can carry the fix as necessary.
> > > This
> > > is now fixed as far as linux-next is concerned, but any non
> > > trivial
> > > conflicts should be mentioned to your upstream maintainer when
> > > your
> > > tree
> > > is submitted for merging.  You may also want to consider
> > > cooperating
> > > with the maintainer of the conflicting tree to minimise any
> > > particularly
> > > complex conflicts.
> > > 
> > > It also looks like there is a bug in that risc-v tree patch:
> > > mem_start
> > > is used uninitialised in setup_bootmem().
> > > -- 
> > > Cheers,
> > > Stephen Rothwell
> > > 
> > > diff --cc arch/riscv/mm/init.c
> > > index 812a48c91a95,bc72bb6b5fe0..000000000000
> > > --- a/arch/riscv/mm/init.c
> > > +++ b/arch/riscv/mm/init.c
> > > @@@ -152,20 -141,25 +152,20 @@@ disable
> > >   }
> > >   #endif /* CONFIG_BLK_DEV_INITRD */
> > >   
> > >  -static phys_addr_t dtb_early_pa __initdata;
> > >  -
> > >   void __init setup_bootmem(void)
> > >   {
> > > - 	struct memblock_region *reg;
> > > - 	phys_addr_t mem_start, end = 0;
> > >  -	phys_addr_t mem_size = 0;
> > >  -	phys_addr_t total_mem = 0;
> > > + 	phys_addr_t mem_start, start, end = 0;
> > >   	phys_addr_t vmlinux_end = __pa_symbol(&_end);
> > >   	phys_addr_t vmlinux_start = __pa_symbol(&_start);
> > > + 	u64 i;
> > >   
> > >   	/* Find the memory region containing the kernel */
> > > - 	for_each_memblock(memory, reg) {
> > > - 		end = reg->base + reg->size;
> > > + 	for_each_mem_range(i, &start, &end) {
> > > + 		phys_addr_t size = end - start;
> > >  -		if (!total_mem)
> > >  +		if (!mem_start)
> > > - 			mem_start = reg->base;
> > > - 		if (reg->base <= vmlinux_start && vmlinux_end
> > > <= end)
> > > - 			BUG_ON(reg->size == 0);
> > > + 			mem_start = start;
> > > + 		if (start <= vmlinux_start && vmlinux_end <=
> > > end)
> > > + 			BUG_ON(size == 0);
> > >  -		total_mem = total_mem + size;
> > >   	}
> > >   
> > >   	/*
> > > @@@ -542,18 -455,11 +533,18 @@@ static void __init
> > > setup_vm_final(void
> > >   {
> > >   	uintptr_t va, map_size;
> > >   	phys_addr_t pa, start, end;
> > > - 	struct memblock_region *reg;
> > > + 	u64 i;
> > >   
> > >  -	/* Set mmu_enabled flag */
> > >  -	mmu_enabled = true;
> > >  -
> > >  +	/**
> > >  +	 * MMU is enabled at this point. But page table setup
> > > is not
> > > complete yet.
> > >  +	 * fixmap page table alloc functions should be used at
> > > this
> > > point
> > >  +	 */
> > >  +	pt_ops.alloc_pte = alloc_pte_fixmap;
> > >  +	pt_ops.get_pte_virt = get_pte_virt_fixmap;
> > >  +#ifndef __PAGETABLE_PMD_FOLDED
> > >  +	pt_ops.alloc_pmd = alloc_pmd_fixmap;
> > >  +	pt_ops.get_pmd_virt = get_pmd_virt_fixmap;
> > >  +#endif
> > >   	/* Setup swapper PGD for fixmap */
> > >   	create_pgd_mapping(swapper_pg_dir, FIXADDR_START,
> > >   			   __pa_symbol(fixmap_pgd_next),
> > 
> > Thanks for pointing this out.  Given that this is the tip of my
> > for-
> > next I'm
> > just going to drop it, we'll sort out the bug and the conflict.
> 
> Thanks. I will rebase on top of next after fixing the bug and resend.
> 

Done. I have rebased the memblock patch(c29c38fa2a8b) and sent it to
the mailing list.

Some of the other conflicts are due to the patches in UEFI series. As
the series is going through multiple shared tree, I am not sure what is
the best course of action.

I also noticed that linux-next/master has an older version of UEFI
patches while for-next in riscv tree has the latest version. 

Please let me know if I need to resend the UEFI series.

-- 
Regards,
Atish

linux-next: manual merge of the akpm-current tree with the risc-v tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  arch/riscv/Kconfig

between commit:

  5cb0080f1bfd ("riscv: Enable ARCH_STACKWALK")

from the risc-v tree and commit:

  46b9b00649f6 ("arch, mm: restore dependency of __kernel_map_pages() on DEBUG_PAGEALLOC")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/riscv/Kconfig
index 8a2a0523a9a3,9283c6f9ae2a..000000000000
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@@ -14,7 -14,7 +14,8 @@@ config RISC
  	def_bool y
  	select ARCH_CLOCKSOURCE_INIT
  	select ARCH_SUPPORTS_ATOMIC_RMW
 +	select ARCH_STACKWALK
+ 	select ARCH_SUPPORTS_DEBUG_PAGEALLOC if MMU
  	select ARCH_HAS_BINFMT_FLAT
  	select ARCH_HAS_DEBUG_VM_PGTABLE
  	select ARCH_HAS_DEBUG_VIRTUAL if MMU

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

Re: linux-next: manual merge of the akpm-current tree with the risc-v tree

[Stephen Rothwell]

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

Hi all,

On Fri, 27 Nov 2020 18:34:41 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   arch/riscv/Kconfig
> 
> between commit:
> 
>   5cb0080f1bfd ("riscv: Enable ARCH_STACKWALK")
> 
> from the risc-v tree and commit:
> 
>   46b9b00649f6 ("arch, mm: restore dependency of __kernel_map_pages() on DEBUG_PAGEALLOC")
> 
> from the akpm-current tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> 
> diff --cc arch/riscv/Kconfig
> index 8a2a0523a9a3,9283c6f9ae2a..000000000000
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@@ -14,7 -14,7 +14,8 @@@ config RISC
>   	def_bool y
>   	select ARCH_CLOCKSOURCE_INIT
>   	select ARCH_SUPPORTS_ATOMIC_RMW
>  +	select ARCH_STACKWALK
> + 	select ARCH_SUPPORTS_DEBUG_PAGEALLOC if MMU
>   	select ARCH_HAS_BINFMT_FLAT
>   	select ARCH_HAS_DEBUG_VM_PGTABLE
>   	select ARCH_HAS_DEBUG_VIRTUAL if MMU

This is now a conflict between the risc-v tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: manual merge of the akpm-current tree with the risc-v tree

[Kefeng Wang]

On 2020/12/17 9:26, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 27 Nov 2020 18:34:41 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Today's linux-next merge of the akpm-current tree got a conflict in:
>>
>>    arch/riscv/Kconfig
>>
>> between commit:
>>
>>    5cb0080f1bfd ("riscv: Enable ARCH_STACKWALK")
>>
>> from the risc-v tree and commit:
>>
>>    46b9b00649f6 ("arch, mm: restore dependency of __kernel_map_pages() on DEBUG_PAGEALLOC")
>>
>> from the akpm-current tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary. This
>> is now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your tree
>> is submitted for merging.  You may also want to consider cooperating
>> with the maintainer of the conflicting tree to minimise any particularly
>> complex conflicts.
>>
>>
>> diff --cc arch/riscv/Kconfig
>> index 8a2a0523a9a3,9283c6f9ae2a..000000000000
>> --- a/arch/riscv/Kconfig
>> +++ b/arch/riscv/Kconfig
>> @@@ -14,7 -14,7 +14,8 @@@ config RISC
>>    	def_bool y
>>    	select ARCH_CLOCKSOURCE_INIT
>>    	select ARCH_SUPPORTS_ATOMIC_RMW
>>   +	select ARCH_STACKWALK
>> + 	select ARCH_SUPPORTS_DEBUG_PAGEALLOC if MMU
>>    	select ARCH_HAS_BINFMT_FLAT
>>    	select ARCH_HAS_DEBUG_VM_PGTABLE
>>    	select ARCH_HAS_DEBUG_VIRTUAL if MMU
> This is now a conflict between the risc-v tree and Linus' tree.

Could it be fixed in alphabetical order when merging riscv tree?



>

linux-next: manual merge of the akpm-current tree with the risc-v tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  lib/Makefile

between commit:

  527701eda5f1 ("lib: Add a generic version of devmem_is_allowed()")

from the risc-v tree and commits:

  8250e121c672 ("lib/list_kunit: follow new file name convention for KUnit tests")
  17bf776cf09a ("lib/linear_ranges_kunit: follow new file name convention for KUnit tests")
  23fa4e39ee62 ("lib/bits_kunit: follow new file name convention for KUnit tests")
  1987f84faec6 ("lib/cmdline_kunit: add a new test suite for cmdline API")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc lib/Makefile
index bcedd691ef63,dc623561ef9d..000000000000
--- a/lib/Makefile
+++ b/lib/Makefile
@@@ -350,8 -350,7 +350,9 @@@ obj-$(CONFIG_PLDMFW) += pldmfw
  
  # KUnit tests
  obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o
- obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
- obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
- obj-$(CONFIG_BITS_TEST) += test_bits.o
+ obj-$(CONFIG_BITS_TEST) += bits_kunit.o
+ obj-$(CONFIG_CMDLINE_KUNIT_TEST) += cmdline_kunit.o
+ obj-$(CONFIG_LINEAR_RANGES_TEST) += linear_ranges_kunit.o
+ obj-$(CONFIG_LIST_KUNIT_TEST) += list_kunit.o
 +
 +obj-$(CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED) += devmem_is_allowed.o

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

Re: linux-next: manual merge of the akpm-current tree with the risc-v tree

[Andy Shevchenko]

On Mon, Dec 14, 2020 at 08:21:07PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   lib/Makefile
> 
> between commit:
> 
>   527701eda5f1 ("lib: Add a generic version of devmem_is_allowed()")
> 
> from the risc-v tree and commits:
> 
>   8250e121c672 ("lib/list_kunit: follow new file name convention for KUnit tests")
>   17bf776cf09a ("lib/linear_ranges_kunit: follow new file name convention for KUnit tests")
>   23fa4e39ee62 ("lib/bits_kunit: follow new file name convention for KUnit tests")
>   1987f84faec6 ("lib/cmdline_kunit: add a new test suite for cmdline API")
> 
> from the akpm-current tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Looks good enough (*) to me, thanks!

*) I think we might group that new line with an existing one(s) of the same
level (GENERIC_LIB) but it doesn't really matter.

> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc lib/Makefile
> index bcedd691ef63,dc623561ef9d..000000000000
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@@ -350,8 -350,7 +350,9 @@@ obj-$(CONFIG_PLDMFW) += pldmfw
>   
>   # KUnit tests
>   obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o
> - obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
> - obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
> - obj-$(CONFIG_BITS_TEST) += test_bits.o
> + obj-$(CONFIG_BITS_TEST) += bits_kunit.o
> + obj-$(CONFIG_CMDLINE_KUNIT_TEST) += cmdline_kunit.o
> + obj-$(CONFIG_LINEAR_RANGES_TEST) += linear_ranges_kunit.o
> + obj-$(CONFIG_LIST_KUNIT_TEST) += list_kunit.o
>  +
>  +obj-$(CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED) += devmem_is_allowed.o



-- 
With Best Regards,
Andy Shevchenko

Re: linux-next: manual merge of the akpm-current tree with the risc-v tree

[Palmer Dabbelt]

On Mon, 14 Dec 2020 09:37:47 PST (-0800), andriy.shevchenko@linux.intel.com wrote:
> On Mon, Dec 14, 2020 at 08:21:07PM +1100, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the akpm-current tree got a conflict in:
>>
>>   lib/Makefile
>>
>> between commit:
>>
>>   527701eda5f1 ("lib: Add a generic version of devmem_is_allowed()")
>>
>> from the risc-v tree and commits:
>>
>>   8250e121c672 ("lib/list_kunit: follow new file name convention for KUnit tests")
>>   17bf776cf09a ("lib/linear_ranges_kunit: follow new file name convention for KUnit tests")
>>   23fa4e39ee62 ("lib/bits_kunit: follow new file name convention for KUnit tests")
>>   1987f84faec6 ("lib/cmdline_kunit: add a new test suite for cmdline API")
>>
>> from the akpm-current tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary. This
>> is now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your tree
>> is submitted for merging.  You may also want to consider cooperating
>> with the maintainer of the conflicting tree to minimise any particularly
>> complex conflicts.
>
> Looks good enough (*) to me, thanks!
>
> *) I think we might group that new line with an existing one(s) of the same
> level (GENERIC_LIB) but it doesn't really matter.

I went back and forth on that one: it's got the same Kconfig name, but it's not
a libgcc function.  Maybe we shouldn't have had the "_LIB" in there?  I don't
remember if that was meant to stand for libgcc or lib/...

I'm happy to just re-spin my patch to avoid the conflict.  It's near/at the top
of my tree, so it's not a big deal, but I'm also just OK merging second and
pointing out the conflict.  Unless you care one way or the other I'll just do
whatever ends up being easier for me :)

>> --
>> Cheers,
>> Stephen Rothwell
>>
>> diff --cc lib/Makefile
>> index bcedd691ef63,dc623561ef9d..000000000000
>> --- a/lib/Makefile
>> +++ b/lib/Makefile
>> @@@ -350,8 -350,7 +350,9 @@@ obj-$(CONFIG_PLDMFW) += pldmfw
>>
>>   # KUnit tests
>>   obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o
>> - obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
>> - obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
>> - obj-$(CONFIG_BITS_TEST) += test_bits.o
>> + obj-$(CONFIG_BITS_TEST) += bits_kunit.o
>> + obj-$(CONFIG_CMDLINE_KUNIT_TEST) += cmdline_kunit.o
>> + obj-$(CONFIG_LINEAR_RANGES_TEST) += linear_ranges_kunit.o
>> + obj-$(CONFIG_LIST_KUNIT_TEST) += list_kunit.o
>>  +
>>  +obj-$(CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED) += devmem_is_allowed.o

Re: linux-next: manual merge of the akpm-current tree with the risc-v tree

[Stephen Rothwell]

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

Hi all,

On Mon, 14 Dec 2020 20:21:07 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   lib/Makefile
> 
> between commit:
> 
>   527701eda5f1 ("lib: Add a generic version of devmem_is_allowed()")
> 
> from the risc-v tree and commits:
> 
>   8250e121c672 ("lib/list_kunit: follow new file name convention for KUnit tests")
>   17bf776cf09a ("lib/linear_ranges_kunit: follow new file name convention for KUnit tests")
>   23fa4e39ee62 ("lib/bits_kunit: follow new file name convention for KUnit tests")
>   1987f84faec6 ("lib/cmdline_kunit: add a new test suite for cmdline API")
> 
> from the akpm-current tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> 
> diff --cc lib/Makefile
> index bcedd691ef63,dc623561ef9d..000000000000
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@@ -350,8 -350,7 +350,9 @@@ obj-$(CONFIG_PLDMFW) += pldmfw
>   
>   # KUnit tests
>   obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o
> - obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
> - obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
> - obj-$(CONFIG_BITS_TEST) += test_bits.o
> + obj-$(CONFIG_BITS_TEST) += bits_kunit.o
> + obj-$(CONFIG_CMDLINE_KUNIT_TEST) += cmdline_kunit.o
> + obj-$(CONFIG_LINEAR_RANGES_TEST) += linear_ranges_kunit.o
> + obj-$(CONFIG_LIST_KUNIT_TEST) += list_kunit.o
>  +
>  +obj-$(CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED) += devmem_is_allowed.o

This is now a conflict between the risc-v tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: manual merge of the akpm-current tree with the risc-v tree

[Andy Shevchenko]

On Thu, Dec 17, 2020 at 3:28 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> On Mon, 14 Dec 2020 20:21:07 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the akpm-current tree got a conflict in:
> >
> >   lib/Makefile
> >
> > between commit:
> >
> >   527701eda5f1 ("lib: Add a generic version of devmem_is_allowed()")
> >
> > from the risc-v tree and commits:
> >
> >   8250e121c672 ("lib/list_kunit: follow new file name convention for KUnit tests")
> >   17bf776cf09a ("lib/linear_ranges_kunit: follow new file name convention for KUnit tests")
> >   23fa4e39ee62 ("lib/bits_kunit: follow new file name convention for KUnit tests")
> >   1987f84faec6 ("lib/cmdline_kunit: add a new test suite for cmdline API")

AFAIU Linus rejected the above patches. I hope kselftest/kunit tree
can pick them up.

> > diff --cc lib/Makefile
> > index bcedd691ef63,dc623561ef9d..000000000000
> > --- a/lib/Makefile
> > +++ b/lib/Makefile
> > @@@ -350,8 -350,7 +350,9 @@@ obj-$(CONFIG_PLDMFW) += pldmfw
> >
> >   # KUnit tests
> >   obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o
> > - obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
> > - obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
> > - obj-$(CONFIG_BITS_TEST) += test_bits.o
> > + obj-$(CONFIG_BITS_TEST) += bits_kunit.o
> > + obj-$(CONFIG_CMDLINE_KUNIT_TEST) += cmdline_kunit.o
> > + obj-$(CONFIG_LINEAR_RANGES_TEST) += linear_ranges_kunit.o
> > + obj-$(CONFIG_LIST_KUNIT_TEST) += list_kunit.o
> >  +
> >  +obj-$(CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED) += devmem_is_allowed.o
>
> This is now a conflict between the risc-v tree and Linus' tree.

Yeah, and it's slightly different. Perhaps RISC-V tree can handle this
by moving Makefile entry somewhere else in the file.

-- 
With Best Regards,
Andy Shevchenko

Re: linux-next: manual merge of the akpm-current tree with the risc-v tree

[Stephen Rothwell]

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

Hi Andy,

On Thu, 17 Dec 2020 11:40:51 +0200 Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>
> Yeah, and it's slightly different. Perhaps RISC-V tree can handle this
> by moving Makefile entry somewhere else in the file.

Or just let Linus take care of it ...

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: manual merge of the akpm-current tree with the risc-v tree

[Palmer Dabbelt]

On Thu, 17 Dec 2020 01:40:51 PST (-0800), andy.shevchenko@gmail.com wrote:
> On Thu, Dec 17, 2020 at 3:28 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Hi all,
>>
>> On Mon, 14 Dec 2020 20:21:07 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> >
>> > Today's linux-next merge of the akpm-current tree got a conflict in:
>> >
>> >   lib/Makefile
>> >
>> > between commit:
>> >
>> >   527701eda5f1 ("lib: Add a generic version of devmem_is_allowed()")
>> >
>> > from the risc-v tree and commits:
>> >
>> >   8250e121c672 ("lib/list_kunit: follow new file name convention for KUnit tests")
>> >   17bf776cf09a ("lib/linear_ranges_kunit: follow new file name convention for KUnit tests")
>> >   23fa4e39ee62 ("lib/bits_kunit: follow new file name convention for KUnit tests")
>> >   1987f84faec6 ("lib/cmdline_kunit: add a new test suite for cmdline API")
>
> AFAIU Linus rejected the above patches. I hope kselftest/kunit tree
> can pick them up.
>
>> > diff --cc lib/Makefile
>> > index bcedd691ef63,dc623561ef9d..000000000000
>> > --- a/lib/Makefile
>> > +++ b/lib/Makefile
>> > @@@ -350,8 -350,7 +350,9 @@@ obj-$(CONFIG_PLDMFW) += pldmfw
>> >
>> >   # KUnit tests
>> >   obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o
>> > - obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
>> > - obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
>> > - obj-$(CONFIG_BITS_TEST) += test_bits.o
>> > + obj-$(CONFIG_BITS_TEST) += bits_kunit.o
>> > + obj-$(CONFIG_CMDLINE_KUNIT_TEST) += cmdline_kunit.o
>> > + obj-$(CONFIG_LINEAR_RANGES_TEST) += linear_ranges_kunit.o
>> > + obj-$(CONFIG_LIST_KUNIT_TEST) += list_kunit.o
>> >  +
>> >  +obj-$(CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED) += devmem_is_allowed.o
>>
>> This is now a conflict between the risc-v tree and Linus' tree.
>
> Yeah, and it's slightly different. Perhaps RISC-V tree can handle this
> by moving Makefile entry somewhere else in the file.

I was planning on just posting the merge conflict along with the PR, which I
was going to do this morning (though in practice that means this afternoon...
;)).  I'd been considering fixing this stuff as I was likely going to have to
rewrite history to sort out our boot bug, but as it's only manifesting on
old-ish QEMU versions I've decided that it's not really worth making it a
blocker.

If you think that's an issue then I'm happy to rewrite my history, but I do
generally try to stay away from that and for this sort of thing I've yet to
have any complaints.  I probably will put it up near the other GENERIC_LIB
stuff in my conflict resolution, though.

linux-next: manual merge of the akpm-current tree with the risc-v tree

[Stephen Rothwell]

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

Hi all,

Tomorrow's linux-next merge of the akpm-current tree will get a
conflict in:

  Documentation/admin-guide/kernel-parameters.txt

between commit:

  f6e5aedf470b ("riscv: Add support for memtest")

from the risc-v tree and commit:

  6b8f5ba8661b ("mm,memory_hotplug: add kernel boot option to enable memmap_on_memory")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/admin-guide/kernel-parameters.txt
index b816481dfaef,04b4e76be65b..000000000000
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@@ -2800,23 -2802,7 +2808,23 @@@
  			seconds.  Use this parameter to check at some
  			other rate.  0 disables periodic checking.
  
 +	memory_hotplug.memmap_on_memory
 +			[KNL,X86,ARM] Boolean flag to enable this feature.
 +			Format: {on | off (default)}
 +			When enabled, memory to build the pages tables for the
 +			memmap array describing the hot-added range will be taken
 +			from the range itself, so the memmap page tables will be
 +			self-hosted.
 +			Since only single memory device ranges are supported at
 +			the moment, this option is disabled by default because
 +			it might have an impact on workloads that needs large
 +			contiguous memory chunks.
 +			The state of the flag can be read in
 +			/sys/module/memory_hotplug/parameters/memmap_on_memory.
 +			Note that even when enabled, there are a few cases where
 +			the feature is not effective.
 +
- 	memtest=	[KNL,X86,ARM,PPC] Enable memtest
+ 	memtest=	[KNL,X86,ARM,PPC,RISCV] Enable memtest
  			Format: <integer>
  			default : 0 <disable>
  			Specifies the number of memtest passes to be

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

Re: linux-next: manual merge of the akpm-current tree with the risc-v tree

[Stephen Rothwell]

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

Hi all,

On Fri, 12 Mar 2021 17:37:02 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Tomorrow's linux-next merge of the akpm-current tree will get a
> conflict in:
> 
>   Documentation/admin-guide/kernel-parameters.txt
> 
> between commit:
> 
>   f6e5aedf470b ("riscv: Add support for memtest")
> 
> from the risc-v tree and commit:
> 
>   6b8f5ba8661b ("mm,memory_hotplug: add kernel boot option to enable memmap_on_memory")
> 
> from the akpm-current tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc Documentation/admin-guide/kernel-parameters.txt
> index b816481dfaef,04b4e76be65b..000000000000
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@@ -2800,23 -2802,7 +2808,23 @@@
>   			seconds.  Use this parameter to check at some
>   			other rate.  0 disables periodic checking.
>   
>  +	memory_hotplug.memmap_on_memory
>  +			[KNL,X86,ARM] Boolean flag to enable this feature.
>  +			Format: {on | off (default)}
>  +			When enabled, memory to build the pages tables for the
>  +			memmap array describing the hot-added range will be taken
>  +			from the range itself, so the memmap page tables will be
>  +			self-hosted.
>  +			Since only single memory device ranges are supported at
>  +			the moment, this option is disabled by default because
>  +			it might have an impact on workloads that needs large
>  +			contiguous memory chunks.
>  +			The state of the flag can be read in
>  +			/sys/module/memory_hotplug/parameters/memmap_on_memory.
>  +			Note that even when enabled, there are a few cases where
>  +			the feature is not effective.
>  +
> - 	memtest=	[KNL,X86,ARM,PPC] Enable memtest
> + 	memtest=	[KNL,X86,ARM,PPC,RISCV] Enable memtest
>   			Format: <integer>
>   			default : 0 <disable>
>   			Specifies the number of memtest passes to be

This is now a conflict between the risc-v tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

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

linux-next: manual merge of the akpm-current tree with the risc-v tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  arch/riscv/Kconfig

between commit:

  7fa865f5640a ("riscv: TRANSPARENT_HUGEPAGE: depends on MMU")

from the risc-v tree and commit:

  f36992ff3525 ("mm: generalize ZONE_[DMA|DMA32]")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

I did the minimal fixup, but really, these selects should remain sorted.
-- 
Cheers,
Stephen Rothwell

diff --cc arch/riscv/Kconfig
index 2eedaf621bc7,6ee11ca998b2..000000000000
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@@ -106,7 -104,7 +106,8 @@@ config RISC
  	select SYSCTL_EXCEPTION_TRACE
  	select THREAD_INFO_IN_TASK
  	select UACCESS_MEMCPY if !MMU
 +	select HAVE_ARCH_TRANSPARENT_HUGEPAGE if 64BIT && MMU
+ 	select ZONE_DMA32 if 64BIT
  
  config ARCH_MMAP_RND_BITS_MIN
  	default 18 if 64BIT

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