linux-toradex.git/drivers/regulator/core.c, branch v6.0-rc2

regulator: core: Fix missing error return from regulator_bulk_get()

2022-08-10T13:52:07+00:00

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

regulator: Consumer load management improvements

2022-07-27T23:01:30+00:00

Merge series from Douglas Anderson :

The main goal of this series is to make a small dent in cleaning up
the way we deal with regulator loads. The idea is to add some extra
functionality to the regulator "bulk" API so that consumers can
specify the load using that.

regulator: core: Allow specifying an initial load w/ the bulk API

2022-07-27T12:47:29+00:00

There are a number of drivers that follow a pattern that looks like
this:
1. Use the regulator bulk API to get a bunch of regulators.
2. Set the load on each of the regulators to use whenever the
   regulators are enabled.

Let's make this easier by just allowing the drivers to pass the load
in.

As part of this change we need to move the error printing in
regulator_bulk_get() around; let's switch to the new dev_err_probe()
to simplify it.

Signed-off-by: Douglas Anderson 
Link: https://lore.kernel.org/r/20220726103631.v2.4.Ie85f68215ada39f502a96dcb8a1f3ad977e3f68a@changeid
Signed-off-by: Mark Brown

regulator: core: Fix off-on-delay-us for always-on/boot-on regulators

2022-07-19T17:47:19+00:00

Regulators marked with "regulator-always-on" or "regulator-boot-on"
as well as an "off-on-delay-us", may run into cycling issues that are
hard to detect.

This is caused by the "last_off" state not being initialized in this
case.

Fix the "last_off" initialization by setting it to the current kernel
time upon initialization, regardless of always_on/boot_on state.

Signed-off-by: Christian Kohlschütter 
Link: https://lore.kernel.org/r/FAFD5B39-E9C4-47C7-ACF1-2A04CD59758D@kohlschutter.com
Signed-off-by: Mark Brown

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

2022-05-17T15:59:05+00:00

regulator: core: Fix enable_count imbalance with EXCLUSIVE_GET

2022-05-05T14:13:06+00:00

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:26+00:00

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:06+00:00

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:05+00:00

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:07+00:00

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