Patch "regulator: core: Clean enabling always-on regulators + their supplies" has been added to the 4.19-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    regulator: core: Clean enabling always-on regulators + their supplies

to the 4.19-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     regulator-core-clean-enabling-always-on-regulators-t.patch
and it can be found in the queue-4.19 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 1100c4b652441bc91aa322c5caee05a3738a9ea1
Author: Douglas Anderson <dianders@xxxxxxxxxxxx>
Date:   Thu Dec 6 14:23:18 2018 -0800

    regulator: core: Clean enabling always-on regulators + their supplies
    
    [ Upstream commit 05f224ca669398b567d09feb6e2ceefcb7d7f945 ]
    
    At the end of regulator_resolve_supply() we have historically turned
    on our supply in some cases.  This could be for one of two reasons:
    
    1. If resolving supplies was happening before the call to
       set_machine_constraints() we needed to predict if
       set_machine_constraints() was going to turn the regulator on and we
       needed to preemptively turn the supply on.
    2. Maybe set_machine_constraints() happened before we could resolve
       supplies (because we failed the first time to resolve) and thus we
       might need to propagate an enable that already happened up to our
       supply.
    
    Historically regulator_resolve_supply() used _regulator_is_enabled()
    to decide whether to turn on the supply.
    
    Let's change things a little bit.  Specifically:
    
    1. Let's try to enable the supply and the regulator in the same place,
       both in set_machine_constraints().  This means that we have exactly
       the same logic for enabling the supply and the regulator.
    2. Let's properly set use_count when we enable always-on or boot-on
       regulators even for those that don't have supplies.  The previous
       commit 1fc12b05895e ("regulator: core: Avoid propagating to
       supplies when possible") only did this right for regulators with
       supplies.
    3. Let's make it clear that the only time we need to enable the supply
       in regulator_resolve_supply() is if the main regulator is currently
       in use.  By using use_count (like the rest of the code) to decide
       if we're going to enable our supply we keep everything consistent.
    
    Overall the new scheme should be cleaner and easier to reason about.
    In addition to fixing regulator_summary to be more correct (because of
    the more correct use_count), this change also has the effect of no
    longer using _regulator_is_enabled() in this code path.
    _regulator_is_enabled() could return an error code for some regulators
    at bootup (like RPMh) that can't read their initial state.  While one
    can argue that the design of those regulators is sub-optimal, the new
    logic sidesteps this brokenness.  This fix in particular fixes
    observed problems on Qualcomm sdm845 boards which use the
    above-mentioned RPMh regulator.  Those problems were made worse by
    commit 1fc12b05895e ("regulator: core: Avoid propagating to supplies
    when possible") because now we'd think at bootup that the SD
    regulators were already enabled and we'd never try them again.
    
    Fixes: 1fc12b05895e ("regulator: core: Avoid propagating to supplies when possible")
    Reported-by: Evan Green <evgreen@xxxxxxxxxxxx>
    Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx>
    Signed-off-by: Mark Brown <broonie@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 870baa7036ecd..b79ecf37e40f8 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1191,11 +1191,21 @@ static int set_machine_constraints(struct regulator_dev *rdev)
 	 * and we have control then make sure it is enabled.
 	 */
 	if (rdev->constraints->always_on || rdev->constraints->boot_on) {
+		if (rdev->supply) {
+			ret = regulator_enable(rdev->supply);
+			if (ret < 0) {
+				_regulator_put(rdev->supply);
+				rdev->supply = NULL;
+				return ret;
+			}
+		}
+
 		ret = _regulator_do_enable(rdev);
 		if (ret < 0 && ret != -EINVAL) {
 			rdev_err(rdev, "failed to enable\n");
 			return ret;
 		}
+		rdev->use_count++;
 	}
 
 	print_constraints(rdev);
@@ -1645,8 +1655,12 @@ static int regulator_resolve_supply(struct regulator_dev *rdev)
 		goto out;
 	}
 
-	/* Cascade always-on state to supply */
-	if (_regulator_is_enabled(rdev)) {
+	/*
+	 * In set_machine_constraints() we may have turned this regulator on
+	 * but we couldn't propagate to the supply if it hadn't been resolved
+	 * yet.  Do it now.
+	 */
+	if (rdev->use_count) {
 		ret = regulator_enable(rdev->supply);
 		if (ret < 0) {
 			_regulator_put(rdev->supply);



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux