[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160622082336.GN23520@phenom.ffwll.local>
Date: Wed, 22 Jun 2016 10:23:36 +0200
From: Daniel Vetter <daniel@...ll.ch>
To: Russell King <rmk@...linux.org.uk>
Cc: Daniel Vetter <daniel.vetter@...ll.ch>,
Stephen Rothwell <sfr@...b.auug.org.au>,
intel-gfx <intel-gfx@...ts.freedesktop.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
linux-next <linux-next@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Benjamin Gaignard <benjamin.gaignard@...aro.org>
Subject: Re: linux-next: manual merge of the drm-misc tree with the arm tree
On Wed, Jun 22, 2016 at 09:21:11AM +0100, Russell King wrote:
> On Wed, Jun 22, 2016 at 09:31:18AM +0200, Daniel Vetter wrote:
> > On Wed, Jun 22, 2016 at 3:47 AM, Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> > > Hi all,
> > >
> > > Today's linux-next merge of the drm-misc tree got a conflict in:
> > >
> > > drivers/gpu/drm/sti/sti_drv.c
> > >
> > > between commit:
> > >
> > > 062993b15e8e ("drm: convert DT component matching to component_match_add_release()")
> >
> > Why did that one end up in the arm tree? Should it go in through
> > drm-misc instead?
>
> Mine is part of a three part patch series which is part of the component
> helper updates (which I'm the author and maintainer of).
>
> Then someone came up with an alternative way of some of part of it.
>
> You can't merge the above DRM part, because that means you also need to
> merge patch 1, which is core component stuff.
Makes sense, but generally in that case I ask Dave for an explicit ack for
merging through another tree to avoid confusion. Lack of that is why I
asked.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Powered by blists - more mailing lists