kernel.git/drivers/regulator/core.c, branch linux-5.19.y

regulator: core: Prevent integer underflow

2022-10-24T07:58:13Z

[ Upstream commit 8d8e16592022c9650df8aedfe6552ed478d7135b ] By using a ratio of delay to poll_enabled_time that is not integer time_remaining underflows and does not exit the loop as expected. As delay could be derived from DT and poll_enabled_time is defined in the driver this can easily happen. Use a signed iterator to make sure that the loop exits once the remaining time is negative. Signed-off-by: Patrick Rudolph Link: https://lore.kernel.org/r/20220909125954.577669-1-patrick.rudolph@9elements.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: core: Clean up on enable failure

2022-09-15T08:47:13Z

[ Upstream commit c32f1ebfd26bece77141257864ed7b4720da1557 ] 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 Signed-off-by: Sasha Levin

Merge remote-tracking branch 'regulator/for-5.19' into regulator-next

2022-05-17T15:59:05Z

regulator: core: Fix enable_count imbalance with EXCLUSIVE_GET

2022-05-05T14:13:06Z

Since the introduction of regulator->enable_count, a driver that did an exclusive get on an already-enabled regulator would end up with enable_count initialized to 0 but rdev->use_count initialized to 1. With that starting point the regulator is effectively stuck enabled, because if the driver attempted to disable it it would fail the enable_count underflow check in _regulator_handle_consumer_disable(). The EXCLUSIVE_GET path in _regulator_get() now initializes enable_count along with rdev->use_count so that the regulator can be disabled without underflowing the former. Signed-off-by: Zev Weiss Fixes: 5451781dadf85 ("regulator: core: Only count load for enabled consumers") Link: https://lore.kernel.org/r/20220505043152.12933-1-zev@bewilderbeest.net Signed-off-by: Mark Brown

regulator: core: Add error flags to sysfs attributes

2022-05-04T14:31:26Z

If a regulator provides a get_error_flags() operation, its sysfs attributes will now include an entry for each defined REGULATOR_ERROR_* flag. Signed-off-by: Zev Weiss Link: https://lore.kernel.org/r/20220504065252.6955-3-zev@bewilderbeest.net Signed-off-by: Mark Brown

regulator: core: Sleep (not delay) in set_voltage()

2022-04-21T13:18:06Z

These delays can be relatively large (e.g., hundreds of microseconds to several milliseconds on RK3399 Gru systems). Per Documentation/timers/timers-howto.rst, that should usually use a sleeping delay. Let's use the existing regulator delay helper to handle both large and small delays appropriately. This avoids burning a bunch of CPU time and hurting scheduling latencies when hitting regulators a lot (e.g., during cpufreq). The sleep vs. delay issue choice has been made differently over time -- early versions of RK3399 Gru PWM-regulator support used usleep_range() in pwm-regulator.c. More of this got moved into the regulator core, in commits like: 73e705bf81ce regulator: core: Add set_voltage_time op At the same time, the sleep turned into a delay. It's OK to sleep in _regulator_do_set_voltage(), as we aren't in an atomic context. (All our callers grab various mutexes already.) I avoid using fsleep() because it uses a usleep_range() of [N to N*2], and usleep_range() very commonly biases to the high end of the range. We don't want to double the expected delay, especially for long delays. Signed-off-by: Brian Norris Reviewed-by: Matthias Kaehlcke Link: https://lore.kernel.org/r/20220420141511.v2.2.If0fc61a894f537b052ca41572aff098cf8e7e673@changeid Signed-off-by: Mark Brown

regulator: core: Rename _regulator_enable_delay()

2022-04-21T13:18:05Z

I want to use it in other contexts besides _regulator_do_enable(). Signed-off-by: Brian Norris Link: https://lore.kernel.org/r/20220420141511.v2.1.I31ef0014c9597d53722ab513890f839f357fdfb3@changeid Signed-off-by: Mark Brown

regulator: Flag uncontrollable regulators as always_on

2022-04-04T07:51:07Z

While we currently assume that regulators with no control available are just uncontionally enabled this isn't always as clearly displayed to users as is desirable, for example the code for disabling unused regulators will log that it is about to disable them. Clean this up a bit by setting always_on during constraint evaluation if we have no available mechanism for controlling the regualtor so things that check the constraint will do the right thing. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20220325144637.1543496-1-broonie@kernel.org Signed-off-by: Mark Brown

regulator: core: fix false positive in regulator_late_cleanup()

2022-02-08T13:37:48Z

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 Link: https://lore.kernel.org/r/20220208084645.8686-1-oliver.barta@aptiv.com Signed-off-by: Mark Brown

Merge tag 'regulator-v5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator

2021-11-02T02:04:47Z

Pull regulator updates from Mark Brown: "Thanks to the removal of the unused TPS80021 driver the regulator updates for this cycle actually have a negative diffstat. Otherwise it's been quite a quiet release, lots of fixes and small improvements with the biggest individual changes being several conversions of DT bindings to YAML format" * tag 'regulator-v5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (34 commits) regulator: Don't error out fixed regulator in regulator_sync_voltage() regulator: tps80031: Remove driver regulator: Fix SY7636A breakage regulator: uniphier: Add binding for NX1 SoC regulator: uniphier: Add USB-VBUS compatible string for NX1 SoC regulator: qcom,rpmh: Add compatible for PM6350 regulator: qcom-rpmh: Add PM6350 regulators regulator: sy7636a: Remove requirement on sy7636a mfd regulator: tps62360: replacing legacy gpio interface for gpiod regulator: lp872x: Remove lp872x_dvs_state regulator: lp872x: replacing legacy gpio interface for gpiod regulator: dt-bindings: samsung,s5m8767: convert to dtschema regulator: dt-bindings: samsung,s2mpa01: convert to dtschema regulator: dt-bindings: samsung,s2m: convert to dtschema dt-bindings: clock: samsung,s2mps11: convert to dtschema regulator: dt-bindings: samsung,s5m8767: correct s5m8767,pmic-buck-default-dvs-idx property regulator: s5m8767: do not use reset value as DVS voltage if GPIO DVS is disabled regulator: dt-bindings: maxim,max8973: convert to dtschema regulator: dt-bindings: maxim,max8997: convert to dtschema regulator: dt-bindings: maxim,max8952: convert to dtschema ...