Re: linux-next: manual merge of the akpm-current tree with the risc-v tree
On Thu, 17 Dec 2020 01:40:51 PST (-0800), andy.shevche...@gmail.com wrote:
On Thu, Dec 17, 2020 at 3:28 AM Stephen Rothwell wrote:
Hi all,
On Mon, 14 Dec 2020 20:21:07 +1100 Stephen Rothwell
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..
> --- 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.
Re: linux-next: manual merge of the akpm-current tree with the risc-v tree
Hi Andy, On Thu, 17 Dec 2020 11:40:51 +0200 Andy Shevchenko 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 pgprUxnfVtQtO.pgp Description: OpenPGP digital signature
Re: linux-next: manual merge of the akpm-current tree with the risc-v tree
On Thu, Dec 17, 2020 at 3:28 AM Stephen Rothwell wrote:
>
> Hi all,
>
> On Mon, 14 Dec 2020 20:21:07 +1100 Stephen Rothwell
> 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..
> > --- 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
On 2020/12/17 9:26, Stephen Rothwell wrote:
Hi all,
On Fri, 27 Nov 2020 18:34:41 +1100 Stephen Rothwell
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..
--- 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?
Re: linux-next: manual merge of the akpm-current tree with the risc-v tree
Hi all,
On Fri, 27 Nov 2020 18:34:41 +1100 Stephen Rothwell
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..
> --- 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
pgpeEYGAzWMTz.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the akpm-current tree with the risc-v tree
Hi all,
On Mon, 14 Dec 2020 20:21:07 +1100 Stephen Rothwell
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..
> --- 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
pgp997akoF_XO.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the akpm-current tree with the risc-v tree
On Mon, 14 Dec 2020 09:37:47 PST (-0800), andriy.shevche...@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..
--- 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
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..
> --- 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
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..
> > > --- 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
Re: linux-next: manual merge of the akpm-current tree with the risc-v tree
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..
> > --- 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
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..
--- 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.
