[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e3aeb07f-34e6-6ae5-61b1-bb357b0a7aef@redhat.com>
Date: Sat, 27 Nov 2021 20:40:22 +0100
From: Javier Martinez Canillas <javierm@...hat.com>
To: linux-kernel@...r.kernel.org, kernel test robot <lkp@...el.com>,
David Airlie <airlied@...ux.ie>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jani Nikula <jani.nikula@...el.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Pekka Paalanen <pekka.paalanen@...labora.com>,
Thomas Zimmermann <tzimmermann@...e.de>,
dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH] drm: Fix build error caused by missing drm_nomodeset.o
On 11/27/21 20:26, Daniel Vetter wrote:
> On Sat, Nov 27, 2021 at 08:19:10PM +0100, Javier Martinez Canillas wrote:
>> The patch for commit ("6a2d2ddf2c34 drm: Move nomodeset kernel parameter
>> to the DRM subsystem") was generated with config 'diff.noprefix true'.
>>
>> But later was applied using 'cat nomodeset.mbox | dim apply-branch' on a
>> machine with 'diff.noprefix false'. And command 'git am --scissors -3' as
>
> Huh that's a dangerous setting, I guess a dim patch to check for this and
> very loudly complain would be good? Care to type that up? It's no big
> deal because strange git settings for dim is pretty much a game of
> whack-a-mole, but we should tackle them when they pop up.
>
Sure.
>> used by the dim tool doesn't handle that case well, since the 3-way merge
>> wrongly resolves the path for new file drivers/gpu/drm/drm_nomodeset.c as
>> gpu/drm/drm_nomodeset.c instead.
>>
>> It led to the following build error as reported by the kernel test robot:
>>
>> make[4]: *** No rule to make target 'drivers/gpu/drm/drm_nomodeset.o', needed by 'drivers/gpu/drm/built-in.a'.
>>
>> Fixes: ("6a2d2ddf2c34 drm: Move nomodeset kernel parameter to the DRM subsystem")
>> Reported-by: kernel test robot <lkp@...el.com>
>> Signed-off-by: Javier Martinez Canillas <javierm@...hat.com>
>
> Build testing before pushing should be done, not the other way round :-)
>
Yes, sorry about that. I wrongly assumed that the tools would do the correct
thing but I will make sure to build test before pushing in the future.
> Also this is pretty much why we want gitlab CI and real branches.
>
> Reviewed-by: Daniel Vetter <daniel.vetter@...ll.ch>
>> ---
Thanks!
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Powered by blists - more mailing lists