[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a1fzr9kX4kNcAnM4ZPh_-Kp61326zrbhDjHyPJJrJq=OQ@mail.gmail.com>
Date: Thu, 4 Oct 2018 17:04:21 +0200
From: Arnd Bergmann <arnd@...db.de>
To: noralf@...nnes.org
Cc: Daniel Vetter <daniel.vetter@...ll.ch>,
Philipp Zabel <p.zabel@...gutronix.de>,
David Airlie <airlied@...ux.ie>,
Lucas Stach <l.stach@...gutronix.de>,
Sam Ravnborg <sam@...nborg.org>,
Souptick Joarder <jrdr.linux@...il.com>,
Leonard Crestez <leonard.crestez@....com>, tzimmermann@...e.de,
dri-devel <dri-devel@...ts.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm/imx: move 'legacyfb_depth' definition out of #ifdef
On Thu, Oct 4, 2018 at 4:43 PM Noralf Trønnes <noralf@...nnes.org> wrote:
> Den 04.10.2018 09.48, skrev Daniel Vetter:
> > On Wed, Oct 3, 2018 at 9:51 PM Arnd Bergmann <arnd@...db.de> wrote:
> >> On Wed, Oct 3, 2018 at 6:13 PM Daniel Vetter <daniel@...ll.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@...db.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
Powered by blists - more mailing lists