All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Noralf Trønnes" <noralf@tronnes.org>
Cc: dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
	thomas.petazzoni@free-electrons.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/9] drm: debugfs: Remove all files automatically on cleanup
Date: Mon, 23 Jan 2017 10:10:50 +0100	[thread overview]
Message-ID: <20170123091050.rk5xzdkn4ro2tuws@phenom.ffwll.local> (raw)
In-Reply-To: <20170122181117.8210-3-noralf@tronnes.org>

On Sun, Jan 22, 2017 at 07:11:10PM +0100, Noralf Trønnes wrote:
> Instead of having the drivers call drm_debugfs_remove_files() in
> their drm_driver->debugfs_cleanup hook, do it automatically by
> traversing minor->debugfs_list.
> Also use debugfs_remove_recursive() so drivers who add their own
> debugfs files don't have to keep track of them for removal.
> 
> Signed-off-by: Noralf Trønnes <noralf@tronnes.org>

Makes sense, but that leaves us with a pile of dead code in drivers? Can
you pls go through them and remove this all (including the debugfs_cleanup
hook), and then removing the remaining (now dead) code in the core?

Thanks, Daniel
> ---
>  drivers/gpu/drm/drm_debugfs.c | 17 +++++++++++++++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index 37fd612..0510ce2 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -218,6 +218,19 @@ int drm_debugfs_remove_files(const struct drm_info_list *files, int count,
>  }
>  EXPORT_SYMBOL(drm_debugfs_remove_files);
>  
> +static void drm_debugfs_remove_all_files(struct drm_minor *minor)
> +{
> +	struct drm_info_node *node, *tmp;
> +
> +	mutex_lock(&minor->debugfs_lock);
> +	list_for_each_entry_safe(node, tmp, &minor->debugfs_list, list) {
> +		debugfs_remove(node->dent);
> +		list_del(&node->list);
> +		kfree(node);
> +	}
> +	mutex_unlock(&minor->debugfs_lock);
> +}
> +
>  /**
>   * Cleanup the debugfs filesystem resources.
>   *
> @@ -245,9 +258,9 @@ int drm_debugfs_cleanup(struct drm_minor *minor)
>  		}
>  	}
>  
> -	drm_debugfs_remove_files(drm_debugfs_list, DRM_DEBUGFS_ENTRIES, minor);
> +	drm_debugfs_remove_all_files(minor);
>  
> -	debugfs_remove(minor->debugfs_root);
> +	debugfs_remove_recursive(minor->debugfs_root);
>  	minor->debugfs_root = NULL;
>  
>  	return 0;
> -- 
> 2.10.2
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: "Noralf Trønnes" <noralf@tronnes.org>
Cc: thomas.petazzoni@free-electrons.com, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/9] drm: debugfs: Remove all files automatically on cleanup
Date: Mon, 23 Jan 2017 10:10:50 +0100	[thread overview]
Message-ID: <20170123091050.rk5xzdkn4ro2tuws@phenom.ffwll.local> (raw)
In-Reply-To: <20170122181117.8210-3-noralf@tronnes.org>

On Sun, Jan 22, 2017 at 07:11:10PM +0100, Noralf Trønnes wrote:
> Instead of having the drivers call drm_debugfs_remove_files() in
> their drm_driver->debugfs_cleanup hook, do it automatically by
> traversing minor->debugfs_list.
> Also use debugfs_remove_recursive() so drivers who add their own
> debugfs files don't have to keep track of them for removal.
> 
> Signed-off-by: Noralf Trønnes <noralf@tronnes.org>

Makes sense, but that leaves us with a pile of dead code in drivers? Can
you pls go through them and remove this all (including the debugfs_cleanup
hook), and then removing the remaining (now dead) code in the core?

Thanks, Daniel
> ---
>  drivers/gpu/drm/drm_debugfs.c | 17 +++++++++++++++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index 37fd612..0510ce2 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -218,6 +218,19 @@ int drm_debugfs_remove_files(const struct drm_info_list *files, int count,
>  }
>  EXPORT_SYMBOL(drm_debugfs_remove_files);
>  
> +static void drm_debugfs_remove_all_files(struct drm_minor *minor)
> +{
> +	struct drm_info_node *node, *tmp;
> +
> +	mutex_lock(&minor->debugfs_lock);
> +	list_for_each_entry_safe(node, tmp, &minor->debugfs_list, list) {
> +		debugfs_remove(node->dent);
> +		list_del(&node->list);
> +		kfree(node);
> +	}
> +	mutex_unlock(&minor->debugfs_lock);
> +}
> +
>  /**
>   * Cleanup the debugfs filesystem resources.
>   *
> @@ -245,9 +258,9 @@ int drm_debugfs_cleanup(struct drm_minor *minor)
>  		}
>  	}
>  
> -	drm_debugfs_remove_files(drm_debugfs_list, DRM_DEBUGFS_ENTRIES, minor);
> +	drm_debugfs_remove_all_files(minor);
>  
> -	debugfs_remove(minor->debugfs_root);
> +	debugfs_remove_recursive(minor->debugfs_root);
>  	minor->debugfs_root = NULL;
>  
>  	return 0;
> -- 
> 2.10.2
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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

  reply	other threads:[~2017-01-23  9:11 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-22 18:11 [PATCH 0/9] drm: Add support for tiny LCD displays Noralf Trønnes
2017-01-22 18:11 ` Noralf Trønnes
2017-01-22 18:11 ` [PATCH 1/9] drm/fb-cma-helper: Add drm_fbdev_cma_set_suspend_unlocked() Noralf Trønnes
2017-01-22 18:11   ` Noralf Trønnes
2017-01-23  9:07   ` Daniel Vetter
2017-01-23  9:07     ` Daniel Vetter
2017-01-22 18:11 ` [PATCH 2/9] drm: debugfs: Remove all files automatically on cleanup Noralf Trønnes
2017-01-22 18:11   ` Noralf Trønnes
2017-01-23  9:10   ` Daniel Vetter [this message]
2017-01-23  9:10     ` Daniel Vetter
2017-01-22 18:11 ` [PATCH 3/9] drm/simple-helpers: Add missing includes Noralf Trønnes
2017-01-22 18:11   ` Noralf Trønnes
2017-01-22 18:11 ` [PATCH 4/9] drm: Add DRM support for tiny LCD displays Noralf Trønnes
2017-01-22 18:11   ` Noralf Trønnes
2017-01-23  9:28   ` Daniel Vetter
2017-01-24 16:35     ` Noralf Trønnes
2017-01-24 17:48       ` Jani Nikula
2017-01-22 18:11 ` [PATCH 5/9] drm/tinydrm: Add helper functions Noralf Trønnes
2017-01-22 18:11   ` Noralf Trønnes
2017-01-23  9:32   ` Daniel Vetter
2017-01-22 18:11 ` [PATCH 6/9] drm/tinydrm: Add MIPI DBI support Noralf Trønnes
2017-01-22 18:11   ` Noralf Trønnes
2017-01-22 18:11 ` [PATCH 7/9] of: Add vendor prefix for Multi-Inno Noralf Trønnes
2017-01-22 18:11   ` Noralf Trønnes
2017-01-23 20:33   ` Rob Herring
2017-01-23 20:33     ` Rob Herring
2017-01-22 18:11 ` [PATCH 8/9] dt-bindings: Add Multi-Inno MI0283QT binding Noralf Trønnes
2017-01-22 18:11   ` Noralf Trønnes
2017-01-23 20:43   ` Rob Herring
2017-01-23 20:43     ` Rob Herring
2017-01-22 18:11 ` [PATCH 9/9] drm/tinydrm: Add support for Multi-Inno MI0283QT display Noralf Trønnes
2017-01-22 18:11   ` Noralf Trønnes

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=20170123091050.rk5xzdkn4ro2tuws@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=noralf@tronnes.org \
    --cc=thomas.petazzoni@free-electrons.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.