Re: [PATCH] driver core: add driver name to probe debug print
Greg Kroah-Hartman <[email protected]> Tue, 30 Jun 2026 22:40:09 +0200
| Newsgroups | org.kernel.vger.linux-embedded,dev.linux.lists.driver-core,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <2026063044-resonate-subtitle-d005@gregkh> |
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 <[email protected]> > > > Signed-off-by: Francesco Valla <[email protected]> > > > --- > > > 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