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
