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: > > On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote: > >> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote: > > < snip > > > >>> + > >>> 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
