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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

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