From: Arnd Bergmann <arnd@arndb.de>
To: noralf@tronnes.org
Cc: 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 17:04:21 +0200 [thread overview]
Message-ID: <CAK8P3a1fzr9kX4kNcAnM4ZPh_-Kp61326zrbhDjHyPJJrJq=OQ@mail.gmail.com> (raw)
In-Reply-To: <af5994a3-5739-ed7f-4374-85e9d19d2408@tronnes.org>
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.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: noralf@tronnes.org
Cc: tzimmermann@suse.de, David Airlie <airlied@linux.ie>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Souptick Joarder <jrdr.linux@gmail.com>,
Leonard Crestez <leonard.crestez@nxp.com>,
Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH] drm/imx: move 'legacyfb_depth' definition out of #ifdef
Date: Thu, 4 Oct 2018 17:04:21 +0200 [thread overview]
Message-ID: <CAK8P3a1fzr9kX4kNcAnM4ZPh_-Kp61326zrbhDjHyPJJrJq=OQ@mail.gmail.com> (raw)
In-Reply-To: <af5994a3-5739-ed7f-4374-85e9d19d2408@tronnes.org>
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.
Arnd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-10-04 15:04 UTC|newest]
Thread overview: 14+ 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 15:49 ` Noralf Trønnes
2018-10-03 16:13 ` Daniel Vetter
2018-10-03 19:51 ` Arnd Bergmann
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 14:43 ` Noralf Trønnes
2018-10-04 15:04 ` Arnd Bergmann [this message]
2018-10-04 15:04 ` Arnd Bergmann
2018-10-04 19:35 ` Daniel Vetter
2018-10-04 19:35 ` Daniel Vetter
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='CAK8P3a1fzr9kX4kNcAnM4ZPh_-Kp61326zrbhDjHyPJJrJq=OQ@mail.gmail.com' \
--to=arnd@arndb.de \
--cc=airlied@linux.ie \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.