linux-stable.git/drivers/regulator/core.c, branch linux-5.2.y

regulator: Defer init completion for a while after late_initcall

2019-10-05T11:14:09+00:00

commit 55576cf1853798e86f620766e23b604c9224c19c upstream.

The kernel has no way of knowing when we have finished instantiating
drivers, between deferred probe and systems that build key drivers as
modules we might be doing this long after userspace has booted. This has
always been a bit of an issue with regulator_init_complete since it can
power off hardware that's not had it's driver loaded which can result in
user visible effects, the main case is powering off displays. Practically
speaking it's not been an issue in real systems since most systems that
use the regulator API are embedded and build in key drivers anyway but
with Arm laptops coming on the market it's becoming more of an issue so
let's do something about it.

In the absence of any better idea just defer the powering off for 30s
after late_initcall(), this is obviously a hack but it should mask the
issue for now and it's no more arbitrary than late_initcall() itself.
Ideally we'd have some heuristics to detect if we're on an affected
system and tune or skip the delay appropriately, and there may be some
need for a command line option to be added.

Link: https://lore.kernel.org/r/20190904124250.25844-1-broonie@kernel.org
Signed-off-by: Mark Brown 
Tested-by: Lee Jones 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152

2019-05-30T18:26:32+00:00

Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation either version 2 of the license or at
  your option any later version

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 3029 file(s).

Signed-off-by: Thomas Gleixner 
Reviewed-by: Allison Randal 
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
Signed-off-by: Greg Kroah-Hartman

Merge branch 'regulator-5.2' into regulator-next

2019-05-06T13:52:14+00:00

regulator: core: simplify return value on suported_voltage

2019-05-03T06:34:26+00:00

All the current clients of this API  assume that 0 corresponds
to a failure and non-zero to a pass therefore ignoring the need to
handle a negative error code.

This commit modifies the API to follow that standard since returning a
negative (EINVAL) doesn't seem to provide enough value to justify
the need to handle it.

Signed-off-by: Jorge Ramirez-Ortiz 
Signed-off-by: Mark Brown

regulator: core: do not report EPROBE_DEFER as error but as debug

2019-04-26T09:38:24+00:00

Temporary failures to get a regulator (EPROBE_DEFER) should be logged
as debug information instead of errors.

Signed-off-by: Jorge Ramirez-Ortiz 
Signed-off-by: Mark Brown

regulator: core: Actually put the gpiod after use

2019-04-25T19:04:56+00:00

I went to great lengths to hand over the management of the GPIO
descriptors to the regulator core, and some stray rebased
oneliner in the old patch must have been assuming the devices
were still doing devres management of it.

We handed the management over to the regulator core, so of
course the regulator core shall issue gpiod_put() when done.

Sorry for the descriptor leak.

Fixes: 541d052d7215 ("regulator: core: Only support passing enable GPIO descriptors")
Signed-off-by: Linus Walleij 
Signed-off-by: Mark Brown

regulator: core: Avoid potential deadlock on regulator_unregister

2019-04-05T02:35:36+00:00

Lockdep reports the following issue on my setup:

Possible unsafe locking scenario:

CPU0                    CPU1
----                    ----
lock((work_completion)(&(&rdev->disable_work)->work));
                        lock(regulator_list_mutex);
                        lock((work_completion)(&(&rdev->disable_work)->work));
lock(regulator_list_mutex);

The problem is that regulator_unregister takes the
regulator_list_mutex and then calls flush_work on disable_work. But
regulator_disable_work calls regulator_lock_dependent which will
also take the regulator_list_mutex. Resulting in a deadlock if the
flush_work call actually needs to flush the work.

Fix this issue by moving the flush_work outside of the
regulator_list_mutex. The list mutex is not used to guard the point at
which the delayed work is queued, so its use adds no additional safety.

Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: Charles Keepax 
Reviewed-by: Dmitry Osipenko 
Signed-off-by: Mark Brown

regulator: core: fix error path for regulator_set_voltage_unlocked

2019-03-19T13:02:45+00:00

During several error paths in the function
regulator_set_voltage_unlocked() the value of 'ret' can take on negative
error values. However, in calls that go through the 'goto out' statement,
this return value is lost and return 0 is used instead, indicating a
'pass'.

There are several cases where this function should legitimately return a
fail instead of a pass: one such case includes constraints check during
voltage selection in the call to regulator_check_voltage(), which can
have -EINVAL for the case when an unsupported voltage is incorrectly
requested. In that case, -22 is expected as the return value, not 0.

Fixes: 9243a195be7a ("regulator: core: Change voltage setting path")
Cc: stable 
Signed-off-by: Steve Twiss 
Reviewed-by: Dmitry Osipenko 
Signed-off-by: Mark Brown

regulator: core: Fix application of "drop lockdep annotation in drms_uA_update()"

2019-03-18T15:01:37+00:00

[The original commit was sent against -next but needed to be sent as a
bugfix, however -next had some additional changes which needed to be
reverted.  Now everything is all in one branch applying the rest of the
changes to fix up the merge issue -- broonie]

commit e5e21f70bfd3 ("regulator: core: Take lock before applying system
load") took the regulator lock before calling drms_uA_update() in order
to silence a lockdep warning during regulator_register().

However, we are not supposed to need locks at this point as the regulator
is in the process of being registered, so there should be no possibility
of concurrent access.

Instead, remove the unnecessary locking and simply drop the lockdep
annotation, since it is no longer valid.

Fixes: e5e21f70bfd3 ("regulator: core: Take lock before applying system load")
Signed-off-by: Niklas Cassel 
Signed-off-by: Mark Brown

regulator: core: Log forbidden DRMS operation

2019-02-21T18:53:37+00:00

When REGULATOR_CHANGE_DRMS is not set, drms_uA_update is a no-op.
It used to print a debug message, which was dropped in commit
8a34e979f684 ("regulator: refactor valid_ops_mask checking code")

Let's bring the debug message back, because it helps find missing
regulator-allow-set-load properties.

Signed-off-by: Marc Gonzalez 
Signed-off-by: Mark Brown