Currently, when looking up a regulator supply, the regulator name
takes priority over the consumer mappings. As there are a lot of
regulator names that are in fairly common use (VDD, MICVDD, etc.) this
can easily lead to obtaining the wrong supply, when a system contains
two regulators that share a name.

The explicit consumer mappings contain much less ambiguity as they
specify both a name and a consumer device. As such prioritise those if
one exists and only fall back to the regulator name if there are no
matching explicit mappings.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add driver for the regulator block in the ROHM BD9571MWV-W MFD PMIC.
This block supports three voltage monitors, VD18, VD25, VD33 for the
1V8, 2V5, 3V3 voltage rails and a single voltage regulator for the
DVFS rail.
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

In preparation for sharing this driver with Madera codecs, factor out
the parts of initialization that aren't dependent on struct arizona.
Signed-off-by: NRichard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

In preparation for supporting Madera codecs, remove the dependency on
struct arizona in the regulator callbacks and struct arizona_ldo1.
Signed-off-by: NRichard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

In preparation for sharing this driver with Madera, move the pdata
for the LDO1 regulator out of struct arizona_pdata into a dedicated
pdata struct for this driver. As a result the code in
arizona_ldo1_of_get_pdata() can be made independent of struct arizona.

This patch also updates the definition of struct arizona_pdata and
the use of this pdata in mach-crag6410-module.c
Signed-off-by: NRichard Fitzgerald <rf@opensource.wolfsonmicro.com>
Acked-by: NKrzysztof Kozlowski <krzk@kernel.org>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

In preparation for sharing this driver with Madera codecs, factor out
the parts of initialization that aren't dependent on struct arizona.
Signed-off-by: NRichard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

In preparation for supporting Madera codecs, remove the dependency on
struct arizona in the regulator callbacks and struct arizona_micsupp.
Signed-off-by: NRichard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

In preparation for sharing this driver with Madera, move the pdata
for the micsupp regulator out of struct arizona_pdata into a dedicated
pdata struct for this driver. As a result the code in
arizona_micsupp_of_get_pdata() can be made independent of struct arizona.

This patch also updates the definition of struct arizona_pdata and
the use of this pdata in mach-crag6410-module.c
Signed-off-by: NRichard Fitzgerald <rf@opensource.wolfsonmicro.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The CS47L24 Arizona codec and most Madera codecs do not have a LDO1
regulator. Split the LDO1 and MICSUPP regulators into separate KConfig
options so the LDO1 is only built into the kernel if needed.
Signed-off-by: NRichard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Commit 43530b69 ("regulator: Use
regmap_read/write(), regmap_update_bits functions directly") intended
to replace working inline helper functions with standard regmap
calls.  However, it also inverted the set/clear logic of the "CORE ADJ
Allowed" bit.  That patch was clearly never tested, since without that
bit cleared, the core VDCDC1 voltage output does not react to I2C
configuration changes.

This patch fixes the issue by clearing the bit as in the original,
correct implementation.  Note for stable back porting that, due to
subsequent driver churn, this patch will not apply on every kernel
version.

Fixes: 43530b69 ("regulator: Use regmap_read/write(), regmap_update_bits functions directly")
Signed-off-by: NRichard Cochran <rcochran@linutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

For anatop regulator we must have a name accordingly. Make sure the name
is properly checked before using it to avoid a possible kernel NULL
point crash.
Signed-off-by: NDong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Rather than just not resolving the supply when there is explicitly no
supply mapping fall through and allow a dummy supply to be substituted.
This fixes issues with constant retries reported by Dong Aisheng.
Signed-off-by: NMark Brown <broonie@kernel.org>
Tested-by: NDong Aisheng <aisheng.dong@nxp.com>
Reviewed-by: NDong Aisheng <aisheng.dong@nxp.com>

When we are propagating voltage changes to parent regulators don't
bother if the parent does not have permission to change voltages.  This
simplifies error checking in the function for cases where the regulator
lacks some of the voltage operations.
Reported-by: NDong Aisheng <aisheng.dong@nxp.com>
Tested-by: NDong Aisheng <aisheng.dong@nxp.com>
Reviewed-by: NDong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Current code only allocates rdesc->n_voltages entries for vctrl->vtable.
Thus use rdesc->n_voltages instead of n_voltages in the for loop.

While at it, also switch to use devm_kcalloc instead of devm_kmalloc_array
+ __GFP_ZERO flag and fix the argument order.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

drivers/regulator/tps65132-regulator.c:274: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>
Acked-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

TPS65132_REG_CONTROL(0xFF) is the latest valid register.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Set the initial voltage selector for vddpcie in case it's disabled
by default.

This fixes the below warning:
20c8000.anatop:regulator-vddpcie: Failed to read a valid default voltage selector.
anatop_regulator: probe of 20c8000.anatop:regulator-vddpcie failed with error -22

Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Robin Gong <yibin.gong@nxp.com>
Cc: Richard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: NRichard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: NDong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add regulator driver for the device TI TPS65132 which is single
inductor - dual output power supply device. TPS65132 device is
designed to support general positive/negative driven applications
like TFT display panels.

TPS65132 regulator driver supports to enable/disable and set voltage
on its output.
Signed-off-by: NVenkat Reddy Talla <vreddytalla@nvidia.com>
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

sreg->name is only used as an intermediate assign of rdesc->name, plus
another strcmp. Since we already have rdesc->name, no need it anymore.
Signed-off-by: NDong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

sreg->name is a string, so use a more proper api to read back the string
instead of of_get_property.
Signed-off-by: NDong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Should check the return value of of_get_regulator_init_data before
using it.
Signed-off-by: NDong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The output voltage of a voltage controlled regulator can be controlled
through the voltage of another regulator. The current version of this
driver assumes that the output voltage is a linear function of the control
voltage.
Signed-off-by: NMatthias Kaehlcke <mka@chromium.org>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add a helper function regulator_set_pull_down_regmap to allow regmap
based regulators to easily enable pull down.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add a helper function regulator_set_soft_start_regmap to allow regmap
based regulators to easily enable soft start.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Some regulators (some PWM regulators) have the voltage transition
non-linear i.e. exponentially. On such cases, the settling time
for voltage transition can not be presented in the voltage-ramp-delay.

Add new property for non-linear voltage transition and handle this
in getting the voltage settling time.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The hi655x-regulator driver consumes a similarly named platform device.
Adding that to the module device table, allows modprobe to locate this
driver once the device is created.
Signed-off-by: NJeremy Linton <lintonrjeremy@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The device argument passed to of_get_regulator_init_data is used to
do some devres memory allocation. Currently the driver passes the MFD
device pointer to this function, this could result in the init_data
allocation being leaked if the regulator is unbound but the MFD isn't.

Correct this issue by correctly passing the local platform device.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The device argument passed to of_get_regulator_init_data is used to
do some devres memory allocation. Currently the driver passes the MFD
device pointer to this function, this could result in the init_data
allocation being leaked if the regulator is unbound but the MFD isn't.

Correct this issue by correctly passing the local platform device.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Commit 26988efe ("regulator: core: Allow to get voltage count and
list from parent") introduces the propagation of the parent voltage
count and list for regulators that don't provide this information
themselves. The goal is to support simple switch regulators, however as
a side effect normal continuous regulators can leak details of their
supplies and provide consumers with inconsistent information.

Limit the propagation of the voltage count and list to switch
regulators.

Fixes: 26988efe ("regulator: core: Allow to get voltage count and
  list from parent")
Signed-off-by: NMatthias Kaehlcke <mka@chromium.org>
Reviewed-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Tested-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Remove the description for the non-existing 'ret' to fix the build warning:
./drivers/regulator/core.c:1467: warning:
Excess function parameter 'ret' description in 'regulator_dev_lookup'.
The description found for the return value is: @ret: 0 on success, -ENODEV
if lookup fails permanently, -EPROBE_DEFER if lookup could succeed in the future.
Signed-off-by: NTamara Diaconita <diaconita.tamara@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This is useful for devices, which need some time to start up, to help
the drivers track how long the supply has been up already. Ie whether
it can safely talk to the HW or needs to wait.
Signed-off-by: NHarald Geyer <harald@ccbib.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Set the correct voltage select register for LDO2.
Signed-off-by: NWadim Egorov <w.egorov@phytec.de>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

It has been pointed out to me that the range for vsel = 58 is actually
dead code as this is covered by an earlier check for (min_uV >= 700000)
&& (min_uV <= 1420000) so remove that check completely.
Reported-by: NAlban Auzeill <alban.auzeill@sonarsource.com>
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The supply_name member of struct regulator can be const as we
don't change it in the regulator core. Furthermore, when we copy
the supply name we can use kstrdup_const() here to avoid a copy
if the name is in the ro data section.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Broken indenting makes code more difficult to read and brings
confusion. Fix warning reported by Smatch:
	s2mpa01.c:362 s2mpa01_pmic_probe() warn: inconsistent indenting
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Static struct regulator_ops is not modified so can be made const for
code safeness.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Static struct regulator_ops is not modified so can be made const for
code safeness.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Static struct regulator_ops is not modified so can be made const for
code safeness.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Static struct regulator_ops (except max8660_dcdc_ops) are not modified
so can be made const for code safeness.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Static struct regulator_ops is not modified so can be made const for
code safeness.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>