On Wed, Oct 21, 2015 at 08:36:23AM -0700, Frank Rowand wrote:

On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:

quoted

On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:

quoted

On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:

< snip >

quoted

quoted

quoted

+
 static bool driver_deferred_probe_enable = false;
+
 /**
  * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
  *

@@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
 	driver_deferred_probe_trigger();

Couldn't you put the "driver_deferred_probe_report = true" here?  And then
not add another round of probes.

The idea is not to report anything for drivers that were deferred
during the normal bootup.  The above is part of the normal bootup,
and the deferred activity should not be warned about.

The above is currently the last point for probe to succeed or defer
(until possibly, as you mentioned, module loading resolves the defer).
If a probe defers above, it will defer again below.  The set of defers
should be exactly the same above and below.

Why should it?  Isn't this late_initcall() the first opportunity that
deferred devices get to be re-probed from their first set of attempts
via the drivers having their initcalls called?

If what you're saying is true, what's the point of this late_initcall()?

<re-cut again, I've no idea why you keep adding it back>

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.