linux-embedded.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Francesco Valla <francesco@valla.it>
To: Linux Embedded <linux-embedded@vger.kernel.org>,
	"Bird, Tim" <Tim.Bird@sony.com>
Subject: Re: [RFC PATCH] boot-time: instrument probes more
Date: Sat, 21 Dec 2024 15:47:54 +0100	[thread overview]
Message-ID: <26696081.1r3eYUQgxm@fedora> (raw)
In-Reply-To: <MW5PR13MB563277AF5972FD2B56026CF9FD3C2@MW5PR13MB5632.namprd13.prod.outlook.com>

Hello,

On Monday, 9 December 2024 at 04:10:04 Bird, Tim <Tim.Bird@sony.com> wrote:
> ----
> Below is the patch that adds the extra instrumentation.  My quick question is, does this look useful?
> Can it be used to find the more problematic (ie long-duration) probe functions or drivers initializations?
> 

Yes, it looks useful to me. While an experienced developer _might_ be able to match
device names and drivers at a quick glance, that's not the case for everyone, in
particular on certain SoCs which are modelled at devicetree level with an exceptionally
high number of "generic" device nodes.

> ----
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 0c3725c3eefa..5e19079b0a2b 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -28,6 +28,7 @@
>  #include <linux/pm_runtime.h>
>  #include <linux/pinctrl/devinfo.h>
>  #include <linux/slab.h>
> +#include <linux/kallsyms.h>
>  
>  #include "base.h"
>  #include "power/power.h"
> @@ -732,8 +733,16 @@ static int really_probe(struct device *dev, struct device_driver *drv)
>  static int really_probe_debug(struct device *dev, struct device_driver *drv)
>  {
>  	ktime_t calltime, rettime;
> +	char fn_name[KSYM_SYMBOL_LEN];
> +	unsigned long addr = 0;
>  	int ret;
>  
> +	if (dev->bus->probe)
> +		addr = (unsigned long)dev->bus->probe;
> +	else if (drv->probe)
> +		addr = (unsigned long)drv->probe;
> +	sprint_symbol_no_offset(fn_name, addr);
> +
>  	calltime = ktime_get();
>  	ret = really_probe(dev, drv);
>  	rettime = ktime_get();
> @@ -742,8 +751,8 @@ static int really_probe_debug(struct device *dev, struct device_driver *drv)
>  	 * CONFIG_DYNAMIC_DEBUG and we want a simple 'initcall_debug' on the
>  	 * kernel commandline to print this all the time at the debug level.
>  	 */
> -	printk(KERN_DEBUG "probe of %s returned %d after %lld usecs\n",
> -		 dev_name(dev), ret, ktime_us_delta(rettime, calltime));
> +	printk(KERN_DEBUG "probe %s in driver %s for device %s returned %d after %lld usecs\n",
> +		 fn_name, drv->name, dev_name(dev), ret, ktime_us_delta(rettime, calltime));
>  	return ret;
>  }
>  
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 76bfcba25003..ae15969c483a 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -32,6 +32,7 @@
>  #include <linux/types.h>
>  #include <linux/iommu.h>
>  #include <linux/dma-map-ops.h>
> +#include <linux/kallsyms.h>
>  
>  #include "base.h"
>  #include "power/power.h"
> @@ -1381,6 +1382,9 @@ static int platform_probe(struct device *_dev)
>  	struct platform_driver *drv = to_platform_driver(_dev->driver);
>  	struct platform_device *dev = to_platform_device(_dev);
>  	int ret;
> +	char fn_name[KSYM_SYMBOL_LEN];
> +	unsigned long addr = 0;
> +
>  
>  	/*
>  	 * A driver registered using platform_driver_probe() cannot be bound
> @@ -1401,6 +1405,13 @@ static int platform_probe(struct device *_dev)
>  		goto out;
>  
>  	if (drv->probe) {
> +		if (initcall_debug) {
> +			addr = (unsigned long)drv->probe;
> +			sprint_symbol_no_offset(fn_name, addr);
> +
> +			printk(KERN_DEBUG "platform probe %s is being called\n", fn_name);
> +		}
> +
>  		ret = drv->probe(dev);
>  		if (ret)
>  			dev_pm_domain_detach(_dev, true);

Does this really belong here? Why not add a print inside really_probe_debug(), just
before the call to really_probe()? That approach would catch all probe types (not just
platform_probe) while containing the initcall_debug instrumentation inside dd.c

Regards,
Francesco




  reply	other threads:[~2024-12-21 14:48 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-27 23:35 [boot-time] [RFC] analyze-initcall-debug.py - a tool to analyze the initcall debug output Francesco Valla
2024-12-03 20:33 ` Bird, Tim
2024-12-05 12:57   ` Francesco Valla
2024-12-05 14:58     ` Geert Uytterhoeven
2024-12-05 21:36       ` Francesco Valla
2024-12-09  3:10     ` [RFC PATCH] boot-time: instrument probes more Bird, Tim
2024-12-21 14:47       ` Francesco Valla [this message]
2024-12-29 17:45         ` Francesco Valla
2024-12-03 21:24 ` [boot-time] jent_mod_init on beagleplay (was RE: [boot-time] [RFC] analyze-initcall-debug.py - a tool to analyze the initcall debug output Bird, Tim
2024-12-05  7:02   ` Stephan Mueller
     [not found]     ` <CAORPcfUfgNnQb6m0baW9qEGnrGYsnbpvwUUmF5Y9Byh9_iMAZw@mail.gmail.com>
2024-12-30 22:35       ` Francesco Valla
2024-12-31  9:55         ` Stephan Müller
2024-12-31 14:42           ` Francesco Valla
2025-01-02  9:06             ` Stephan Mueller
2025-01-02 10:33               ` Francesco Valla
2025-01-02 12:56                 ` Stephan Mueller
2025-01-03 17:23                   ` Francesco Valla
2025-01-04 15:45                     ` Stephan Müller
2025-01-07 22:40                   ` Bird, Tim
2025-01-07 21:42         ` boot markers ideas (was RE: [boot-time] jent_mod_init on beagleplay) Bird, Tim
2025-01-07 23:40           ` Rob Landley
2025-01-09 16:23             ` Francesco Valla
2024-12-30 22:22   ` [boot-time] jent_mod_init on beagleplay (was RE: [boot-time] [RFC] analyze-initcall-debug.py - a tool to analyze the initcall debug output Francesco Valla
2025-01-07 21:27     ` Bird, Tim
2024-12-04  0:29 ` Bird, Tim
2024-12-05 13:05   ` Francesco Valla

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=26696081.1r3eYUQgxm@fedora \
    --to=francesco@valla.it \
    --cc=Tim.Bird@sony.com \
    --cc=linux-embedded@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).