summaryrefslogtreecommitdiff
path: root/drivers/regulator/da9121-regulator.c
diff options
context:
space:
mode:
authorOliver Barta <oliver.barta@aptiv.com>2022-02-08 09:46:45 +0100
committerMark Brown <broonie@kernel.org>2022-02-08 13:37:48 +0000
commit4e2a354e3775870ca823f1fb29bbbffbe11059a6 (patch)
tree750fd56c7f4424a9d46bede80b82a2feaf5d09d7 /drivers/regulator/da9121-regulator.c
parentb4c18c18ebf7cf1e602af88c12ef9cb0d6e5ce51 (diff)
downloadlwn-4e2a354e3775870ca823f1fb29bbbffbe11059a6.tar.gz
lwn-4e2a354e3775870ca823f1fb29bbbffbe11059a6.zip
regulator: core: fix false positive in regulator_late_cleanup()
The check done by regulator_late_cleanup() to detect whether a regulator is on was inconsistent with the check done by _regulator_is_enabled(). While _regulator_is_enabled() takes the enable GPIO into account, regulator_late_cleanup() was not doing that. This resulted in a false positive, e.g. when a GPIO-controlled fixed regulator was used, which was not enabled at boot time, e.g. reg_disp_1v2: reg_disp_1v2 { compatible = "regulator-fixed"; regulator-name = "display_1v2"; regulator-min-microvolt = <1200000>; regulator-max-microvolt = <1200000>; gpio = <&tlmm 148 0>; enable-active-high; }; Such regulator doesn't have an is_enabled() operation. Nevertheless it's state can be determined based on the enable GPIO. The check in regulator_late_cleanup() wrongly assumed that the regulator is on and tried to disable it. Signed-off-by: Oliver Barta <oliver.barta@aptiv.com> Link: https://lore.kernel.org/r/20220208084645.8686-1-oliver.barta@aptiv.com Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'drivers/regulator/da9121-regulator.c')
0 files changed, 0 insertions, 0 deletions