From: Daniel Vetter <daniel@ffwll.ch>
To: Arnd Bergmann <arnd@arndb.de>
Cc: noralf@tronnes.org, Daniel Vetter <daniel.vetter@ffwll.ch>,
Philipp Zabel <p.zabel@pengutronix.de>,
David Airlie <airlied@linux.ie>,
Lucas Stach <l.stach@pengutronix.de>,
Sam Ravnborg <sam@ravnborg.org>,
Souptick Joarder <jrdr.linux@gmail.com>,
Leonard Crestez <leonard.crestez@nxp.com>,
tzimmermann@suse.de, dri-devel <dri-devel@lists.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drm/imx: move 'legacyfb_depth' definition out of #ifdef
Date: Thu, 4 Oct 2018 21:35:43 +0200 [thread overview]
Message-ID: <20181004193543.GQ31561@phenom.ffwll.local> (raw)
In-Reply-To: <CAK8P3a1fzr9kX4kNcAnM4ZPh_-Kp61326zrbhDjHyPJJrJq=OQ@mail.gmail.com>
On Thu, Oct 04, 2018 at 05:04:21PM +0200, Arnd Bergmann wrote:
> On Thu, Oct 4, 2018 at 4:43 PM Noralf Trønnes <noralf@tronnes.org> wrote:
> > Den 04.10.2018 09.48, skrev Daniel Vetter:
> > > On Wed, Oct 3, 2018 at 9:51 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > >> On Wed, Oct 3, 2018 at 6:13 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > >>> On Wed, Oct 03, 2018 at 05:49:32PM +0200, Noralf Trønnes wrote:
> > >>>>
> > >>>> Den 02.10.2018 22.58, skrev Arnd Bergmann:
> > >>>>> The variable is now referenced unconditionally, but still
> > >>>>> declared in an #ifdef:
> > >>>>>
> > >>>>> drivers/gpu/drm/imx/imx-drm-core.c: In function 'imx_drm_bind':
> > >>>>> drivers/gpu/drm/imx/imx-drm-core.c:264:6: error: 'legacyfb_depth' undeclared (first use in this function); did you mean 'lockdep_depth'?
> > >>>>>
> > >>>>> Remove the #ifdef so it can always be accessed.
> > >>>>>
> > >>>>> Fixes: f53705fd9803 ("drm/imx: Use drm_fbdev_generic_setup()")
> > >>>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > >>>>> ---
> > >>>> I've already applied the previous one you sent:
> > >>>> https://cgit.freedesktop.org/drm/drm-misc/commit/?id=064b06bbf117f8b5e64a5143e970d5a1cf602fd6
> > >>>>
> > >>>> Not sure when it reaches linux-next now that we are past rc6.
> > >>> Only once we're past -rc1.
> > >> Can we revert f53705fd9803 in linux-next then to prevent the regression from
> > >> making it into 4.20?
> > > Probably simpler to cherry pick the fix from drm-misc-next to
> > > drm-misc-next-fixes. Noralf, can you pls do that?
> >
> > Would this be the correct procudure:
> >
> > dim update-branches
> > dim create-workdir drm-misc-next-fixes
> > <build>
> > CONFIG_DRM_FBDEV_EMULATION=n
> > <build will break>
> > git cherry-pick 064b06bbf117f8b5e64a5143e970d5a1cf602fd6
> > <build passes>
> > dim push-branch drm-misc-next-fixes
> >
> > I read that cherry picking creates a new commit with a new hash.
> > But since you ask me to do this, I assume git will handle this when
> > branches are merged?
>
> The git history will show both commit IDs, which is a bit ugly but
> ok if it's rare enough. There is a chance for creating a conflict if the
> backport changes context, or one branch contains extra changes
> that touch the same lines, but usually this is not a problem.
+1, and your recipe looks good too. drm-intel works entirely on these
cherry-picks, and we've done it a few times in drm-misc too. Having to
cherry-pick is one of the downsides of group maintainership, since you
really can't rebase trees at will. Definitely not the -next queue.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2018-10-04 19:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-02 20:58 [PATCH] drm/imx: move 'legacyfb_depth' definition out of #ifdef Arnd Bergmann
2018-10-03 15:49 ` Noralf Trønnes
2018-10-03 16:13 ` Daniel Vetter
2018-10-03 19:51 ` Arnd Bergmann
2018-10-04 7:48 ` Daniel Vetter
2018-10-04 14:43 ` Noralf Trønnes
2018-10-04 15:04 ` Arnd Bergmann
2018-10-04 19:35 ` Daniel Vetter [this message]
2018-10-05 10:22 ` Noralf Trønnes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181004193543.GQ31561@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=airlied@linux.ie \
--cc=arnd@arndb.de \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=jrdr.linux@gmail.com \
--cc=l.stach@pengutronix.de \
--cc=leonard.crestez@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=noralf@tronnes.org \
--cc=p.zabel@pengutronix.de \
--cc=sam@ravnborg.org \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).