diff options
author | Mark Brown <broonie@kernel.org> | 2020-05-20 16:09:02 +0100 |
---|---|---|
committer | Mark Brown <broonie@kernel.org> | 2020-05-20 16:09:02 +0100 |
commit | a24490e0170e4cc6d4fd1f37691f19a106b694ae (patch) | |
tree | 20964ef269612a2ea33240274bc3422c74a02b15 /drivers/regulator | |
parent | 9bcbabafa19b9f27a283777eff32e7d66fcef09c (diff) | |
parent | 7e73861eb40d591a98628592c6f0182fbf2f6c4d (diff) | |
download | linux-a24490e0170e4cc6d4fd1f37691f19a106b694ae.tar.bz2 |
Merge series "MAINTAINER entries for few ROHM power devices" from Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>:
Add maintainer entries to a few ROHM devices and Linear Ranges
Linear Ranges helpers were refactored out of regulator core to lib so
that other drivers could utilize them too. (I guess power/supply drivers
and possibly clk drivers can benefit from them). As regulators is
currently the main user it makes sense the changes to linear_ranges go
through Mark's tree.
During past two years few ROHM PMIC drivers have been added to
mainstream. They deserve a supporter from ROHM side too :)
Patch 1:
Maintainer entries for few ROHM IC drivers
Patch 2:
Maintainer entry for linear ranges helpers
---
Matti Vaittinen (2):
MAINTAINERS: Add entry for ROHM power management ICs
MAINTAINERS: Add maintainer entry for linear ranges helper
MAINTAINERS | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
base-commit: b9bbe6ed63b2b9f2c9ee5cbd0f2c946a2723f4ce
--
2.21.0
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =]
Diffstat (limited to 'drivers/regulator')
-rw-r--r-- | drivers/regulator/core.c | 25 |
1 files changed, 11 insertions, 14 deletions
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index ad143004c32b..941783a14b45 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -5755,10 +5755,6 @@ static DECLARE_DELAYED_WORK(regulator_init_complete_work, static int __init regulator_init_complete(void) { - int delay = driver_deferred_probe_timeout; - - if (delay < 0) - delay = 0; /* * Since DT doesn't provide an idiomatic mechanism for * enabling full constraints and since it's much more natural @@ -5769,17 +5765,18 @@ static int __init regulator_init_complete(void) has_full_constraints = true; /* - * 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. + * 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. */ - schedule_delayed_work(®ulator_init_complete_work, delay * HZ); + schedule_delayed_work(®ulator_init_complete_work, + msecs_to_jiffies(30000)); return 0; } |