| Message ID | 20190111094552.7379-3-lokeshvutla@ti.com |
|---|---|
| State | Accepted |
| Delegated to: | Simon Glass |
| Headers | show |
| Series | Introduce regulator_set_enable_if_allowed() | expand |
On Fri, 11 Jan 2019 at 02:46, Lokesh Vutla <lokeshvutla@ti.com> wrote: > > regulator_set_enable() api throws an error in the following three cases: > - when requested to disable an always-on regulator > - when set_enable() ops not provided by regulator driver > - when enabling is actually failed.(Error returned by the regulator driver) > > Sometimes consumer drivers doesn't want to track the first two scenarios > and just need to worry about the case where enabling is actually failed. > But it is also a good practice to have an error value returned in the > first two cases. > > So introduce an api regulator_set_enable_if_allowed() which ignores the > first two error cases and returns an error as given by regulator driver. > Consumer drivers can use this api need not worry about the first two > error conditions. > > Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> > --- > drivers/power/regulator/regulator-uclass.c | 11 +++++++++++ > include/power/regulator.h | 11 +++++++++++ > test/dm/regulator.c | 21 +++++++++++++++++++++ > 3 files changed, 43 insertions(+) Reviewed-by: Simon Glass <sjg@chromium.org>
On Fri, 11 Jan 2019 at 02:46, Lokesh Vutla <lokeshvutla@ti.com> wrote: > > regulator_set_enable() api throws an error in the following three cases: > - when requested to disable an always-on regulator > - when set_enable() ops not provided by regulator driver > - when enabling is actually failed.(Error returned by the regulator driver) > > Sometimes consumer drivers doesn't want to track the first two scenarios > and just need to worry about the case where enabling is actually failed. > But it is also a good practice to have an error value returned in the > first two cases. > > So introduce an api regulator_set_enable_if_allowed() which ignores the > first two error cases and returns an error as given by regulator driver. > Consumer drivers can use this api need not worry about the first two > error conditions. > > Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> > --- > drivers/power/regulator/regulator-uclass.c | 11 +++++++++++ > include/power/regulator.h | 11 +++++++++++ > test/dm/regulator.c | 21 +++++++++++++++++++++ > 3 files changed, 43 insertions(+) Reviewed-by: Simon Glass <sjg@chromium.org> Applied to u-boot-dm, thanks!
diff --git a/drivers/power/regulator/regulator-uclass.c b/drivers/power/regulator/regulator-uclass.c index 4511625ff2..6f355b969a 100644 --- a/drivers/power/regulator/regulator-uclass.c +++ b/drivers/power/regulator/regulator-uclass.c @@ -118,6 +118,17 @@ int regulator_set_enable(struct udevice *dev, bool enable) return ops->set_enable(dev, enable); } +int regulator_set_enable_if_allowed(struct udevice *dev, bool enable) +{ + int ret; + + ret = regulator_set_enable(dev, enable); + if (ret == -ENOSYS || ret == -EACCES) + return 0; + + return ret; +} + int regulator_get_mode(struct udevice *dev) { const struct dm_regulator_ops *ops = dev_get_driver_ops(dev); diff --git a/include/power/regulator.h b/include/power/regulator.h index 5318ab3ace..314160a894 100644 --- a/include/power/regulator.h +++ b/include/power/regulator.h @@ -303,6 +303,17 @@ int regulator_get_enable(struct udevice *dev); */ int regulator_set_enable(struct udevice *dev, bool enable); +/** + * regulator_set_enable_if_allowed: set regulator enable state if allowed by + * regulator + * + * @dev - pointer to the regulator device + * @enable - set true or false + * @return - 0 on success or if enabling is not supported + * -errno val if fails. + */ +int regulator_set_enable_if_allowed(struct udevice *dev, bool enable); + /** * regulator_get_mode: get active operation mode id of a given regulator * diff --git a/test/dm/regulator.c b/test/dm/regulator.c index 5d11e946b2..e510539542 100644 --- a/test/dm/regulator.c +++ b/test/dm/regulator.c @@ -175,6 +175,27 @@ static int dm_test_power_regulator_set_get_enable(struct unit_test_state *uts) } DM_TEST(dm_test_power_regulator_set_get_enable, DM_TESTF_SCAN_FDT); +/* Test regulator set and get enable if allowed method */ +static +int dm_test_power_regulator_set_enable_if_allowed(struct unit_test_state *uts) +{ + const char *platname; + struct udevice *dev, *dev_autoset; + bool val_set = false; + + /* Get BUCK1 - always on regulator */ + platname = regulator_names[BUCK1][PLATNAME]; + ut_assertok(regulator_autoset_by_name(platname, &dev_autoset)); + ut_assertok(regulator_get_by_platname(platname, &dev)); + + /* Try disabling always-on regulator */ + ut_assertok(regulator_set_enable_if_allowed(dev, val_set)); + ut_asserteq(regulator_get_enable(dev), !val_set); + + return 0; +} +DM_TEST(dm_test_power_regulator_set_enable_if_allowed, DM_TESTF_SCAN_FDT); + /* Test regulator set and get mode method */ static int dm_test_power_regulator_set_get_mode(struct unit_test_state *uts) {
regulator_set_enable() api throws an error in the following three cases: - when requested to disable an always-on regulator - when set_enable() ops not provided by regulator driver - when enabling is actually failed.(Error returned by the regulator driver) Sometimes consumer drivers doesn't want to track the first two scenarios and just need to worry about the case where enabling is actually failed. But it is also a good practice to have an error value returned in the first two cases. So introduce an api regulator_set_enable_if_allowed() which ignores the first two error cases and returns an error as given by regulator driver. Consumer drivers can use this api need not worry about the first two error conditions. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> --- drivers/power/regulator/regulator-uclass.c | 11 +++++++++++ include/power/regulator.h | 11 +++++++++++ test/dm/regulator.c | 21 +++++++++++++++++++++ 3 files changed, 43 insertions(+)