The generic voltage balancer doesn't work correctly if one of regulator
couples turns off. Currently there are no users in kernel for that case,
although let's explicitly show that this case is unsupported for those who
will try to use that feature.

Link: https://lore.kernel.org/linux-samsung-soc/20191008170503.yd6GscYPLxjgrXqDuCO7AJc6i6egNZGJkVWHLlCxvA4@z/Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20191025002240.25288-2-digetx@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20191009150203.8052-1-yuehaibing@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>

Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20191009150138.11640-1-yuehaibing@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>

The sleep flag bit decides the mode for BUCK_MODE_MANUAL case, simplify
the logic as the result is the same.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Reviewed-by: NAdam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/20191007115009.25672-2-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

The implement is exactly the same as rk808_set_suspend_voltage, so just
use rk808_set_suspend_voltage instead.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20191008010628.8513-3-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

The default in rk817_set_ramp_delay is 25MV rather than 10MV.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20191008010628.8513-2-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

These regulator_ops variables never need to be modified, make them const so
compiler can put them to .rodata.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20191008010628.8513-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

gpiod_get_from_of_node() is being retired in favor of
fwnode_gpiod_get_index(), that behaves similar to gpiod_get_index(),
but can work with arbitrary firmware node. It will also be able to
support secondary software nodes.

Let's switch this driver over.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20191004231017.130290-8-dmitry.torokhov@gmail.comReviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

devm_fwnode_get_index_gpiod_from_child() is going away as the name is
too unwieldy, let's switch to using the new devm_fwnode_gpiod_get().

Note that we no longer need to check for NULL as devm_fwnode_gpiod_get()
will return -ENOENT if GPIO is missing.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20191004231017.130290-7-dmitry.torokhov@gmail.comReviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

devm_gpiod_get_from_of_node() is being retired in favor of
devm_fwnode_gpiod_get_index(), that behaves similar to
devm_gpiod_get_index(), but can work with arbitrary firmware node. It
will also be able to support secondary software nodes.

Let's switch this driver over.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NAdam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/20191004231017.130290-6-dmitry.torokhov@gmail.comReviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

devm_gpiod_get_from_of_node() is being retired in favor of
devm_fwnode_gpiod_get_index(), that behaves similar to
devm_gpiod_get_index(), but can work with arbitrary firmware node. It
will also be able to support secondary software nodes.

Let's switch this driver over.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20191004231017.130290-5-dmitry.torokhov@gmail.comReviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

devm_gpiod_get_from_of_node() is being retired in favor of
devm_fwnode_gpiod_get_index(), that behaves similar to
devm_gpiod_get_index(), but can work with arbitrary firmware node. It
will also be able to support secondary software nodes.

Let's switch this driver over.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20191004231017.130290-4-dmitry.torokhov@gmail.comReviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

devm_gpiod_get_from_of_node() is being retired in favor of
[devm_]fwnode_gpiod_get_index(), that behaves similar to
devm_gpiod_get_index(), but can work with arbitrary firmware node. It
will also be able to support secondary software nodes.

Let's switch this driver over.

Note that now that we have a good non-devm API for getting GPIO from
arbitrary firmware node, there is no reason to use devm API here as
regulator core takes care of managing lifetime of "enable" GPIO and we
were immediately detaching requested GPIO from devm anyway.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20191004231017.130290-3-dmitry.torokhov@gmail.comReviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

devm_gpiod_get_from_of_node() is being retired in favor of
devm_fwnode_gpiod_get_index(), that behaves similar to
devm_gpiod_get_index(), but can work with arbitrary firmware node. It
will also be able to support secondary software nodes.

Let's switch this driver over.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20191004231017.130290-2-dmitry.torokhov@gmail.comReviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Only the desc field is really used, so use struct regulator_desc instead.
Then struct pbias_regulator_data can be removed.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20191007114320.20977-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

It's more straightforward to use for statement here.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NSteve Twiss <stwiss.opensource@diasemi.com>
Link: https://lore.kernel.org/r/20191007115009.25672-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add support for PM6150/PM6150L regulators. This ensures
that consumers are able to modify the physical state of PMIC
regulators.
Signed-off-by: NKiran Gunda <kgunda@codeaurora.org>
Link: https://lore.kernel.org/r/1570183734-30706-3-git-send-email-kgunda@codeaurora.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Inside function max8907_regulator_probe(), variable val could
be uninitialized if regmap_read() fails. However, val is used
later in the if statement to decide the content written to
"pmic", which is potentially unsafe.
Signed-off-by: NYizhuo <yzhai003@ucr.edu>
Link: https://lore.kernel.org/r/20191003175813.16415-1-yzhai003@ucr.eduSigned-off-by: NMark Brown <broonie@kernel.org>

Correct the PMIC5 BoB min voltage from 0.3V to 3V. Also correct
the voltage selector accordingly.
Signed-off-by: NKiran Gunda <kgunda@codeaurora.org>
Link: https://lore.kernel.org/r/1570184215-5355-1-git-send-email-kgunda@codeaurora.orgSigned-off-by: NMark Brown <broonie@kernel.org>

This fixes device probing when built as a module
Signed-off-by: NGuido Günther <agx@sigxcpu.org>
Link: https://lore.kernel.org/r/46ce3400e227dd88d51486c02a6152c9ec52acbb.1569875042.git.agx@sigxcpu.orgSigned-off-by: NMark Brown <broonie@kernel.org>

In function pfuze100_regulator_probe(), variable "val" could be
initialized if regmap_read() fails. However, "val" is used to
decide the control flow later in the if statement, which is
potentially unsafe.
Signed-off-by: NYizhuo <yzhai003@ucr.edu>
Link: https://lore.kernel.org/r/20190929170957.14775-1-yzhai003@ucr.eduSigned-off-by: NMark Brown <broonie@kernel.org>

The VDDCORE regulator takes a good length of time to discharge down, so
add an on_off_delay to ensure DCVDD is removed before it is powered on
again.
Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20191001132017.1785-1-ckeepax@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

drivers/regulator/pcap-regulator.c:89:27: warning:
 SW3_table defined but not used [-Wunused-const-variable=]

It is never used, so can be removed.
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20190928085540.45332-1-yuehaibing@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>

The sleep flag bit decides the mode for BUCK_MODE_MANUAL case, simplify
the logic as the result is the same.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Reviewed-by: NAdam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/20190926055128.23434-2-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

Use of_device_get_match_data to simplify the code a bit.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20190925101256.19030-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

This Power IC is used in combination with various PMIC combos,
generally found on boards with MSM8992, MSM8994, MSM8996,
MSM8956, MSM8976 and others, usually at address 0x5 on the SPMI
bus, and its usual usage is to provide power to the GPU and/or
to the CPU clusters (APC0/APC1).
Signed-off-by: NAngelo G. Del Regno <kholk11@gmail.com>
Link: https://lore.kernel.org/r/20190921095043.62593-6-kholk11@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The PM8950 provides 6 SMPS regulators, of which 5 HFSMPS
and one FTSMPS2.5 (s5), and 23 LDOs.
Add these to the RPM regulator driver.
Signed-off-by: NAngelo G. Del Regno <kholk11@gmail.com>
Link: https://lore.kernel.org/r/20190921095043.62593-4-kholk11@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The PM8950 has 5 HFSMPS, 1 FTSMPS2.5 (s5, controlling APC voltage)
and 23 LDO regulators.
Add the configuration for this chip.
Signed-off-by: NAngelo G. Del Regno <kholk11@gmail.com>
Link: https://lore.kernel.org/r/20190921095043.62593-3-kholk11@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

ti_abb_wait_txdone() may return -ETIMEDOUT when ti_abb_check_txdone()
returns true in the latest iteration of the while loop because the timeout
value is abb->settling_time + 1. Similarly, ti_abb_clear_all_txdone() may
return -ETIMEDOUT when ti_abb_check_txdone() returns false in the latest
iteration of the while loop. Fix it.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NNishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20190929095848.21960-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

Currently the suspend reg_field maps to the pmic voltage selection bits
and is used during suspend_enabe/disable() and during get_mode(). This
seems to be wrong for both use cases.

Use case one (suspend_enabe/disable):
Those callbacks are used to mark a regulator device as enabled/disabled
during suspend. Marking the regulator enabled during suspend is done by
the LDOx_CONF/BUCKx_CONF bit within the LDOx_CONT/BUCKx_CONT registers.
Setting this bit tells the DA9062 PMIC state machine to keep the
regulator on in POWERDOWN mode and switch to suspend voltage.

Use case two (get_mode):
The get_mode callback is used to retrieve the active mode state. Since
the regulator-setting-A is used for the active state and
regulator-setting-B for the suspend state there is no need to check
which regulator setting is active.

Fixes: 4068e518 ("regulator: da9062: DA9062 regulator driver")
Signed-off-by: NMarco Felsch <m.felsch@pengutronix.de>
Reviewed-by: NAdam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/20190917124246.11732-2-m.felsch@pengutronix.deSigned-off-by: NMark Brown <broonie@kernel.org>

Use of_device_get_match_data which has NULL test for match before
dereference match->data. Add NULL test for drvtype so it still works
for fixed_voltage_ops when !CONFIG_OF.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Reviewed-by: NPhilippe Schenker <philippe.schenker@toradex.com>
Link: https://lore.kernel.org/r/20190922022928.28355-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

Sometimes it can happen that the regulator_of_get_init_data() can't
retrieve the config due to a not probed device the regulator depends on.
Fix that by checking the return value of of_parse_cb() and return
EPROBE_DEFER in such cases.
Signed-off-by: NMarco Felsch <m.felsch@pengutronix.de>
Link: https://lore.kernel.org/r/20190917154021.14693-4-m.felsch@pengutronix.deSigned-off-by: NMark Brown <broonie@kernel.org>

Currently the regulator-suspend-min/max-microvolt must be within the
root regulator node but the dt-bindings specifies it as subnode
properties for the regulator-state-[mem/disk/standby] node. The only DT
using this bindings currently is the at91-sama5d2_xplained.dts and this
DT uses it correctly. I don't know if it isn't tested but it can't work
without this fix.

Fixes: f7efad10 ("regulator: add PM suspend and resume hooks")
Signed-off-by: NMarco Felsch <m.felsch@pengutronix.de>
Link: https://lore.kernel.org/r/20190917154021.14693-3-m.felsch@pengutronix.deSigned-off-by: NMark Brown <broonie@kernel.org>

regulator_uV_show() is missing error handling if regulator_get_voltage_rdev()
returns negative values. Instead it prints the errno as a string, e.g. -EINVAL
as "-22" which could be interpreted as -22 µV.

We also do not need to hold the lock while converting the integer to a string.
Reported-by: NAdam Ford <aford173@gmail.com>
Signed-off-by: NH. Nikolaus Schaller <hns@goldelico.com>
Tested-by: NAdam Ford <aford173@gmail.com>
Link: https://lore.kernel.org/r/f37f2a1276efcb34cf3b7f1a25481175be048806.1568143348.git.hns@goldelico.comSigned-off-by: NMark Brown <broonie@kernel.org>

This fixes 11da04af, as devm_gpiod_get_from_of_node() does
not do translation "con-id" -> "con-id-gpios" that our bindings expects,
and therefore it was wrong to change connection ID to be simply "enable"
when moving to using devm_gpiod_get_from_of_node().

Fixes: 11da04af ("regulator: da9211: Pass descriptors instead of GPIO numbers")
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20190910170246.GA56792@dtor-wsSigned-off-by: NMark Brown <broonie@kernel.org>

This fixes 96392c3d, as devm_gpiod_get_from_of_node() does
not do translation "con-id" -> "con-id-gpios" that our bindings expects,
and therefore it was wrong to change connection ID to be simply
"maxim,ena" when moving to using devm_gpiod_get_from_of_node().

Fixes: 96392c3d ("regulator: max77686: Pass descriptor instead of GPIO number")
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20190910170050.GA55530@dtor-wsSigned-off-by: NMark Brown <broonie@kernel.org>

Pro5 SoC has same scheme of USB3 VBUS as Pro4, so the data for Pro5 is
equivalent to Pro4.
Signed-off-by: NKunihiko Hayashi <hayashi.kunihiko@socionext.com>
Link: https://lore.kernel.org/r/1568080304-1572-1-git-send-email-hayashi.kunihiko@socionext.comSigned-off-by: NMark Brown <broonie@kernel.org>

This commit adds the possibility to choose the compatible
"regulator-fixed-clock" in devicetree.

This is a special regulator-fixed that has to have a clock, from which
the regulator gets switched on and off.
Signed-off-by: NPhilippe Schenker <philippe.schenker@toradex.com>
Link: https://lore.kernel.org/r/20190910062103.39641-2-philippe.schenker@toradex.comSigned-off-by: NMark Brown <broonie@kernel.org>

The value under 's2mps11->ext_control_gpiod[i]' is assigned to local
variable and used in probe in one place before.  Use it consistently
later so code will be easier to read.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20190909155723.24734-1-krzk@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Use rdev->regmap/&rdev->dev instead of lp87565->regmap/lp87565->dev.
In additional, the lp87565->dev actually is the parent mfd device,
so the dev_err message is misleading here with lp87565->dev.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20190908035720.17748-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>