This patch fix the below build error:
drivers/regulator/mt6311-regulator.c:111: undefined reference to `__devm_regmap_init_i2c'
Signed-off-by: NHenry Chen <henryc.chen@mediatek.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

Since we need to read voltages of parents as part of setting supply
voltages we need to be able to do get_voltage() internally without
taking locks so reorganize the locking to take locks on the full tree on
entry rather than as we recurse when called externally.
Reported-by: NJohn Stultz <john.stultz@linaro.org>
Tested-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

An spi_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Acked-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The driver depends on MFD_STW481X but there isn't a build dependency so
it's a good idea to allow the driver to always be built when the
COMPILE_TEST option is enabled.

That way, the driver can be built with a config generated by make
allyesconfig and check if a patch would break the build.
Signed-off-by: NLuis de Bethencourt <luisbg@osg.samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The set_load() op deals with uA while the SMD packets used mA, so
convert as we're building the packet.
Signed-off-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Until now changing the voltage of a regulator only ever effected the
regulator itself, but never its supplies. It's a common pattern though
to put LDO regulators behind switching regulators. The switching
regulators efficiently drop the input voltage but have a high ripple on
their output. The output is then cleaned up by the LDOs. For higher
energy efficiency the voltage drop at the LDOs should be minimized. For
this scenario we need to propagate the voltage change to the supply
regulators. Another scenario where voltage propagation is desired is
a regulator which only consists of a switch and thus cannot regulate
voltages itself. In this case we can pass setting voltages to the
supply.

This patch adds support for voltage propagation. We do voltage
propagation when the current regulator has a minimum dropout voltage
specified or if the current regulator lacks a get_voltage operation
(indicating it's a switch and not a regulator).

Changing the supply voltage must be done carefully. When we are
increasing the current regulators output we must first increase the
supply voltage and then the regulator itself. When we are decreasing the
current regulators voltage we must decrease the supply voltage after
changing the current regulators voltage.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

_regulator_call_set_voltage has code to translate a minimum/maximum
voltage pair into a selector. This code is useful for others aswell,
so create a regulator_map_voltage function.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

The anatop regulators are SoC internal LDO regulators usually supplied
by an external PMIC. This patch adds support for specifying the supply
from the device tree using the vin-supply property.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

The unlocked version will be needed when we start propagating voltage
changes to the supply regulators.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

The LDO1 driver is using the arizona_of_get_named_gpio helper function
which will return 0 if an error was encountered whilst parsing the GPIO,
as under the pdata scheme 0 was not being treated as a valid GPIO.
However, since the regulator framework was expanded to allow the use of
GPIO 0 this causes us to attempt to register GPIO 0 when we encountered
an error parsing the device tree.

This patch uses of_get_named_gpio directly and sets the
ena_gpio_initialized flag based on the return value.

Fixes: 1de3821a ("regulator: Set ena_gpio_initialized in regulator drivers")
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Provide an additional case entry for DA9053_BC in the find_regulator_info()
function in order to support BC type silicon for the DA9053 device.
Signed-off-by: NSteve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The DC1SW and DC5LDO regulators in the AXP22X are internally chained
to DCDC1 and DCDC5, hence the names. The original bindings used the
parent regulator names for the supply regulator property.

Since they are internally connected, the relationship should not be
represented in the device tree, but handled internally by the driver.

This patch has the driver remember the regulator names for the parent
DCDC1/DCDC5, and use them as supply names for DC1SW/DC5LDO.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

This patch modifies tps6105x and associated function driver to use regmap
instead of operating directly on i2c.
Signed-off-by: NDenis Grigoryev <grigoryev@fastwel.ru>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

For the step-down DC/DC regulators, the output voltage is
selectable by setting VSEL pin that when VSEL is low, output
voltage is programmed by VSET1[] bits, and when VSEL is high,
output voltage is programmed by VSET2[] bits.

The DT property "active-semi,vsel-high" is used to specify
the VSEL pin at high on the board.
Signed-off-by: NWenyou Yang <wenyou.yang@atmel.com>
Reviewed-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Signed-off-by: NRichard Fitzgerald <rf@opensource.wolfsonmicro.com>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The unlocked version will be needed when we start propagating voltage
changes to the supply regulators.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Each regulator_dev is locked with its own mutex. This is fine as long
as only one regulator_dev is locked, but makes lockdep unhappy when we
have to walk up the supply chain like it can happen in
regulator_get_voltage:

regulator_get_voltage ->
 mutex_lock(&regulator->rdev->mutex) ->
_regulator_get_voltage(regulator->rdev) ->
regulator_get_voltage(rdev->supply) ->
mutex_lock(&regulator->rdev->mutex);

This causes lockdep to issue a possible deadlock warning.

There are at least two ways to work around this:

- We can always lock the whole supply chain using the functions
  introduced with this patch.
- We could store the current voltage in struct regulator_rdev so
  that we do not have to walk up the supply chain for the
  _regulator_get_voltage case.

Anyway, regulator_lock_supply/regulator_unlock_supply will be needed
once we allow regulator_set_voltage to optimize the supply voltages.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

When resolving regulator-regulator supplies we ignore probe deferral
returns from regulator_dev_lookup() (such as are generated for DT when
we can see a supply is registered) and just fall back to the dummy
regulator if there are full constraints (as is the case for DT).  This
means that probe deferral is broken for DT systems, fix that by paying
attention to -EPROBE_DEFER return codes like we do -ENODEV.

A further patch will simplify this further, this is a minimal fix for
the specific issue.

Fixes: 9f7e25ed (regulator: core: Handle full constraints systems when resolving supplies)
Reported-by: NSascha Hauer <s.hauer@pengutronix.de>
Tested-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NMark Brown <broonnie@kernel.org>
Cc: stable@vger.kernel.org

The enable bit indexes for DCDC4 and DCDC5 regulators are off by 1.

We haven't run into any problems with this since either the regulators
aren't defined in the DT and aren't used, or all the DCDC regulators
have the "always-on" property set, as they are almost always used
for system critical loads.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

Implement the ->enable(), ->disable() and ->is_enabled methods and remove
the PWM call in ->set_voltage_sel().
This is particularly important for critical regulators tagged as always-on,
because not claiming the PWM (and its dependencies) might lead to
unpredictable behavior (like a system hang because the PWM clk is only
claimed when the PWM device is enabled).
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

As we are already registering a device with regulator_class for each
regulator device, regulator_list is redundant and can be replaced with
calls to class_find_device() and class_for_each_device().
Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add device tree based initialization support for tps65023 regulators.
Therefore add macros for regulator definition setting of_match and
regulators_node members. Add initialization of regulator_desc data
using these macros. Remove old regulator_desc initialization.

Add device tree binding document for tps65023 regulators.
Signed-off-by: NThomas Elste <thomas.elste@imms.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: NLuis de Bethencourt <luisbg@osg.samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: NLuis de Bethencourt <luisbg@osg.samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: NLuis de Bethencourt <luisbg@osg.samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The ret pointer passed to regulator_dev_lookup is only filled with a
valid error code if regulator_dev_lookup returned NULL. Currently
regulator_resolve_supply checks this ret value before it checks if a
regulator was returned, this can result in valid regulator lookups being
ignored.

Fixes: 6261b06d ("regulator: Defer lookup of supply to regulator_get")
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

Introduce "regulator-allow-set-load" property to make it possible to
flag in the board configuration that a regulator is allowed to have the
load requirements changed.
Signed-off-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The same error print exists 4 times in the regulator core

	<rdev>: operation not allowed

Unfortunately, seeing this in the dmesg is not very informative.
Add what type of operation is not allowed to the message so that
these errors are unique, hopefully pointing developers in the
right direction

	<rdev>: drms operation not allowed
	<rdev>: voltage operation not allowed
	<rdev>: current operation not allowed
	<rdev>: mode operation not allowed
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add missing zero to value. This will be needed when range checking
is implemented.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Acked-by: NDan Murphy <dmurphy@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

It's clearly a typo error that just creates a null statement so remove it.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

It's clearly a typo error that just creates a null statement so remove it.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add separate compatible strings for every platform and populate the
pbias register offset in the driver data.
This helps avoid depending on the dt for pbias register offset.

Also update the dt binding documentation for the new compatible
strings.
Suggested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The smd rpm structures are always in little endian, but this
driver is not capable of being used on big endian CPUs. Annotate
the little endian data members and update the code to do the
proper byte swapping.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

We were checking rdev->supply for NULL after dereferencing it. Lets
check for rdev->supply along with _regulator_is_enabled() and call
regulator_enable() only if rdev->supply is not NULL.
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

drivers/regulator/mt6311-regulator.c:169:3-8: No need to set .owner here. The core will do it.

 Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The driver has a I2C device id table that is used to create the modaliases
and already contains a "ltc3589" device id. So the modalias is unnecessary.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The driver has a I2C device id table that is used to create the modaliases
and also "ad5398-regulator" is not a supported I2C id, so it's never used.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The driver has a I2C device id table that is used to create the modaliases
and also "pfuze100-regulator" is not a supported I2C id, so is never used.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

When calling regulator_set_load, regulator_check_drms prints and returns
an error if the regulator device's flag REGULATOR_CHANGE_DRMS isn't set.
drms_uA_update, however, bails out without reporting an error.

Replace the error print with a debug level print so that we don't get
such prints when the underlying regulator doesn't support DRMS.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

If memory allocation gets failed on parsing the DT, then it returns error
'-ENOMEM' explicitly. Then, the driver exists from the _probe().
Signed-off-by: NMilo Kim <milo.kim@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>