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@xxxxxxxxx wrote:
> On Thu, Dec 17, 2020 at 3:28 AM Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
> > Hi all,
> >
> > On Mon, 14 Dec 2020 20:21:07 +1100 Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> 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.