From: javierm@redhat.com (Javier Martinez Canillas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] driver core: add a debugfs entry to show deferred devices
Date: Wed, 20 Jun 2018 10:46:35 +0200 [thread overview]
Message-ID: <ea628ded-3cb3-c426-da6d-bf7cb51f4ca8@redhat.com> (raw)
In-Reply-To: <20180619225145.GA23389@kroah.com>
On 06/20/2018 12:51 AM, Greg Kroah-Hartman wrote:
[snip]
>> @@ -233,6 +252,9 @@ void device_unblock_probing(void)
>> */
>> static int deferred_probe_initcall(void)
>> {
>> + debugfs_create_file("deferred_devices", 0444, NULL, NULL,
>> + &deferred_devs_fops);
>
> In the root of debugfs?
>
I added in the root for lack of a better place. Any suggestion is welcomed.
> Anyway, what about "devices_deferred", to help keep things semi-sane if
> we have other driver core debugfs entries?
>
I don't have a strong opinion on the name really, so I'll change it.
> And you don't remove the file ever?
>
Yeah, I saw that it wasn't removed in other places for debugfs entries
created by the core since unlike drivers they can't be built as a module
or re-loaded. But you are right, I'll add an __exitcall to remove there.
> And what is the use of this file? What can you do with this
> information? Who is going to use it? Don't we have other deferred
This patch is the result of a discussion with Tomeu and Mark (cc'ed) to
allow https://kernelci.org to test if there was a regression that makes
drivers to defer their probe.
The problem with the probe deferral mechanism is that you don't have a
way to distinguish between a valid deferral due a dependency not being
available yet and a bug (i.e: wrong DTB, config symbol not enabled, etc)
that prevents the device to eventually being probed.
> probe debugging somewhere else?
>
There is some debug yes, but it isn't suitable for the use case I explained.
For start, it only tells you if a given driver for a device was deferred or
probed correctly while this patch attempts to tell what was left (if any)
in the queue after the last driver was registered.
Second, is only enabled until late_initcall so it will only print the probe
deferral for built-in drivers and not for modules. This patch registers the
debugfs entry after the probe debugging has been disabled.
> thanks,
>
> greg k-h
>
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
next prev parent reply other threads:[~2018-06-20 8:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-19 20:59 [PATCH] driver core: add a debugfs entry to show deferred devices Javier Martinez Canillas
2018-06-19 21:06 ` Andy Shevchenko
2018-06-19 22:51 ` Greg Kroah-Hartman
2018-06-19 23:43 ` Andy Shevchenko
2018-06-20 9:04 ` Javier Martinez Canillas
2018-06-20 8:46 ` Javier Martinez Canillas [this message]
2018-06-20 9:48 ` Javier Martinez Canillas
2018-06-20 10:54 ` Mark Brown
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=ea628ded-3cb3-c426-da6d-bf7cb51f4ca8@redhat.com \
--to=javierm@redhat.com \
--cc=linux-arm-kernel@lists.infradead.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).