Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp955992ybh; Wed, 18 Mar 2020 12:12:26 -0700 (PDT) X-Google-Smtp-Source: ADFU+vunWRHdiZEVpzRZRL8GCveDxIivj1WSmdKRWDsz12PHxMhiH4WJTAi0vQODJxd5dPL194om X-Received: by 2002:aca:fd09:: with SMTP id b9mr4439159oii.88.1584558746647; Wed, 18 Mar 2020 12:12:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584558746; cv=none; d=google.com; s=arc-20160816; b=o6YMK0iMiI9sU7ROfamuiM5syyHbW6UwVabn0e+ryhSEI5jTFvblpG4umGTXcbY7nT I8bnf7Y2F9A7LIB8yJxVicR54TD3K9pEUmlLx/NsFGIBpsQK6DGL8Punul5t/Dy8Z/7Y 4IWaf+sn/uWbON1+Uwqfon7ySni61X8Ewea6eANjtf+Z/ThwhSEtpArqALHUkMLO0OJ+ AGfB4WRRni8SF8L+RCzTeMwGSRKiRLSo7Ej2Nz9UB3v5DJcSGE9gIh3ia9GPp2LFoll8 NZ5oISGzyImIHuzAZGF+K1YwDjTm3qFEu71I7Jgf3E08Au6eFjPIVyp2rDF7XB07DHqi EsyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=mF3uqR0dI65g7bnW0IoscUYfl1Pu8OWv3Jeasc6I3BA=; b=rgb7EUAZ8WEJtnEBVZr2tcwib/9UAIKNpIE6zM8zAORlyOPXWDVcH6htn5uc4h5bJT ICnn94u4kBKDjjA1fB/2cRCCr9ejSoBhtC1XBSCmXBKsgErUEwOTj2Z27KMER0VPUhrO RwM5M9T1FfhMNe55lBs77ecrSt+k6w+R+3pnWChVnHVzwERjggo/xdE6L4JWn/EvnR7+ WVCanfY8pYEa08BIadPaBOYoSTlMPDXo1lAPY+lQMsDnrHJftU4GfRjlzVDL8oXbTLdn r00Xr7ujrkt2dyZDuVgLbgL5nxgfB1UGauYOHijrtNBMiQzuRXakz6Sv1k5imyiteWkF XJgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=j9cqkV9W; 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 q5si4039475otn.181.2020.03.18.12.12.14; Wed, 18 Mar 2020 12:12: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=@ffwll.ch header.s=google header.b=j9cqkV9W; 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 S1726817AbgCRTK4 (ORCPT + 99 others); Wed, 18 Mar 2020 15:10:56 -0400 Received: from mail-oi1-f195.google.com ([209.85.167.195]:45756 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726623AbgCRTK4 (ORCPT ); Wed, 18 Mar 2020 15:10:56 -0400 Received: by mail-oi1-f195.google.com with SMTP id 9so8925018oiq.12 for ; Wed, 18 Mar 2020 12:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mF3uqR0dI65g7bnW0IoscUYfl1Pu8OWv3Jeasc6I3BA=; b=j9cqkV9WTwaRvdcnzXTDaIt+vzNztv/R+bD2UgJMLQtJeMU12eT/rGdhjyO/W0T/xM 1HVP7sesYmegIVG5wXh4mssL83KThrLmHOVhVNTxAqe/PN0hJokGjjKlQIDb3gZfTQU1 joonWCXOEMZStzU2POcK99QCo7KXD+wLcj/5M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mF3uqR0dI65g7bnW0IoscUYfl1Pu8OWv3Jeasc6I3BA=; b=bgllQcn1UWqrGE8z3sPSpDxs3fihtAYldnh/30kc2qZ42F49g1hOwfqQ+qYvGhMAqi CTX/B4dGgli1YogYNjidLG5Cs4KqlIIpRivrcqm90LVK2Kl8KMCUWIZp7XwkkIMwaoHk ONOGXUb78tcGiuQZtKQ2VOIl+4ZoNTl9YY7Fhi5Pcr6WAn7rYq0M+ciKcsmmNYqJjjAD 05Wt0cwoX09NOgFFBKL2JigsYd1x/gafbCYnrgQ+CTiLtC3uZwC0/lXEX9YMQ72FV5sK jnmRbU5ZQY686OE0xpTegepmvLriZz9yopY1uVyQ+Q0djJsYxSHiRNdl+8IsnbMtraqo 9ALA== X-Gm-Message-State: ANhLgQ2xmN7htLMpVP5Q6BTtz6rM3hcZXDAZWboG4/1TSw4FojDrnCEA FXf5VIlvlxjfvebSFxxAgmeixEmXdufCXu8nWb+2Rg== X-Received: by 2002:aca:be08:: with SMTP id o8mr4150691oif.101.1584558654804; Wed, 18 Mar 2020 12:10:54 -0700 (PDT) MIME-Version: 1.0 References: <20200310133121.27913-1-wambui.karugax@gmail.com> <20200310133121.27913-11-wambui.karugax@gmail.com> <20200318152627.GY2363188@phenom.ffwll.local> <20200318165846.GC3090655@kroah.com> In-Reply-To: <20200318165846.GC3090655@kroah.com> From: Daniel Vetter Date: Wed, 18 Mar 2020 20:10:43 +0100 Message-ID: Subject: Re: [PATCH v2 10/17] drm/vram-helper: make drm_vram_mm_debugfs_init() return 0 To: Greg KH Cc: Wambui Karuga , Dave Airlie , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , dri-devel , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" 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 5:58 PM Greg KH wrote: > > 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. So the trouble with this one is that the static inline functions for the debugfs file are wrapped in a #if too, and hence if we drop the #if around the function call stuff won't compile. Should we drop all the #if in the .c file and assume the compiler will remove all the dead code and dead functions? -Daniel (who has no idea how this all works really) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch