regulator: core: Don't err if allow-set-load but no allowed-modes

Bugzilla: https://bugzilla.redhat.com/2157968

commit 57919f4
Author: Douglas Anderson <dianders@chromium.org>
Date:   Wed Aug 24 14:22:57 2022 -0700

    regulator: core: Don't err if allow-set-load but no allowed-modes

    Apparently the device trees of some boards have the property
    "regulator-allow-set-load" for some of their regulators but then they
    don't specify anything for "regulator-allowed-modes". That's not
    really legit, but...

    ...before commit efb0cb5 ("regulator: qcom-rpmh: Implement
    get_optimum_mode(), not set_load()") they used to get away with it, at
    least on boards using RPMH regulators. That's because when a regulator
    driver implements set_load() then the core doesn't look at
    "regulator-allowed-modes" when trying to automatically adjust things
    in response to the regulator's load. The core doesn't know what mode
    we'll end up in, so how could it validate it?

    Said another way: before commit efb0cb5 ("regulator: qcom-rpmh:
    Implement get_optimum_mode(), not set_load()") some boards _were_
    having the regulator mode adjusted despite listing no allowed
    modes. After commit efb0cb5 ("regulator: qcom-rpmh: Implement
    get_optimum_mode(), not set_load()") these same boards were now
    getting an error returned when trying to use their regulators, since
    simply enabling a regulator tries to update its load and that was
    failing.

    We don't really want to go back to the behavior from before commit
    efb0cb5 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not
    set_load()"). Boards shouldn't have been changing modes if no allowed
    modes were listed. However, the behavior after commit efb0cb5
    ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()")
    isn't the best because now boards can't even turn their regulators on.

    Let's choose to detect this case and return "no error" from
    drms_uA_update(). The net-result will be _different_ behavior than we
    had before commit efb0cb5 ("regulator: qcom-rpmh: Implement
    get_optimum_mode(), not set_load()"), but this new behavior seems more
    correct. If a board truly needed the mode switched then its device
    tree should be updated to list the allowed modes.

    Reported-by: Andrew Halaney <ahalaney@redhat.com>
    Fixes: efb0cb5 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()")
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Tested-by: Andrew Halaney <ahalaney@redhat.com>
    Link: https://lore.kernel.org/r/20220824142229.RFT.v2.2.I6f77860e5cd98bf5c67208fa9edda4a08847c304@changeid
    Signed-off-by: Mark Brown <broonie@kernel.org>

Signed-off-by: Adrien Thierry <athierry@redhat.com>

Author: athierry1

drivers/regulator/core.c

@@ -952,6 +952,18 @@ static int drms_uA_update(struct regulator_dev *rdev)
 			rdev_err(rdev, "failed to set load %d: %pe\n",
 				 current_uA, ERR_PTR(err));
 	} else {
+		/*
+		 * Unfortunately in some cases the constraints->valid_ops has
+		 * REGULATOR_CHANGE_DRMS but there are no valid modes listed.
+		 * That's not really legit but we won't consider it a fatal
+		 * error here. We'll treat it as if REGULATOR_CHANGE_DRMS
+		 * wasn't set.
+		 */
+		if (!rdev->constraints->valid_modes_mask) {
+			rdev_dbg(rdev, "Can change modes; but no valid mode\n");
+			return 0;
+		}
+
 		/* get output voltage */
 		output_uV = regulator_get_voltage_rdev(rdev);