Re: [PATCH v5 0/6] driver core: Improve and cleanup driver_deferred_probe_check_state()

[John Stultz]

On Tue, Apr 21, 2020 at 4:59 PM Eugeniu Rosca <erosca@xxxxxxxxxxxxxx> wrote:
>
> Hi John,
> Cc: linux-renesas-soc
>
> On Tue, Feb 25, 2020 at 05:08:22AM +0000, John Stultz wrote:
> > This series goal is to improve and cleanup the
> > driver_deferred_probe_check_state() code in the driver core.
> >
> > This series is useful for being able to support modules
> > dependencies which may be loaded by userland, far after
> > late_initcall is done. For instance, this series allows us to
> > successfully use various clk drivers as modules on the db845c
> > board. And without it, those drivers have to be statically built
> > in to work.
> >
> > Since I first sent out this patch, Saravana suggested an
> > alternative approach which also works for our needs, and is a
> > bit simpler:
> >  https://lore.kernel.org/lkml/20200220055250.196456-1-saravanak@xxxxxxxxxx/T/#u
> >
> > However, while that patch provides the functionality we need,
> > I still suspect the driver_deferred_probe_check_state() code
> > could benefit from the cleanup in this patch, as the existing
> > logic is somewhat muddy.
> >
> > New in v5:
> > * Reworked the driver_deferred_probe_check_state() logic as
> >   suggested by Saravana to tie the initcall_done checking with
> >   modules being enabled.
> > * Cleanup some comment wording as suggested by Rafael
> > * Try to slightly simplify the regulator logic as suggested by
> >   Bjorn
> >
> > Thanks so much to Bjorn, Saravana and Rafael for their reviews
> > and suggestions! Additional review and feedback is always greatly
> > appreciated!
>
> Building a recent [0] kernel using vanilla arm64 defconfig
> and booting it on H3ULCB, I get buried into backtraces [1].
>
> After reverting this series, up to and including its first commit,
> booting goes back to normal [2].
>
> Any chance to get a fix or at least some hints where to dig into?

Yea. There's two patch sets I have for this. The first quiets down the
warnings(we don't need stack dumps for these):
  https://lore.kernel.org/lkml/20200330202715.86609-1-john.stultz@xxxxxxxxxx/

The second reverts the default timeout back to 0:
  https://lore.kernel.org/lkml/20200413204253.84991-1-john.stultz@xxxxxxxxxx/


Let me know if those work for you, or if you're still having trouble
afterwards.  I need to resubmit the set as I'm guessing they've been
overlooked.

thanks
-john