Hello Arnd.
On Thu, May 21, 2020 at 09:30:08AM +0200, Arnd Bergmann wrote:
> On Thu, May 21, 2020 at 9:18 AM Thomas Bogendoerfer
> <tsbogend@xxxxxxxxxxxxxxxx> wrote:
> > On Thu, May 21, 2020 at 03:42:17AM +0300, Serge Semin wrote:
> > > On Thu, May 21, 2020 at 03:34:29AM +0300, Serge Semin wrote:
> > > >
> > > > This patchset is rebased and tested on the mainline Linux kernel 5.7-rc4:
> > > > base-commit: 0e698dfa2822 ("Linux 5.7-rc4")
> > > > tag: v5.7-rc4
> > >
> > > Thomas,
> > > Please note that this patchset is based on the Linux 5.7-rc4 tree (it most likely
> > > will get cleanly applied on rc6 as well), while mips-next is still at rc1. Due
> > > to that the patchset fails to be applied on mips-next. I think it would be
> > > better first to merge the last Linux tree into the mips-next, then try to merge
> > > this patchset in. Should you have any problem after that, please let me know.
> > > I'll resend the patchset being rebased on top of the new mips-next tree.
> >
> > no, that's not how it works. Please rebase your patches on top of
> > mips-next. Thank you.
>
> Right, backmerges should generally be avoided. However if something
> between rc1 and rc4 is required to make Baikal-T1 work, rebasing it to
> rc1 would make it non-bisectable, which is also bad.
>
> Serge, are you aware of something in -rc4 that is needed as a dependency?
Not I am aware of. Regarding my suggestion. It's not like I was going to
delegate a work or something. It's that a merge conflict is connected with
MODULE_PROC_FAMILY macro being moved to a dedicated file vermagic.h file:
62d0fd591db1 ("arch: split MODULE_ARCH_VERMAGIC definitions out to <asm/vermagic.h>").
Since I've already fixed it, Thomas wouldn't need to worry about the problem
anymore if he first merged the kernel master branch in first, which he would
have done anyway eventually. Since it's not an option and as you said backmerges
should be avoided, then I'll rebase the patchset onto the mips-next, and then
resend.
-Sergey
>
> Arnd
