Messages in this thread | | | Date | Thu, 20 Feb 2020 08:05:22 -0800 | From | Bjorn Andersson <> | Subject | Re: [PATCH v4 6/6] regulator: Use driver_deferred_probe_timeout for regulator_init_complete_work |
| |
On Wed 19 Feb 21:04 PST 2020, John Stultz wrote:
> The regulator_init_complete_work logic defers the cleanup for an > arbitrary 30 seconds of time to allow modules loaded by userland > to start. > > This arbitrary timeout is similar to the > driver_deferred_probe_timeout value, and its been suggested we > align these so users have a method to extend the timeouts as > needed. > > So this patch changes the logic to use the > driver_deferred_probe_timeout value if it is set, otherwise we > directly call the regulator_init_complete_work_function(). > > Cc: Rob Herring <robh@kernel.org> > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> > Cc: Kevin Hilman <khilman@kernel.org> > Cc: Ulf Hansson <ulf.hansson@linaro.org> > Cc: Pavel Machek <pavel@ucw.cz> > Cc: Len Brown <len.brown@intel.com> > Cc: Todd Kjos <tkjos@google.com> > Cc: Bjorn Andersson <bjorn.andersson@linaro.org> > Cc: Liam Girdwood <lgirdwood@gmail.com> > Cc: Mark Brown <broonie@kernel.org> > Cc: Thierry Reding <treding@nvidia.com> > Cc: Linus Walleij <linus.walleij@linaro.org> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: linux-pm@vger.kernel.org > Signed-off-by: John Stultz <john.stultz@linaro.org> > Change-Id: I9fa2411abbb91ed4dd0edc41e8cc8583577c005b
Change-Id...
> --- > v4: > * Split out into its own patch, as suggested by Mark > --- > drivers/regulator/core.c | 25 ++++++++++++++----------- > 1 file changed, 14 insertions(+), 11 deletions(-) > > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c > index d015d99cb59d..394e7b11576a 100644 > --- a/drivers/regulator/core.c > +++ b/drivers/regulator/core.c > @@ -5767,18 +5767,21 @@ static int __init regulator_init_complete(void) > has_full_constraints = true; > > /* > - * We punt completion for an arbitrary amount of time since > - * systems like distros will load many drivers from userspace > - * so consumers might not always be ready yet, this is > - * particularly an issue with laptops where this might bounce > - * the display off then on. Ideally we'd get a notification > - * from userspace when this happens but we don't so just wait > - * a bit and hope we waited long enough. It'd be better if > - * we'd only do this on systems that need it, and a kernel > - * command line option might be useful. > + * If driver_deferred_probe_timeout is set, we punt > + * completion for that many seconds since systems like > + * distros will load many drivers from userspace so consumers > + * might not always be ready yet, this is particularly an > + * issue with laptops where this might bounce the display off > + * then on. Ideally we'd get a notification from userspace > + * when this happens but we don't so just wait a bit and hope > + * we waited long enough. It'd be better if we'd only do > + * this on systems that need it. > */ > - schedule_delayed_work(®ulator_init_complete_work, > - msecs_to_jiffies(30000)); > + if (driver_deferred_probe_timeout >= 0) > + schedule_delayed_work(®ulator_init_complete_work, > + driver_deferred_probe_timeout * HZ); > + else > + regulator_init_complete_work_function(NULL);
Why not schedule_delayed_work(..., 0) in this case, to get it off the initcall context and to avoid the difference in execution paths?
Regards, Bjorn
> > return 0; > } > -- > 2.17.1 >
| |