Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751228AbdGZG6S (ORCPT ); Wed, 26 Jul 2017 02:58:18 -0400 Received: from mail-oi0-f66.google.com ([209.85.218.66]:36718 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751031AbdGZG6R (ORCPT ); Wed, 26 Jul 2017 02:58:17 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170725180555.3699056-1-arnd@arndb.de> From: Arnd Bergmann Date: Wed, 26 Jul 2017 08:58:16 +0200 X-Google-Sender-Auth: VTAK1Jqq-pZkYEPU0fwOwza4niU Message-ID: Subject: Re: [PATCH v2] drm/hisilicon: fix build error without fbdev emulation To: Daniel Vetter Cc: Xinliang Liu , Rongrong Zou , Xinwei Kong , Chen Feng , David Airlie , Sean Paul , Russell King , Gabriel Krisman Bertazi , Jani Nikula , Thierry Reding , Rob Herring , Shawn Guo , dri-devel , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1569 Lines: 33 On Wed, Jul 26, 2017 at 7:55 AM, Daniel Vetter wrote: > On Tue, Jul 25, 2017 at 8:05 PM, Arnd Bergmann wrote: >> We cannot reference priv->fbdev outside of the #ifdef: >> >> drivers/net/virtio_net.c:1881:12: error: 'virtnet_restore_up' defined but not used [-Werror=unused-function] >> static int virtnet_restore_up(struct virtio_device *vdev) >> drivers/net/virtio_net.c:1859:13: error: 'virtnet_freeze_down' defined but not used [-Werror=unused-function] >> static void virtnet_freeze_down(struct virtio_device *vdev) >> >> As the #ifdef is a bit annoying here, this removes it entirely >> and uses an IS_ENABLED() check in it place where needed. >> >> Fixes: b4dd9f1ffaba ("drm/hisilicon: Remove custom FB helper deferred setup") >> Signed-off-by: Arnd Bergmann > > I guess I wasn't clear enough, but you don't even need the IS_ENABLED. > The cma_fini/init functions themselves don't get no-opped out (I guess > we could fix that), but the underlying fb helper functions they call > do, so this is all perfectly fine to call unconditionally. And that's > what all other drivers do. Should I edit while applying, or do you > want to respin? Please just edit as you like then, I think that's quicker. The version I sent was meant to have smaller object code as well, and I didn't think we could rely on drm_fb_cma_helper.c being built without CONFIG_DRM_FBDEV_EMULATION, but I see now that they are independent as you say, so making them unconditional indeed gives the simplest code. Thanks! Arnd