From: Javier Martinez Canillas <javierm@redhat.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org,
Tomeu Vizoso <tomeu.vizoso@collabora.com>,
Rob Herring <robh@kernel.org>, Mark Brown <broonie@kernel.org>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
Peter Robinson <pbrobinson@gmail.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3] driver core: add a debugfs entry to show deferred devices
Date: Sun, 8 Jul 2018 15:33:55 +0200 [thread overview]
Message-ID: <1a75bc99-29e1-4a48-3f8e-dd3d89064326@redhat.com> (raw)
In-Reply-To: <20180708132213.GA29000@kroah.com>
On 07/08/2018 03:22 PM, Greg Kroah-Hartman wrote:
> On Sun, Jul 08, 2018 at 03:21:07PM +0200, Greg Kroah-Hartman wrote:
>> On Sun, Jul 08, 2018 at 02:32:56AM +0200, Javier Martinez Canillas wrote:
>>> With Device Trees (DT), the dependencies of the devices are defined in the
>>> DT, then the drivers parse that information to lookup the needed resources
>>> that have as dependencies.
>>>
>>> Since drivers and devices are registered in a non-deterministic way, it is
>>> possible that a device that is a dependency has not been registered yet by
>>> the time that is looked up.
>>>
>>> In this case the driver that requires this dependency cannot probe and has
>>> to defer it. So the driver core adds it to a list of deferred devices that
>>> is iterated again every time that a new driver is probed successfully.
>>>
>>> For debugging purposes it may be useful to know what are the devices whose
>>> probe function was deferred. Add a debugfs entry showing that information.
>>>
>>> $ cat /sys/kernel/debug/devices_deferred
>>> 48070000.i2c:twl@48:bci
>>> musb-hdrc.0.auto
>>> omapdrm.0
>>>
>>> This information could be obtained partially by enabling debugging, but it
>>> means that the kernel log has to be parsed and the probe deferral balanced
>>> with the successes. This can be error probe and has to be done in a ad-hoc
>>> manner by everyone who needs to debug these kind of issues.
>>>
>>> Since the information is already known by the kernel, just show it to make
>>> it easier to debug.
>>>
>>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>>> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>>> Reviewed-by: Mark Brown <broonie@kernel.org>
>>>
>>> ---
>>>
>>> Changes since RFC v1:
>>> - Remove unneeded ret variable from deferred_devs_show()
>>>
>>> Changes since RFC v2:
>>> - Use DEFINE_SHOW_ATTRIBUTE() macro.
>>> - Don't propagate debugfs_create_file() error.
>>> - Remove IS_ENABLED(CONFIG_DEBUG_FS) guards.
>>> - Drop RFC prefix.
>>>
>>> Changes since v1:
>>> - Better explain in the commit message why this patch is useful.
>>> - Rename deferred_devices entry to devices_deferred.
>>> - Add an exit function and remove the debugfs entry.
>>>
>>> Changes since v2:
>>> - Add Andy Shevchenko and Mark Brown Reviewed-by tag.
>>> - Rebase on top of Greg's driver-core-next branch.
>>>
>>>
>>> drivers/base/dd.c | 30 ++++++++++++++++++++++++++++++
>>> 1 file changed, 30 insertions(+)
>>>
>>> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
>>> index 6ea9c5cece7..140f534ee9c 100644
>>> --- a/drivers/base/dd.c
>>> +++ b/drivers/base/dd.c
>>> @@ -16,6 +16,7 @@
>>> * Copyright (c) 2007-2009 Novell Inc.
>>> */
>>>
>>> +#include <linux/debugfs.h>
>>> #include <linux/device.h>
>>> #include <linux/delay.h>
>>> #include <linux/dma-mapping.h>
>>> @@ -53,6 +54,8 @@ static DEFINE_MUTEX(deferred_probe_mutex);
>>> static LIST_HEAD(deferred_probe_pending_list);
>>> static LIST_HEAD(deferred_probe_active_list);
>>> static atomic_t deferred_trigger_count = ATOMIC_INIT(0);
>>> +static struct dentry *deferred_devices;
>>> +static bool initcalls_done;
>>
>> Wait, why add this variable? No one uses it that I can see in this
>> patch, doesn't it create a build warning?
>>
Argh, sorry about that. It was my bad when doing the conflict resolution. This
variable got removed by commit 0a50f61c4fb ("drivers: base: initcall_debug logs
for driver probe times") that made the patch to not apply cleanly anymore.
>> You did test-build this, right?
>
> I just tested it, it causes a build warning, which implies that you did
> not test this :(
>
I did but missed the build warning.
> greg k-h
>
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
prev parent reply other threads:[~2018-07-08 13:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-08 0:32 Javier Martinez Canillas
2018-07-08 13:21 ` Greg Kroah-Hartman
2018-07-08 13:22 ` Greg Kroah-Hartman
2018-07-08 13:33 ` Javier Martinez Canillas [this message]
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=1a75bc99-29e1-4a48-3f8e-dd3d89064326@redhat.com \
--to=javierm@redhat.com \
--cc=andy.shevchenko@gmail.com \
--cc=broonie@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbrobinson@gmail.com \
--cc=robh@kernel.org \
--cc=tomeu.vizoso@collabora.com \
/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
all inboxes | Powered by JetHome®