mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Maciej Purski <m.purski@samsung.com>
Cc: linux-kernel@vger.kernel.org, Russell King <rmk+kernel@armlinux.org.uk>
Subject: Re: [PATCH v2] component: add debugfs support
Date: Wed, 15 Nov 2017 15:01:31 +0100	[thread overview]
Message-ID: <20171115140131.GB21840@kroah.com> (raw)
In-Reply-To: <1510747526-24831-1-git-send-email-m.purski@samsung.com>

On Wed, Nov 15, 2017 at 01:05:26PM +0100, Maciej Purski wrote:
> Add 'component' directory to debugfs. Create a new file for each master,
> when a master is added. Remove it on a master deletion.
> 
> Show a list of devices matched with master and indicate if
> master's components were successfully added and if the whole master is
> bound.
> 
> Signed-off-by: Maciej Purski <m.purski@samsung.com>
> ---
> Changes in v2:
> - use seq_printf() instead of seq_puts() when printing headers
> - move whole debugfs code to the file beginning in order to avoid
>   forward declarations or using multiple ifdefs
> ---
>  drivers/base/component.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 83 insertions(+)
> 
> diff --git a/drivers/base/component.c b/drivers/base/component.c
> index 89b032f..8745ad9 100644
> --- a/drivers/base/component.c
> +++ b/drivers/base/component.c
> @@ -17,6 +17,7 @@
>  #include <linux/module.h>
>  #include <linux/mutex.h>
>  #include <linux/slab.h>
> +#include <linux/debugfs.h>
>  
>  struct component;
>  
> @@ -41,6 +42,7 @@ struct master {
>  	const struct component_master_ops *ops;
>  	struct device *dev;
>  	struct component_match *match;
> +	struct dentry *dentry;
>  };
>  
>  struct component {
> @@ -56,6 +58,85 @@ static DEFINE_MUTEX(component_mutex);
>  static LIST_HEAD(component_list);
>  static LIST_HEAD(masters);
>  
> +#ifdef CONFIG_DEBUG_FS
> +
> +static struct dentry *component_debugfs_dir;
> +
> +static int component_devices_show(struct seq_file *s, void *data)
> +{
> +	struct master *m = s->private;
> +	struct component_match *match = m->match;
> +	size_t i;
> +
> +	mutex_lock(&component_mutex);
> +	seq_printf(s, "%-40s %20s\n", "master name", "status");
> +	seq_puts(s, "-------------------------------------------------------------\n");
> +	seq_printf(s, "%-40s %20s\n\n",
> +		   dev_name(m->dev), m->bound ? "bound" : "not bound");
> +
> +	seq_printf(s, "%-40s %20s\n", "device name", "status");
> +	seq_puts(s, "-------------------------------------------------------------\n");
> +	for (i = 0; i < match->num; i++) {
> +		struct device *d = (struct device *)match->compare[i].data;
> +
> +		seq_printf(s, "%-40s %20s\n", dev_name(d),
> +			   match->compare[i].component ?
> +			   "registered" : "not registered");
> +	}
> +	mutex_unlock(&component_mutex);
> +
> +	return 0;
> +}
> +
> +static int component_devices_open(struct inode *inode, struct file *file)
> +{
> +	return single_open(file, component_devices_show, inode->i_private);
> +}
> +
> +static const struct file_operations component_devices_fops = {
> +	.open = component_devices_open,
> +	.read = seq_read,
> +	.llseek = seq_lseek,
> +	.release = single_release,
> +};
> +
> +static int __init component_debug_init(void)
> +{
> +	component_debugfs_dir = debugfs_create_dir("component", NULL);
> +
> +	if (!component_debugfs_dir)
> +		return -ENOMEM;

No need to test this at all, you should never fail anything if debugfs
is not working properly, just continue and move on.  The result of any
debugfs call can be fed back into any other debugfs call without any
problems.

> +
> +	return 0;
> +}
> +
> +core_initcall(component_debug_init);
> +
> +static void component_master_debugfs_add(struct master *m)
> +{
> +	m->dentry = debugfs_create_file(dev_name(m->dev), 0444,
> +					component_debugfs_dir,
> +					m, &component_devices_fops);

See, you do it well here, do the same thing when you create the initial
debugfs directory.

Also, "component" is very vague, can you think of a better term for
this?  "device_component"?  "dev_component"?  Something else?  But I
don't care, if you really like "component", that's fine.

thanks,

greg k-h

  reply	other threads:[~2017-11-15 14:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20171115120534eucas1p25315c9e71abea9b7be93d66f97406523@eucas1p2.samsung.com>
2017-11-15 12:05 ` Maciej Purski
2017-11-15 14:01   ` Greg Kroah-Hartman [this message]
2017-11-16 12:39     ` Maciej Purski

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=20171115140131.GB21840@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.purski@samsung.com \
    --cc=rmk+kernel@armlinux.org.uk \
    /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®