From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8304EC00449 for ; Fri, 5 Oct 2018 10:22:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4E0DB2084D for ; Fri, 5 Oct 2018 10:22:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4E0DB2084D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=tronnes.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728257AbeJERUt (ORCPT ); Fri, 5 Oct 2018 13:20:49 -0400 Received: from smtp.domeneshop.no ([194.63.252.55]:48739 "EHLO smtp.domeneshop.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727535AbeJERUt (ORCPT ); Fri, 5 Oct 2018 13:20:49 -0400 Received: from 211.81-166-168.customer.lyse.net ([81.166.168.211]:61192 helo=[192.168.10.175]) by smtp.domeneshop.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1g8NFl-0004Ol-Qi; Fri, 05 Oct 2018 12:22:37 +0200 Subject: Re: [PATCH] drm/imx: move 'legacyfb_depth' definition out of #ifdef To: Arnd Bergmann , Philipp Zabel , David Airlie , Lucas Stach , Sam Ravnborg , Souptick Joarder , Leonard Crestez , tzimmermann@suse.de, dri-devel , Linux Kernel Mailing List References: <20181002205836.2323084-1-arnd@arndb.de> <123f7e1c-8f2b-5797-de16-650ec01d0b24@tronnes.org> <20181003161326.GD31561@phenom.ffwll.local> <20181004193543.GQ31561@phenom.ffwll.local> From: =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= Message-ID: <6b77a97b-59d6-a881-b7ab-baf14c4dc482@tronnes.org> Date: Fri, 5 Oct 2018 12:22:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181004193543.GQ31561@phenom.ffwll.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Den 04.10.2018 21.35, skrev Daniel Vetter: > 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 wrote: >>> Den 04.10.2018 09.48, skrev Daniel Vetter: >>>> On Wed, Oct 3, 2018 at 9:51 PM Arnd Bergmann wrote: >>>>> On Wed, Oct 3, 2018 at 6:13 PM Daniel Vetter 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 >>>>>>>> --- >>>>>>> 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 >>> >>> CONFIG_DRM_FBDEV_EMULATION=n >>> >>> git cherry-pick 064b06bbf117f8b5e64a5143e970d5a1cf602fd6 >>> >>> 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. The patch is now in drm-misc-next-fixes. Thanks for helping me fix this fallout. Noralf.