linux-kernel - Re: linux-next: build failure after merge of the drm-misc 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]

Message-ID: <20170724183328.GA7564@kroah.com>
Date:   Mon, 24 Jul 2017 11:33:28 -0700
From:   Greg KH <greg@...ah.com>
To:     Daniel Vetter <daniel.vetter@...ll.ch>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Dave Airlie <airlied@...ux.ie>,
        Intel Graphics <intel-gfx@...ts.freedesktop.org>,
        DRI <dri-devel@...ts.freedesktop.org>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Hans de Goede <hdegoede@...hat.com>
Subject: Re: linux-next: build failure after merge of the drm-misc tree

On Mon, Jul 24, 2017 at 10:24:41AM +0200, Daniel Vetter wrote:
> On Mon, Jul 24, 2017 at 2:03 AM, Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> > Hi Daniel,
> >
> > On Fri, 21 Jul 2017 09:24:49 +0200 Daniel Vetter <daniel.vetter@...ll.ch> wrote:
> >>
> >> How are we going to handle this now? The refactor is deeply burried in
> >> drm-misc, I guess you could cherry-pick the relevant patches over. But
> >> that'll probably lead to more conflicts because git will get confused.
> >
> > I'll just keep applying the merge resolution patch and will remind Dave
> > and Greg about it during the week before the merge window opens so that
> > they can let Linus know that the fix up is needed.
> 
> Well, Greg squeezed the vbox driver into -rc2, so now we already get
> to resolve this in a backmerge. And hopefully the bikeshed patches in
> -staging won't interfere too badly with whatever refactoring we'll do
> in drm-next.
> 
> Greg, fyi this is the last time I'll ack a drm driver for staging.
> This just doesn't work. We're spending more time here working the
> -staging vs. drm-next conflicts than the actual vbox driver review has
> taken me. And probly less than the cleanup for merging directly to
> drm-next will end up taking.

Hey, I was amazed that you all acked it, and it's why I required that
you do so before I took it :)

Good luck with the merges!

greg k-h