From: Thomas Zimmermann <tzimmermann@suse.de>
To: Wambui Karuga <wambui.karugax@gmail.com>,
Daniel Vetter <daniel@ffwll.ch>,
Greg KH <gregkh@linuxfoundation.org>,
Dave Airlie <airlied@linux.ie>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v2 10/17] drm/vram-helper: make drm_vram_mm_debugfs_init() return 0
Date: Tue, 7 Apr 2020 08:36:47 +0200 [thread overview]
Message-ID: <cfbf0a0c-8fe1-ff41-d8cb-8f96a3912a36@suse.de> (raw)
In-Reply-To: <alpine.LNX.2.21.99999.375.2003191522020.89327@wambui>
[-- Attachment #1.1: Type: text/plain, Size: 4976 bytes --]
Hi
Am 19.03.20 um 13:27 schrieb Wambui Karuga:
>
>
> On Thu, 19 Mar 2020, Daniel Vetter wrote:
>
>> On Thu, Mar 19, 2020 at 08:55:24AM +0100, Greg KH wrote:
>>> On Wed, Mar 18, 2020 at 08:10:43PM +0100, Daniel Vetter wrote:
>>>> On Wed, Mar 18, 2020 at 5:58 PM Greg KH <gregkh@linuxfoundation.org>
>>>> 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
>>>>>> <wambui.karugax@gmail.com> 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 <wambui.karugax@gmail.com>
>>>>>>>>> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
>>>>>>>>> ---
>>>>>>>>> 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?
>>>
>>> Yes you should :)
>>>
>>> there should not be any need for #if in a .c file for debugfs stuff.
>>
>> Wambui, can you pls try that out? I.e. removing all the #if for
>> CONFIG_DEBUG_FS from that file.
>
> Removing them works with CONFIG_DEBUG_FS enabled or disabled.
> I can send a patch for that.
Please do. Removing explicit checks for CONFIG_ is usually a good thing.
Best regards
Thomas
>
> wambui karuga
>> -Daniel
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
>>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-04-07 6:36 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-10 13:31 [PATCH v2 00/17] drm: subsytem-wide debugfs functions refactor Wambui Karuga
2020-03-10 13:31 ` [PATCH v2 01/17] drm/tegra: remove checks for debugfs functions return value Wambui Karuga
2020-03-10 13:31 ` [PATCH v2 02/17] drm/tilcdc: remove check for return value of debugfs functions Wambui Karuga
2020-03-10 13:31 ` [PATCH v2 03/17] drm/v3d: make v3d_debugfs_init() return 0 Wambui Karuga
2020-03-10 13:31 ` [PATCH v2 04/17] drm/vc4: remove check of return value of drm_debugfs functions Wambui Karuga
2020-03-10 13:31 ` [PATCH v2 05/17] drm/arc: make arcgpu_debugfs_init() return 0 Wambui Karuga
2020-03-12 7:55 ` Alexey Brodkin
2020-03-10 13:31 ` [PATCH v2 06/17] drm/arm: make hdlcd_debugfs_init() " Wambui Karuga
2020-03-10 15:43 ` Liviu Dudau
2020-03-10 13:31 ` [PATCH v2 07/17] drm/etnaviv: remove check for return value of drm_debugfs_create_files() Wambui Karuga
2020-03-11 16:44 ` Lucas Stach
2020-03-10 13:31 ` [PATCH v2 08/17] drm/msm: remove checks " Wambui Karuga
2020-03-10 13:31 ` [PATCH v2 09/17] drm/sti: remove use of drm_debugfs functions as return values Wambui Karuga
2020-03-10 13:31 ` [PATCH v2 10/17] drm/vram-helper: make drm_vram_mm_debugfs_init() return 0 Wambui Karuga
2020-03-18 15:26 ` Daniel Vetter
2020-03-18 16:02 ` Wambui Karuga
2020-03-18 16:31 ` Daniel Vetter
2020-03-18 16:58 ` Greg KH
2020-03-18 19:10 ` Daniel Vetter
2020-03-19 7:55 ` Greg KH
2020-03-19 10:18 ` Daniel Vetter
2020-03-19 12:27 ` Wambui Karuga
2020-04-07 6:36 ` Thomas Zimmermann [this message]
2020-03-10 13:31 ` [PATCH v2 11/17] drm/nouveau: make nouveau_drm_debugfs_init() " Wambui Karuga
2020-03-10 13:31 ` [PATCH v2 12/17] drm/pl111: make pl111_debugfs_init " Wambui Karuga
2020-03-10 13:31 ` [PATCH v2 13/17] drm/omap: remove checks for return value of drm_debugfs functions Wambui Karuga
2020-03-10 13:31 ` [PATCH v2 14/17] drm/i915: have *_debugfs_init() functions return void Wambui Karuga
2020-03-11 8:15 ` Jani Nikula
2020-03-10 13:31 ` [PATCH v2 15/17] drm: make various debugfs_init() functions return 0 Wambui Karuga
2020-03-10 13:31 ` [PATCH v2 16/17] drm/debugfs: remove checks for return value of drm_debugfs functions Wambui Karuga
2020-03-10 13:31 ` [PATCH v2 17/17] drm: convert .debugfs_init() hook to return void Wambui Karuga
2020-03-10 14:33 ` [PATCH v2 00/17] drm: subsytem-wide debugfs functions refactor Greg KH
2020-03-18 16:54 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cfbf0a0c-8fe1-ff41-d8cb-8f96a3912a36@suse.de \
--to=tzimmermann@suse.de \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=wambui.karugax@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®