On Mon, Mar 30, 2020 at 6:30 AM Robin Murphy <robin.murphy@xxxxxxx> wrote: > > On 2020-03-30 2:11 pm, Andy Shevchenko wrote: > > On Mon, Mar 30, 2020 at 3:49 PM Robin Murphy <robin.murphy@xxxxxxx> wrote: > >> On 2020-03-30 11:13 am, Sudeep Holla wrote: > >>> On Fri, Mar 27, 2020 at 07:40:25PM +0000, Robin Murphy wrote: > > > > ... > > > >> AFAICS the difference is down to whether deferred_probe_timeout has > >> expired or not - I'm not familiar enough with this code to know > >> *exactly* what the difference is supposed to represent, nor which change > >> has actually pushed the Juno case from one state to the other (other > >> than it almost certainly can't be $SUBJECT - if this series is to blame > >> at all I'd assume it would be down to patch #1/3, but there's a bunch of > >> other rework previously queued in -next that is probably also interacting) > > > > JFYI: patch #1/3 wasn't applied. > > OK, so if anyone's invested enough to want to investigate, it must be > something in John's earlier changes here: > > https://lore.kernel.org/lkml/20200225050828.56458-1-john.stultz@xxxxxxxxxx/ Hey all, Sorry, I just got a heads up about this thread. So yea, it looks like the change is due likely to the first patch in my series. Previously, after initcall_done, (since deferred_probe_timeout was -1 unless manually specified) if the driver wasn't already loaded we'd print "ignoring dependency for device, assuming no driver" and return ENODEV. Now, if modules are enabled (as without modules enabled, I believe you'd see the same behavior as previous), we wait 30 seconds (for userspace to load any posssible modules that meet that dependency) and then the driver_deferred_probe_timeout fires and we print "deferred probe timeout, ignoring dependency". It seems the issue here is the first message was printed with dev_warn() and the second with dev_WARN() which provides the scary backtrace. I think functionally as mentioned above, there's no real behavioral change here. But please correct me if that's wrong. Since we are more likely to see the second message now, maybe we should make both print via dev_warn()? I'll spin up a patch. thanks -john
