linux-kernel - Re: linux-next: manual merge of the gpio tree with the mfd tree

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] [day] [month] [year] [list]

Date:   Tue, 9 Jul 2019 15:20:05 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Lee Jones <lee.jones@...aro.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>
Subject: Re: linux-next: manual merge of the gpio tree with the mfd tree

Hi Stephen, Linus

On Tue, Jul 9, 2019 at 2:16 AM Stephen Rothwell <sfr@...b.auug.org.au> wrote:

> > Today's linux-next merge of the gpio tree got a conflict in:
> >
> >   drivers/gpio/Makefile
> >
> > between commit:
> >
> >   18bc64b3aebf ("gpio: Initial support for ROHM bd70528 GPIO block")
> >
> > from the mfd tree and commit:
> >
> >   db16bad6efd9 ("gpio: Sort GPIO drivers in Makefile")
> >
> > from the gpio tree.
(...)
> I am still getting this conflict (the commit ids may have changed).
> Just a reminder in case you think Linus may need to know.

Of course I forgot to mention that in my pull request to Torvalds.

Linus: there might be some trival merge conflict in the Makefile
because Geert made a patch restructuring the Makefile and a
new GPIO driver was merged orthogonally in the MFD tree.

The resolution should be trivial, and the end result that we see
less of this because now the files are in alphabetic order so
we (or so it is believed) get a rectangular distribution of
conflicts since all filenames are equally plausible (yeah right).
It's a best effort to keep some sane order at least.

Yours,
Linus Walleij