[PATCH] driver core: add driver name to probe debug print

[PATCH] driver core: add driver name to probe debug print

[Francesco Valla]

The initcall_debug command line option is a useful tool while debugging
and optimizing the initialization of a new system, mainly because it
allows to see probe failures and deferrals without recompiling the
kernel (e.g., with CONFIG_DEBUG_DRIVER). However, matching a device
with the driver it is being probed with can become difficult, since
some devices use names that are not explicit, at least at a first sight
(e.g.: '1-0:1.0' or '1-0060').

Add an additional debug print to inform the user which driver is being
used for a device, allowing for a quick match. The print is inserted in
the same really_probe_debug() wrapper that is already used to report
the result of the probe, and is thus not affecting executions not using
the initcall_debug option.

Suggested-by: Tim Bird <tim.bird@sony.com>
Signed-off-by: Francesco Valla <francesco@valla.it>
---
Hello,

this very small patch comes from a discussion started at the end of
2024 after a Boot Time SIG meeting [1]; I decided to reduce the patch
proposed there by Tim to the bare minimum, as this should already be
enough information for a developer to work with.

I was unsure on whether to add information to the existing print or
introduce a new one; while IMO technically worse, I opted for this
second solution, since the existing print *might* be viewed as
userspace-facing ABI. I'll be happy to do otherwise if there is
consensus.

Thank you!

Regards,
Francesco

[1] https://lore.kernel.org/linux-embedded/MW5PR13MB563277AF5972FD2B56026CF9FD3C2@MW5PR13MB5632.namprd13.prod.outlook.com/
---
 drivers/base/dd.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 60c005223844..3c0930020050 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -782,6 +782,9 @@ static int really_probe_debug(struct device *dev, const struct device_driver *dr
 	ktime_t calltime, rettime;
 	int ret;
 
+	/* Don't change this to pr_debug() - see comment below. */
+	printk(KERN_DEBUG "probing %s with driver %s\n", dev_name(dev), drv->name);
+
 	calltime = ktime_get();
 	ret = really_probe(dev, drv);
 	rettime = ktime_get();

---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260628-probe_driver-3f14e94573f6

Best regards,
--  
Francesco Valla <francesco@valla.it>

Re: [PATCH] driver core: add driver name to probe debug print

[Greg Kroah-Hartman]

On Mon, Jun 29, 2026 at 11:51:18PM +0200, Francesco Valla wrote:
> The initcall_debug command line option is a useful tool while debugging
> and optimizing the initialization of a new system, mainly because it
> allows to see probe failures and deferrals without recompiling the
> kernel (e.g., with CONFIG_DEBUG_DRIVER). However, matching a device
> with the driver it is being probed with can become difficult, since
> some devices use names that are not explicit, at least at a first sight
> (e.g.: '1-0:1.0' or '1-0060').
> 
> Add an additional debug print to inform the user which driver is being
> used for a device, allowing for a quick match. The print is inserted in
> the same really_probe_debug() wrapper that is already used to report
> the result of the probe, and is thus not affecting executions not using
> the initcall_debug option.
> 
> Suggested-by: Tim Bird <tim.bird@sony.com>
> Signed-off-by: Francesco Valla <francesco@valla.it>
> ---
> Hello,
> 
> this very small patch comes from a discussion started at the end of
> 2024 after a Boot Time SIG meeting [1]; I decided to reduce the patch
> proposed there by Tim to the bare minimum, as this should already be
> enough information for a developer to work with.
> 
> I was unsure on whether to add information to the existing print or
> introduce a new one; while IMO technically worse, I opted for this
> second solution, since the existing print *might* be viewed as
> userspace-facing ABI. I'll be happy to do otherwise if there is
> consensus.
> 
> Thank you!
> 
> Regards,
> Francesco
> 
> [1] https://lore.kernel.org/linux-embedded/MW5PR13MB563277AF5972FD2B56026CF9FD3C2@MW5PR13MB5632.namprd13.prod.outlook.com/
> ---
>  drivers/base/dd.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 60c005223844..3c0930020050 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -782,6 +782,9 @@ static int really_probe_debug(struct device *dev, const struct device_driver *dr
>  	ktime_t calltime, rettime;
>  	int ret;
>  
> +	/* Don't change this to pr_debug() - see comment below. */
> +	printk(KERN_DEBUG "probing %s with driver %s\n", dev_name(dev), drv->name);

So you now get 2 lines per driver probe attempt?

What exactly is this going to help out with?  You aleady get the probe
result line, how is doing 2 going to change anything except explode your
kernel log?  Why not just modify the one existing line instead?

And the comment "see below" should mean that you move the comment up
here so that it doesn't need to be repeated.

thanks,

greg k-h

Re: [PATCH] driver core: add driver name to probe debug print

[Francesco Valla]

Hello Greg,

thank you for the quick feedback.

On Tue, Jun 30, 2026 at 12:21:39PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Jun 29, 2026 at 11:51:18PM +0200, Francesco Valla wrote:
> > The initcall_debug command line option is a useful tool while debugging
> > and optimizing the initialization of a new system, mainly because it
> > allows to see probe failures and deferrals without recompiling the
> > kernel (e.g., with CONFIG_DEBUG_DRIVER). However, matching a device
> > with the driver it is being probed with can become difficult, since
> > some devices use names that are not explicit, at least at a first sight
> > (e.g.: '1-0:1.0' or '1-0060').
> > 
> > Add an additional debug print to inform the user which driver is being
> > used for a device, allowing for a quick match. The print is inserted in
> > the same really_probe_debug() wrapper that is already used to report
> > the result of the probe, and is thus not affecting executions not using
> > the initcall_debug option.
> > 
> > Suggested-by: Tim Bird <tim.bird@sony.com>
> > Signed-off-by: Francesco Valla <francesco@valla.it>
> > ---
> > Hello,
> > 
> > this very small patch comes from a discussion started at the end of
> > 2024 after a Boot Time SIG meeting [1]; I decided to reduce the patch
> > proposed there by Tim to the bare minimum, as this should already be
> > enough information for a developer to work with.
> > 
> > I was unsure on whether to add information to the existing print or
> > introduce a new one; while IMO technically worse, I opted for this
> > second solution, since the existing print *might* be viewed as
> > userspace-facing ABI. I'll be happy to do otherwise if there is
> > consensus.
> > 
> > Thank you!
> > 
> > Regards,
> > Francesco
> > 
> > [1] https://lore.kernel.org/linux-embedded/MW5PR13MB563277AF5972FD2B56026CF9FD3C2@MW5PR13MB5632.namprd13.prod.outlook.com/
> > ---
> >  drivers/base/dd.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> > index 60c005223844..3c0930020050 100644
> > --- a/drivers/base/dd.c
> > +++ b/drivers/base/dd.c
> > @@ -782,6 +782,9 @@ static int really_probe_debug(struct device *dev, const struct device_driver *dr
> >  	ktime_t calltime, rettime;
> >  	int ret;
> >  
> > +	/* Don't change this to pr_debug() - see comment below. */
> > +	printk(KERN_DEBUG "probing %s with driver %s\n", dev_name(dev), drv->name);
> 
> So you now get 2 lines per driver probe attempt?
> 
> What exactly is this going to help out with?  You aleady get the probe
> result line, how is doing 2 going to change anything except explode your
> kernel log?  Why not just modify the one existing line instead?
> 

I was being overzealous with the "don't break the userspace ABI" rule
and included the existing print into this kind of ABI. Given your
response, though, this might not be the case. I'll wait a couple of days
to see if anyone has something to add and then send a V2 that adds the
driver name to the existent print (solution that I technically prefer).

> And the comment "see below" should mean that you move the comment up
> here so that it doesn't need to be repeated.
> 
> thanks,
> 
> greg k-h

Regards,
Francesco

Re: [PATCH] driver core: add driver name to probe debug print

[Greg Kroah-Hartman]

On Tue, Jun 30, 2026 at 06:00:17PM +0200, Francesco Valla wrote:
> Hello Greg,
> 
> thank you for the quick feedback.
> 
> On Tue, Jun 30, 2026 at 12:21:39PM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Jun 29, 2026 at 11:51:18PM +0200, Francesco Valla wrote:
> > > The initcall_debug command line option is a useful tool while debugging
> > > and optimizing the initialization of a new system, mainly because it
> > > allows to see probe failures and deferrals without recompiling the
> > > kernel (e.g., with CONFIG_DEBUG_DRIVER). However, matching a device
> > > with the driver it is being probed with can become difficult, since
> > > some devices use names that are not explicit, at least at a first sight
> > > (e.g.: '1-0:1.0' or '1-0060').
> > > 
> > > Add an additional debug print to inform the user which driver is being
> > > used for a device, allowing for a quick match. The print is inserted in
> > > the same really_probe_debug() wrapper that is already used to report
> > > the result of the probe, and is thus not affecting executions not using
> > > the initcall_debug option.
> > > 
> > > Suggested-by: Tim Bird <tim.bird@sony.com>
> > > Signed-off-by: Francesco Valla <francesco@valla.it>
> > > ---
> > > Hello,
> > > 
> > > this very small patch comes from a discussion started at the end of
> > > 2024 after a Boot Time SIG meeting [1]; I decided to reduce the patch
> > > proposed there by Tim to the bare minimum, as this should already be
> > > enough information for a developer to work with.
> > > 
> > > I was unsure on whether to add information to the existing print or
> > > introduce a new one; while IMO technically worse, I opted for this
> > > second solution, since the existing print *might* be viewed as
> > > userspace-facing ABI. I'll be happy to do otherwise if there is
> > > consensus.
> > > 
> > > Thank you!
> > > 
> > > Regards,
> > > Francesco
> > > 
> > > [1] https://lore.kernel.org/linux-embedded/MW5PR13MB563277AF5972FD2B56026CF9FD3C2@MW5PR13MB5632.namprd13.prod.outlook.com/
> > > ---
> > >  drivers/base/dd.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> > > index 60c005223844..3c0930020050 100644
> > > --- a/drivers/base/dd.c
> > > +++ b/drivers/base/dd.c
> > > @@ -782,6 +782,9 @@ static int really_probe_debug(struct device *dev, const struct device_driver *dr
> > >  	ktime_t calltime, rettime;
> > >  	int ret;
> > >  
> > > +	/* Don't change this to pr_debug() - see comment below. */
> > > +	printk(KERN_DEBUG "probing %s with driver %s\n", dev_name(dev), drv->name);
> > 
> > So you now get 2 lines per driver probe attempt?
> > 
> > What exactly is this going to help out with?  You aleady get the probe
> > result line, how is doing 2 going to change anything except explode your
> > kernel log?  Why not just modify the one existing line instead?
> > 
> 
> I was being overzealous with the "don't break the userspace ABI" rule
> and included the existing print into this kind of ABI. Given your
> response, though, this might not be the case. I'll wait a couple of days
> to see if anyone has something to add and then send a V2 that adds the
> driver name to the existent print (solution that I technically prefer).

printk() messages are NOT a userspace ABI so all should be fine.
Especially for debugging messages :)

thanks,

greg k-h

RE: [PATCH] driver core: add driver name to probe debug print

[Bird, Tim]

> -----Original Message-----
> From: Francesco Valla <francesco@valla.it>
> Hello Greg,
> 
> thank you for the quick feedback.
> 
> On Tue, Jun 30, 2026 at 12:21:39PM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Jun 29, 2026 at 11:51:18PM +0200, Francesco Valla wrote:
> > > The initcall_debug command line option is a useful tool while debugging
> > > and optimizing the initialization of a new system, mainly because it
> > > allows to see probe failures and deferrals without recompiling the
> > > kernel (e.g., with CONFIG_DEBUG_DRIVER). However, matching a device
> > > with the driver it is being probed with can become difficult, since
> > > some devices use names that are not explicit, at least at a first sight
> > > (e.g.: '1-0:1.0' or '1-0060').
> > >
> > > Add an additional debug print to inform the user which driver is being
> > > used for a device, allowing for a quick match. The print is inserted in
> > > the same really_probe_debug() wrapper that is already used to report
> > > the result of the probe, and is thus not affecting executions not using
> > > the initcall_debug option.
> > >
> > > Suggested-by: Tim Bird <tim.bird@sony.com>
> > > Signed-off-by: Francesco Valla <francesco@valla.it>
> > > ---
> > > Hello,
> > >
> > > this very small patch comes from a discussion started at the end of
> > > 2024 after a Boot Time SIG meeting [1]; I decided to reduce the patch
> > > proposed there by Tim to the bare minimum, as this should already be
> > > enough information for a developer to work with.
> > >
> > > I was unsure on whether to add information to the existing print or
> > > introduce a new one; while IMO technically worse, I opted for this
> > > second solution, since the existing print *might* be viewed as
> > > userspace-facing ABI. I'll be happy to do otherwise if there is
> > > consensus.
> > >
> > > Thank you!
> > >
> > > Regards,
> > > Francesco
> > >
> > > [1] https://lore.kernel.org/linux-
> embedded/MW5PR13MB563277AF5972FD2B56026CF9FD3C2@MW5PR13MB5632.namprd13.prod.outlook.com/
> > > ---
> > >  drivers/base/dd.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> > > index 60c005223844..3c0930020050 100644
> > > --- a/drivers/base/dd.c
> > > +++ b/drivers/base/dd.c
> > > @@ -782,6 +782,9 @@ static int really_probe_debug(struct device *dev, const struct device_driver *dr
> > >  	ktime_t calltime, rettime;
> > >  	int ret;
> > >
> > > +	/* Don't change this to pr_debug() - see comment below. */
> > > +	printk(KERN_DEBUG "probing %s with driver %s\n", dev_name(dev), drv->name);
> >
> > So you now get 2 lines per driver probe attempt?
> >
> > What exactly is this going to help out with?  You aleady get the probe
> > result line, how is doing 2 going to change anything except explode your
> > kernel log?  Why not just modify the one existing line instead?
> >
> 
> I was being overzealous with the "don't break the userspace ABI" rule
> and included the existing print into this kind of ABI. Given your
> response, though, this might not be the case. I'll wait a couple of days
> to see if anyone has something to add and then send a V2 that adds the
> driver name to the existent print (solution that I technically prefer).

I examined scripts/bootgraph.pl, bootchart, tools/power/pm-graph/bootgraph.py
systemd-analyze and some others that parse dmesg lines produced by the initcall_debug
option (including my own tools).

The only tool I found that parses the probe debug lines is analyze-initcall-debug.py
 - which is your program, and we discussed that you planned to modify that tool to 
accept both old and new string formats for this line.

This is all to say that I'm not aware of anything that will break if you change the
format of the existing probe debug line.  So my vote would be to add the driver
name to the existing printk line.  Of course, it would be great if you can do so conservatively
(that is, keeping most of the string elements intact and in the same order, so that existing parsers
that we might not be aware of don't break).

I'll be glad to see this extra data available.
 -- Tim