Messages in this thread | | | Date | Thu, 17 Dec 2020 09:06:23 -0800 (PST) | Subject | Re: linux-next: manual merge of the akpm-current tree with the risc-v tree | From | 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.
| |