Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp835574ybh; Wed, 18 Mar 2020 10:00:27 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuDxetOa3wpsge1wGdPSgnpuW6TR2kfJfS/hpCgUKuViP6Wb7Nzvfyi1wopMoEBJrsREsU2 X-Received: by 2002:a05:6830:1193:: with SMTP id u19mr4885642otq.190.1584550826988; Wed, 18 Mar 2020 10:00:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584550826; cv=none; d=google.com; s=arc-20160816; b=y8D/wuNHVz2g7flZ+5MJEzJc70vykZWIVJFl0cdQsg5tLpo9IgIgkkxedItXvbZ8Fx PDXVP5y4A1FWgzS1gXklkx7posaTJ+bCIjYoLBcVUm+eWBdbiKrGytt4zxoZBv7WePH3 eT/x3GbTnJ19j5uQLYKlHrvQtx8LHan4B0HeSMNBKP5KhgwVInl67MCCkzJ9g49S8MOv IQfFep99bgpVRv9FwXlEbtVoVEaZkBRnxFnjfK4Tqb1oQdq9Xq9Groq4MVwi5k4K3YYt IWMLrG5Y50SL8MgHuBCD0BxRiuFpvgl0ksSlQq8Q1s/gKAUrcShnHUvYT7xtwGp3T7gP t22A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=hpB+PGEDHvUDTMqUKPwdTLTeIxT5SljHglS3Q85kOP8=; b=Kp/bKGLkMTlgH4IQ+zhuzV86nhLW3U2l/2Tk/leOcsXwI7gFUSmKQESlImBgFJlail GLa3LRZHy2FH9vBXVtuskZrjZ9GopncE0gX4tXD62W4JI83fRf7Re5S+BKQ+KMthJk00 fRva6Z9xfdEkqYL+SPzXIrkeZ3mcFae+cJi9XCXNUGrfjv8aYy6TwGORkSOxMe8VF86E YLv1yeKfTmlxLBacxEbTmJgXgGWZY7GmsZ1hifEgZ4RSnaclFLF+i3QdgACldaaaE4vD sAhFbUttibEuiOcfWhaYIIXI/YCOYgo3b6k308EUpe/Gwicj7xxn1V3+fy7QWuaPVmcI R+9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=I1pTko21; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g8si3522329otg.126.2020.03.18.10.00.13; Wed, 18 Mar 2020 10:00:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=I1pTko21; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726859AbgCRQ6u (ORCPT + 99 others); Wed, 18 Mar 2020 12:58:50 -0400 Received: from mail.kernel.org ([198.145.29.99]:33448 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726680AbgCRQ6t (ORCPT ); Wed, 18 Mar 2020 12:58:49 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8E9D820724; Wed, 18 Mar 2020 16:58:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584550729; bh=50sIpwbTYylG3uOeXddKEerXCNu0A2f54RlDXQlgRCY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=I1pTko21+eEy3TFE/HCcnefGq5yIi0x+IohXiwaDCSA9CrlauuC40vheU5h3Cp7s4 uEiYvJoq0SGZTxXd5QNgGt1s4k3kXwiqkYH1zYdJr3NIKqfEWmFrbvXcK/Fswxr/IK eUKAnxYn6eMILCn40d4TT2DXztIL4wjfjAdEaSCo= Date: Wed, 18 Mar 2020 17:58:46 +0100 From: Greg KH To: Daniel Vetter Cc: Wambui Karuga , Dave Airlie , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , dri-devel , Linux Kernel Mailing List Subject: Re: [PATCH v2 10/17] drm/vram-helper: make drm_vram_mm_debugfs_init() return 0 Message-ID: <20200318165846.GC3090655@kroah.com> References: <20200310133121.27913-1-wambui.karugax@gmail.com> <20200310133121.27913-11-wambui.karugax@gmail.com> <20200318152627.GY2363188@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 18, 2020 at 05:31:47PM +0100, Daniel Vetter wrote: > On Wed, Mar 18, 2020 at 5:03 PM Wambui Karuga wrote: > > > > > > > > On Wed, 18 Mar 2020, Daniel Vetter wrote: > > > > > On Tue, Mar 10, 2020 at 04:31:14PM +0300, Wambui Karuga wrote: > > >> Since 987d65d01356 (drm: debugfs: make > > >> drm_debugfs_create_files() never fail), drm_debugfs_create_files() never > > >> fails and should return void. Therefore, remove its use as the > > >> return value of drm_vram_mm_debugfs_init(), and have the function > > >> return 0 directly. > > >> > > >> v2: have drm_vram_mm_debugfs_init() return 0 instead of void to avoid > > >> introducing build issues and build breakage. > > >> > > >> References: https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html > > >> Signed-off-by: Wambui Karuga > > >> Acked-by: Thomas Zimmermann > > >> --- > > >> drivers/gpu/drm/drm_gem_vram_helper.c | 10 ++++------ > > >> 1 file changed, 4 insertions(+), 6 deletions(-) > > >> > > >> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c > > >> index 92a11bb42365..c8bcc8609650 100644 > > >> --- a/drivers/gpu/drm/drm_gem_vram_helper.c > > >> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c > > >> @@ -1048,14 +1048,12 @@ static const struct drm_info_list drm_vram_mm_debugfs_list[] = { > > >> */ > > >> int drm_vram_mm_debugfs_init(struct drm_minor *minor) > > >> { > > >> - int ret = 0; > > >> - > > >> #if defined(CONFIG_DEBUG_FS) > > > > > > Just noticed that this #if here is not needed, we already have a dummy > > > function for that case. Care to write a quick patch to remove it? On top > > > of this patch series here ofc, I'm in the processing of merging the entire > > > pile. > > > > > > Thanks, Daniel > > Hi Daniel, > > Without this check here, and compiling without CONFIG_DEBUG_FS, this > > function is run and the drm_debugfs_create_files() does not have access to > > the parameters also protected by an #if above this function. So the change > > throws an error for me. Is that correct? > > Hm right. Other drivers don't #ifdef out their debugfs file functions > ... kinda a bit disappointing that we can't do this in the neatest way > possible. > > Greg, has anyone ever suggested to convert the debugfs_create_file > function (and similar things) to macros that don't use any of the > arguments, and then also annotating all the static functions/tables as > __maybe_unused and let the compiler garbage collect everything? > Instead of explicit #ifdef in all the drivers ... No, no one has suggested that, having the functions be static inline should make it all "just work" properly if debugfs is not enabled. The variables will not be used, so the compiler should just optimize them away properly. No checks for CONFIG_DEBUG_FS should be needed anywhere in .c code. thanks, greg k-h