devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomeu Vizoso <tomeu.vizoso@collabora.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: "Mark Brown" <broonie@kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Stephen Boyd" <sboyd@codeaurora.org>,
	"Vinod Koul" <vinod.koul@intel.com>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Alexandre Courbot" <gnurou@gmail.com>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"David Airlie" <airlied@linux.ie>,
	"Terje Bergström" <tbergstrom@nvidia.com>,
	"Stephen Warren" <swarren@wwwdotorg.org>,
	"Wolfram Sang" <wsa@the-dreams.de>,
	"Frank Rowand" <frowand.list@gmail.com>,
	"Grant Likely" <grant.likely@linaro.org>,
	"Kishon Vijay Abraham I" <kishon@ti.com>,
	"Sebastian Reichel" <sre@kernel.org>,
	"Dmitry Eremin-Solenikov" <dbaryshkov@gmail.com>,
	"David Woodhouse" <dwmw2@infradead.org>,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	"Felipe Balbi" <balbi@ti.com>
Subject: Re: [GIT PULL] On-demand device probing
Date: Mon, 19 Oct 2015 17:00:54 +0200	[thread overview]
Message-ID: <CAAObsKDWM6A98tdKHqi4fe5DBf0BmB0JeghcZDWan_PYbyshag@mail.gmail.com> (raw)
In-Reply-To: <20151019143045.GE32532@n2100.arm.linux.org.uk>

On 19 October 2015 at 16:30, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Oct 19, 2015 at 04:10:56PM +0200, Tomeu Vizoso wrote:
>> On 19 October 2015 at 15:18, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
>> >> ... If a device is available and has
>> >> a compatible driver, but it cannot be probed because a dependency
>> >> isn't going to be available, that's an error and is going to cause
>> >> real-world problems unless the device is redundant. Currently we say
>> >> nothing because with deferred probe the probe callbacks are also part
>> >> of the mechanism that determines the dependency order.
>> >
>> > So what if device X depends on device Y, and we have a driver for
>> > device Y built-in to the kernel, but the driver for device X is a
>> > module?
>> >
>> > I don't see this being solvable in the way you describe above - it's
>> > going to identify X as being unable to be satisfied, and report it as
>> > an error - but it's not an error at all.
>>
>> It's going to probe Y at late_initcall, then probe X when its driver
>> is registered. No deferred probes nor messages about it.
>>
>> But if you meant to write the opposite case (X built-in and Y in a
>> module), then I have to ask you in what situation that would make
>> sense.
>
> I did mean the opposite way around.  It may not make sense if you're
> targetting a single platform, but it may make sense in a single zImage
> kernel.
>
> Consider something like a single zImage kernel that is built with
> everything built-in to be able to boot and mount rootfs without
> initramfs support on both platform A and platform B.  Both platforms
> share some hardware (eg, an I2C GPIO expander) which is built as a
> module.  It is a resource provider.  Platform B contains a driver
> which is required to boot on platform A, but not platform B (so the
> kernel has to have that driver built-in.)  On platform B, there is
> a dependency to the I2C GPIO expander device.

I see, in this situation the person trying to find out why some device
hadn't probed would enable debug logging of failed probes and would
see one spurious message if there was a deferred probe because of the
module.

>> >> Having a specific switch for enabling deferred probe logging sounds
>> >> good, but there's going to be hundreds of spurious messages about
>> >> deferred probes that were just deferrals and only one of them is going
>> >> to be the actual error in which a device failed to find a dependency.
>> >
>> > Why would there be?  Sounds like something's very wrong there.
>>
>> Sorry about that, I have checked that only now and I "only" get 39
>> deferred probe messages on exynos5250-snow.
>
> I typically see one or two, maybe five maximum on the platforms I have
> here, but normally zero.

Hmm, I have given a look at our lava farm and have seen 2 dozens as
common (with multi_v7).

>> > So, really, after boot and all appropriate modules have been loaded,
>> > you should end up with no deferred probes.  Are you saying that you
>> > still have "hundreds" at that point?  If you do, that sounds like
>> > there's something very wrong.
>>
>> I was talking about messages if we log each -EPROBE_DEFER, not devices
>> that remain to be probed. The point being that right now we don't have
>> a way to know if we are deferring because the dependency will be
>> around later, or if we have a problem and the dependency isn't going
>> to be there at all.
>
> What's the difference between a dependency which isn't around because
> the driver is not built into the kernel but is available as a module,
> and a dependency that isn't around because the module hasn't been
> loaded yet?
>
> How do you distinguish between those two scenarios?  In the former
> scenario, the device will eventually come up when udev loads the
> module.  In the latter case, it's a persistent failing case.

Agreed, but it's something that doesn't happen often and that's why
such messages would be at the debug level instead of being warns or
errors.

>> Agreed, with the note from above on why it would be better to only
>> print such a message only when the -EPROBE_DEFER is likely to be a
>> problem.
>
> ... and my argument is that there's _no way_ to know for certain which
> deferred probes will be a problem, and which won't.  The only way to
> definitely know that is if you disable kernel modules, and require
> all drivers to be built into the kernel.
>
> What you can do is print those devices which have failed to probe at
> late_initcall() time - possibly augmenting that with reports from
> subsystems showing what resources are not available, but that's only
> a guide, because of the "it might or might not be in a kernel module"
> problem.

Well, adding those reports would give you a changelog similar to the
one in this series...

Thanks,

Tomeu

> --
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

  reply	other threads:[~2015-10-19 15:00 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-14  8:34 [GIT PULL] On-demand device probing Tomeu Vizoso
2015-10-14  9:26 ` Mark Brown
2015-10-15 11:42   ` Tomeu Vizoso
     [not found]     ` <1444909328-24761-1-git-send-email-tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2015-10-16 21:23       ` Olof Johansson
2015-10-17 15:19         ` Rob Herring
2015-10-19 16:52           ` Olof Johansson
2015-10-17  6:57 ` Greg Kroah-Hartman
2015-10-17 15:04   ` Rob Herring
2015-10-17 15:47     ` Greg Kroah-Hartman
2015-10-17 16:28       ` Rob Herring
2015-10-17 16:56         ` Greg Kroah-Hartman
2015-10-17 17:54           ` Rob Clark
2015-10-17 18:27             ` Greg Kroah-Hartman
2015-10-17 18:45               ` Rob Clark
2015-10-17 18:59                 ` Greg Kroah-Hartman
2015-10-17 19:39                   ` Rob Clark
2015-10-17 20:22                     ` Greg Kroah-Hartman
2015-10-17 19:04                 ` Noralf Trønnes
2015-10-17 19:48                   ` Rob Clark
2015-10-18 19:41       ` Mark Brown
2015-10-18 19:29   ` Mark Brown
2015-10-18 19:37     ` Greg Kroah-Hartman
2015-10-18 19:53       ` Mark Brown
2015-10-19  9:44         ` David Woodhouse
2015-10-19  9:52           ` Russell King - ARM Linux
2015-10-19 11:02           ` Mark Brown
2015-10-19 12:35           ` Rob Herring
2015-10-19 12:47             ` David Woodhouse
2015-10-19 14:50               ` Mark Brown
2015-10-19 15:29                 ` David Woodhouse
2015-10-19 15:43                   ` Russell King - ARM Linux
2015-10-19 18:27                     ` Uwe Kleine-König
2015-10-19 18:39                       ` Russell King - ARM Linux
2015-10-19 23:47                         ` Alexandre Courbot
2015-10-20 11:12                     ` David Woodhouse
2015-10-19 15:58                   ` Rob Herring
2015-10-19 21:40                     ` Rafael J. Wysocki
2015-10-19 22:58                       ` Rob Herring
     [not found]                         ` <CAL_JsqKa3MFJUWKV2KxPE_NmrP2g4dOD3zr+0Kyx4yBkDOg2HA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-10-20  7:56                           ` Rafael J. Wysocki
2015-10-20 14:15                             ` Rob Herring
     [not found]                               ` <CAL_JsqJuu5_Osqi+X6M6UeRDZFQB+_8riYDF1gvsGayk5-4SFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-10-20 14:40                                 ` Alan Stern
2015-10-20 15:36                                   ` Mark Brown
2015-10-20 16:04                                     ` Alan Stern
2015-10-20 16:21                                       ` Tomeu Vizoso
2015-10-20 17:14                                         ` Alan Stern
2015-10-20 19:35                                           ` Mark Brown
2015-10-20 23:35                                             ` Rafael J. Wysocki
2015-10-21  6:15                                               ` Jean-Francois Moine
2015-10-22  0:54                                         ` Rafael J. Wysocki
2015-10-22  9:14                                           ` Tomeu Vizoso
2015-10-27  5:03                                       ` Rafael J. Wysocki
2015-10-20 23:34                               ` Rafael J. Wysocki
2015-10-21  8:55                                 ` Geert Uytterhoeven
2015-10-21 23:39                                   ` Rafael J. Wysocki
2015-10-19 16:04                   ` Mark Brown
2015-10-19 12:34         ` Tomeu Vizoso
2015-10-19 13:18           ` Russell King - ARM Linux
     [not found]             ` <20151019131821.GA32532-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2015-10-19 14:10               ` Tomeu Vizoso
2015-10-19 14:30                 ` Russell King - ARM Linux
2015-10-19 15:00                   ` Tomeu Vizoso [this message]
2015-10-19 15:35                     ` Russell King - ARM Linux
2015-10-19 16:21                       ` Geert Uytterhoeven
2015-10-19 16:45                         ` Russell King - ARM Linux
2015-10-20 15:46                         ` Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing) Russell King - ARM Linux
2015-10-21  3:58                           ` Alternative approach to solve the deferred probe Frank Rowand
2015-10-21  8:18                             ` Russell King - ARM Linux
2015-10-21 15:36                               ` Frank Rowand
2015-10-21 16:55                                 ` Grygorii Strashko
2015-10-21 17:20                                   ` Russell King - ARM Linux
2015-10-21 18:13                                     ` Grygorii Strashko
2015-10-21 18:28                                       ` Russell King - ARM Linux
2015-10-22 15:12                                         ` Grygorii Strashko
2015-10-21 18:02                                   ` Frank Rowand
2015-10-21 18:29                                     ` Grygorii Strashko
2015-10-21 20:35                                 ` Russell King - ARM Linux
2015-10-22  0:05                                   ` Frank Rowand
2015-10-22 13:20                           ` Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing) Mark Brown
     [not found]           ` <CAAObsKB2BUZ-smid45wOdAQw6h2yNqCydk+azAFNk69ewHJtZQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-10-21 15:59             ` [GIT PULL] On-demand device probing Frank Rowand
2015-10-21 16:27               ` Mark Brown
2015-10-21 18:18                 ` Frank Rowand
2015-10-21 21:03                   ` Mark Brown
2015-10-21 21:12                   ` Rob Herring
2015-10-21 21:50                     ` Frank Rowand
2015-10-22  9:05                       ` Tomeu Vizoso
2015-10-22 14:38                         ` Greg Kroah-Hartman
2015-10-22 14:44                         ` Greg Kroah-Hartman
     [not found]                           ` <20151022144405.GC21861-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2015-10-22 15:02                             ` Russell King - ARM Linux
2015-10-22 23:33                               ` Mark Brown
2015-10-22 18:53                           ` Frank Rowand
2015-10-22 19:26                             ` Greg Kroah-Hartman
     [not found]                               ` <20151022192639.GC27248-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2015-10-23 12:28                                 ` Tomeu Vizoso
     [not found]                             ` <562930AB.1070203-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-10-23 15:45                               ` Tim Bird
2015-10-23 16:34                                 ` Rob Herring
2015-10-24 14:17                                   ` Rafael J. Wysocki
2015-10-24 22:06                                     ` Mark Brown
2015-10-25 13:54                                       ` Rafael J. Wysocki
2015-10-26  1:12                                         ` Mark Brown
2015-10-26 10:51                                         ` Michael Turquette
2015-10-26 12:55                                           ` Tomeu Vizoso
2015-10-26 23:37                                           ` Rafael J. Wysocki
2015-10-25 19:45                                 ` Andrew F. Davis
2015-10-24 17:55                             ` Geert Uytterhoeven

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=CAAObsKDWM6A98tdKHqi4fe5DBf0BmB0JeghcZDWan_PYbyshag@mail.gmail.com \
    --to=tomeu.vizoso@collabora.com \
    --cc=airlied@linux.ie \
    --cc=balbi@ti.com \
    --cc=broonie@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=dbaryshkov@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=frowand.list@gmail.com \
    --cc=gnurou@gmail.com \
    --cc=grant.likely@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kishon@ti.com \
    --cc=lgirdwood@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mturquette@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@codeaurora.org \
    --cc=sre@kernel.org \
    --cc=swarren@wwwdotorg.org \
    --cc=tbergstrom@nvidia.com \
    --cc=thierry.reding@gmail.com \
    --cc=vinod.koul@intel.com \
    --cc=wsa@the-dreams.de \
    /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).