From: pavel@ucw.cz (Pavel Machek)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4] driver core: add a debugfs entry to show deferred devices
Date: Tue, 10 Jul 2018 14:36:49 +0200 [thread overview]
Message-ID: <20180710123648.GA4227@amd> (raw)
In-Reply-To: <20180710100152.bb562zgbv7yimb7r@earth.universe>
Hi!
> > 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 at 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>
>
> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Thanks for doing this.
Note that it rejects on current -rc4, but solution is trivial.
Tested-by: Pavel Machek <pavel@ucw.cz>
Unfortunately, it does not help with pwm problem on Droid4, as nothing
is deffered:
user at devuan:/sys/bus/platform/drivers$ cat
/sys/kernel/debug/devices_deferred
user at devuan:/sys/bus/platform/drivers$
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180710/8cb18740/attachment.sig>
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@ucw.cz>
To: Sebastian Reichel <sre@kernel.org>
Cc: Javier Martinez Canillas <javierm@redhat.com>,
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,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v4] driver core: add a debugfs entry to show deferred devices
Date: Tue, 10 Jul 2018 14:36:49 +0200 [thread overview]
Message-ID: <20180710123648.GA4227@amd> (raw)
In-Reply-To: <20180710100152.bb562zgbv7yimb7r@earth.universe>
[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]
Hi!
> > 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>
>
> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Thanks for doing this.
Note that it rejects on current -rc4, but solution is trivial.
Tested-by: Pavel Machek <pavel@ucw.cz>
Unfortunately, it does not help with pwm problem on Droid4, as nothing
is deffered:
user@devuan:/sys/bus/platform/drivers$ cat
/sys/kernel/debug/devices_deferred
user@devuan:/sys/bus/platform/drivers$
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2018-07-10 12:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-08 13:34 [PATCH v4] driver core: add a debugfs entry to show deferred devices Javier Martinez Canillas
2018-07-08 13:34 ` Javier Martinez Canillas
2018-07-10 10:01 ` Sebastian Reichel
2018-07-10 10:01 ` Sebastian Reichel
2018-07-10 12:36 ` Pavel Machek [this message]
2018-07-10 12:36 ` Pavel Machek
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=20180710123648.GA4227@amd \
--to=pavel@ucw.cz \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.