From d511e8a7e850db567cd7f633288aa96a19508e5b Mon Sep 17 00:00:00 2001 From: Douglas Anderson Date: Tue, 9 Aug 2022 14:27:45 -0700 Subject: regulator: core: Fix missing error return from regulator_bulk_get() In commit 6eabfc018e8d ("regulator: core: Allow specifying an initial load w/ the bulk API") I changed the error handling but had a subtle that caused us to always return no error even if there was an error. Fix it. Fixes: 6eabfc018e8d ("regulator: core: Allow specifying an initial load w/ the bulk API") Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20220809142738.1.I91625242f137c707bb345c51c80c5ecee02eeff3@changeid Signed-off-by: Mark Brown --- drivers/regulator/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/regulator') diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 7150b1d0159e..d8373cb04f90 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -4784,10 +4784,10 @@ int regulator_bulk_get(struct device *dev, int num_consumers, consumers[i].consumer = regulator_get(dev, consumers[i].supply); if (IS_ERR(consumers[i].consumer)) { - consumers[i].consumer = NULL; ret = dev_err_probe(dev, PTR_ERR(consumers[i].consumer), "Failed to get supply '%s'", consumers[i].supply); + consumers[i].consumer = NULL; goto err; } -- cgit v1.2.3 From c32f1ebfd26bece77141257864ed7b4720da1557 Mon Sep 17 00:00:00 2001 From: Andrew Halaney Date: Fri, 19 Aug 2022 14:43:36 -0500 Subject: regulator: core: Clean up on enable failure If regulator_enable() fails, enable_count is incremented still. A consumer, assuming no matching regulator_disable() is necessary on failure, will then get this error message upon regulator_put() since enable_count is non-zero: [ 1.277418] WARNING: CPU: 3 PID: 1 at drivers/regulator/core.c:2304 _regulator_put.part.0+0x168/0x170 The consumer could try to fix this in their driver by cleaning up on error from regulator_enable() (i.e. call regulator_disable()), but that results in the following since regulator_enable() failed and didn't increment user_count: [ 1.258112] unbalanced disables for vreg_l17c [ 1.262606] WARNING: CPU: 4 PID: 1 at drivers/regulator/core.c:2899 _regulator_disable+0xd4/0x190 Fix this by decrementing enable_count upon failure to enable. With this in place, just the reason for failure to enable is printed as expected and developers can focus on the root cause of their issue instead of thinking their usage of the regulator consumer api is incorrect. For example, in my case: [ 1.240426] vreg_l17c: invalid input voltage found Fixes: 5451781dadf8 ("regulator: core: Only count load for enabled consumers") Signed-off-by: Andrew Halaney Reviewed-by: Douglas Anderson Reviewed-by: Brian Masney Link: https://lore.kernel.org/r/20220819194336.382740-1-ahalaney@redhat.com Signed-off-by: Mark Brown --- drivers/regulator/core.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) (limited to 'drivers/regulator') diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 7150b1d0159e..8851695879a7 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -2733,13 +2733,18 @@ static int _regulator_do_enable(struct regulator_dev *rdev) */ static int _regulator_handle_consumer_enable(struct regulator *regulator) { + int ret; struct regulator_dev *rdev = regulator->rdev; lockdep_assert_held_once(&rdev->mutex.base); regulator->enable_count++; - if (regulator->uA_load && regulator->enable_count == 1) - return drms_uA_update(rdev); + if (regulator->uA_load && regulator->enable_count == 1) { + ret = drms_uA_update(rdev); + if (ret) + regulator->enable_count--; + return ret; + } return 0; } -- cgit v1.2.3 From 78e1e867f44e6bdc72c0e6a2609a3407642fb30b Mon Sep 17 00:00:00 2001 From: Xiaolei Wang Date: Thu, 25 Aug 2022 19:19:22 +0800 Subject: regulator: pfuze100: Fix the global-out-of-bounds access in pfuze100_regulator_probe() The pfuze_chip::regulator_descs is an array of size PFUZE100_MAX_REGULATOR, the pfuze_chip::pfuze_regulators is the pointer to the real regulators of a specific device. The number of real regulator is supposed to be less than the PFUZE100_MAX_REGULATOR, so we should use the size of 'regulator_num * sizeof(struct pfuze_regulator)' in memcpy(). This fixes the out of bounds access bug reported by KASAN. Signed-off-by: Xiaolei Wang Link: https://lore.kernel.org/r/20220825111922.1368055-1-xiaolei.wang@windriver.com Signed-off-by: Mark Brown --- drivers/regulator/pfuze100-regulator.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/regulator') diff --git a/drivers/regulator/pfuze100-regulator.c b/drivers/regulator/pfuze100-regulator.c index 6b617024a67d..d899d6e98fb8 100644 --- a/drivers/regulator/pfuze100-regulator.c +++ b/drivers/regulator/pfuze100-regulator.c @@ -766,7 +766,7 @@ static int pfuze100_regulator_probe(struct i2c_client *client, ((pfuze_chip->chip_id == PFUZE3000) ? "3000" : "3001")))); memcpy(pfuze_chip->regulator_descs, pfuze_chip->pfuze_regulators, - sizeof(pfuze_chip->regulator_descs)); + regulator_num * sizeof(struct pfuze_regulator)); ret = pfuze_parse_regulators_dt(pfuze_chip); if (ret) -- cgit v1.2.3