linux-kernel - Re: [PATCH v3 00/14] mips: Prepare MIPS-arch code for Baikal-T1 SoC support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200521134813.tv2aqikvh45gryc4@mobilestation>
Date:   Thu, 21 May 2020 16:48:13 +0300
From:   Serge Semin <Sergey.Semin@...kalelectronics.ru>
To:     Arnd Bergmann <arnd@...db.de>
CC:     Serge Semin <fancer.lancer@...il.com>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
        Maxim Kaurkin <Maxim.Kaurkin@...kalelectronics.ru>,
        Pavel Parkhomenko <Pavel.Parkhomenko@...kalelectronics.ru>,
        Ramil Zaripov <Ramil.Zaripov@...kalelectronics.ru>,
        Ekaterina Skachko <Ekaterina.Skachko@...kalelectronics.ru>,
        Vadim Vlasov <V.Vlasov@...kalelectronics.ru>,
        Alexey Kolotnikov <Alexey.Kolotnikov@...kalelectronics.ru>,
        Paul Burton <paul.burton@...tec.com>,
        Ralf Baechle <ralf@...ux-mips.org>,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Tony Lindgren <tony@...mide.com>,
        Olof Johansson <olof@...om.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        "open list:BROADCOM NVRAM DRIVER" <linux-mips@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 00/14] mips: Prepare MIPS-arch code for Baikal-T1 SoC
 support

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@...ha.franken.de> 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