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

Palmer Dabbelt
2020-12-17T17:07:06Z

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.