`cat /sys/kernel/debug/regulator/regulator_summary` ends on a deadlock
when you have a voltage controlled regulator (vctrl).

The problem is that the vctrl_get_voltage() and vctrl_set_voltage() calls the
regulator_get_voltage() and regulator_set_voltage() and that will try to lock
again the dependent regulators (the regulator supplying the control voltage).

Fix the issue by exporting the unlocked version of the regulator_get_voltage()
and regulator_set_voltage() API so drivers that need it, like the voltage
controlled regulator driver can use it.

Fixes: f8702f9e ("regulator: core: Use ww_mutex for regulators locking")
Reported-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20200116094543.2847321-1-enric.balletbo@collabora.comSigned-off-by: NMark Brown <broonie@kernel.org>

The .set_ramp_delay should be for bd70528_buck_ops only.
Setting .set_ramp_delay for for bd70528_ldo_ops causes problem because
BD70528_MASK_BUCK_RAMP (0x10) overlaps with BD70528_MASK_LDO_VOLT (0x1f).
So setting ramp_delay for LDOs may change the voltage output, fix it.

Fixes: 99ea37bd ("regulator: bd70528: Support ROHM BD70528 regulator block")
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/20200101022406.15176-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

Current code set incorrect bits when set ramp_delay for AXP20X_DCDC2,
fix it.

Fixes: d29f54df ("regulator: axp20x: add support for set_ramp_delay for AXP209")
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20191221081049.32490-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

A copy-paste error was introduced when bitmasks were converted to
macros, incorrectly setting the enable bitmask for ELDO2 to the one
for ELDO1 for the AXP22x units.

Fix it by using the correct macro.

On affected boards, ELDO1 and/or ELDO2 are used to power the camera,
which is currently unsupported.

Fixes: db4a555f ("regulator: axp20x: use defines for masks")
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20191218044720.21990-1-wens@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

platform device aliases were missing, preventing
autoloading of module.

Fixes: 811b7006 ("regulator: rn5t618: add driver for Ricoh RN5T618 regulators")
Signed-off-by: NAndreas Kemnade <andreas@kemnade.info>
Link: https://lore.kernel.org/r/20191211221600.29438-1-andreas@kemnade.infoSigned-off-by: NMark Brown <broonie@kernel.org>

We need the of_match table if we want to use the compatible string in
the pmic's child node and get the regulator driver loaded automatically.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20191210100725.11005-1-brgl@bgdev.plSigned-off-by: NMark Brown <broonie@kernel.org>

Inside machine_constraints_voltage() a loop is in charge of verifying that
each of the defined voltages are within the configured constraints and
that those constraints are in fact compatible with the available voltages'
list.

When the registered regulator happens to be defined with a wide range of
possible voltages the above O(n) loop can be costly.
Moreover since this behaviour is triggered during the registration process,
it means also that it can be easily triggered at probe time, slowing down
considerably some module loading.

On the other side if such wide range of voltage values happens to be also
continuous and without discontinuity of any kind, the above potentially
cumbersome operation is also useless.

For these reasons, avoid such .list_voltage poll loop when regulator is
described as 'continuous_voltage_range' as is, indeed, similarly already
done inside regulator_is_supported_voltage().
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20191209125239.46054-1-cristian.marussi@arm.comSigned-off-by: NMark Brown <broonie@kernel.org>

Axe a duplicated word ("property") in a warning message.
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20191203214838.9680-1-christophe.jaillet@wanadoo.frSigned-off-by: NMark Brown <broonie@kernel.org>

There are several issues with the error handling code of
the regulator_register() function:
        ret = device_register(&rdev->dev);
        if (ret != 0) {
                put_device(&rdev->dev); --> rdev released
                goto unset_supplies;
        }
...
unset_supplies:
...
        unset_regulator_supplies(rdev); --> use-after-free
...
clean:
        if (dangling_of_gpiod)
                gpiod_put(config->ena_gpiod);
        kfree(rdev);                     --> double free

We add a variable to record the failure of device_register() and
move put_device() down a bit to avoid the above issues.

Fixes: c438b9d0 ("regulator: core: Move registration of regulator device")
Signed-off-by: NWen Yang <wenyang@linux.alibaba.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/20191201030250.38074-1-wenyang@linux.alibaba.comSigned-off-by: NMark Brown <broonie@kernel.org>

This is caused by dereferencing 'rdev' after put_device() in
the _regulator_get()/_regulator_put() functions.
This patch just moves the put_device() down a bit to avoid the
issue.
Signed-off-by: NWen Yang <wenyang@linux.alibaba.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/20191124145835.25999-1-wenyang@linux.alibaba.comSigned-off-by: NMark Brown <broonie@kernel.org>

-EINVAL is not a valid return value for .of_map_mode, return
REGULATOR_MODE_INVALID instead.

Fixes: 844e7492 ("regulator: da9062: add of_map_mode support for bucks")
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20191122045154.802-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
	$ sed -e 's/^        /\t/' -i */Kconfig
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20191120133949.13996-1-krzk@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Tell the regulator framework to retrieve regulator init
data from the 'regulator' subnode, or from the parent mfd
device's platform data.

Example:

i2c0 {
	tps61052@33 {
		compatible = "ti,tps61052";
		reg = <0x33>;

		regulator {
			regulator-min-microvolt = <5000000>;
			regulator-max-microvolt = <5000000>;
			regulator-always-on;
		};
	};
};

Tree: next-20191118
Signed-off-by: NSven Van Asbroeck <TheSven73@gmail.com>
Link: https://lore.kernel.org/r/20191119154611.29625-3-TheSven73@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

This driver currently requires platform data to specify the
operational mode and regulator init data (in case of regulator
mode).

Optionally specify the operational mode by looking at the name
of the devicetree child node.

Example: put chip in regulator mode:

i2c0 {
	tps61052@33 {
		compatible = "ti,tps61052";
		reg = <0x33>;

		regulator {
                            regulator-min-microvolt = <5000000>;
                            regulator-max-microvolt = <5000000>;
                            regulator-always-on;
		};
	};
};

Tree: linux-next
Signed-off-by: NSven Van Asbroeck <TheSven73@gmail.com>
Link: https://lore.kernel.org/r/20191119154611.29625-2-TheSven73@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Fixes coccicheck warning:

drivers/regulator/vexpress-regulator.c:78:1-3: WARNING: PTR_ERR_OR_ZERO can be used
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: Nzhengbin <zhengbin13@huawei.com>
Link: https://lore.kernel.org/r/1574074762-34629-1-git-send-email-zhengbin13@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>

This patch adds DT description of da9062 buck regulator modes.
Signed-off-by: NChristoph Fritz <chf.fritz@googlemail.com>
Link: https://lore.kernel.org/r/1573652416-9848-4-git-send-email-chf.fritz@googlemail.comSigned-off-by: NMark Brown <broonie@kernel.org>

This patch adds of_map_mode support for bucks to set regulator modes
from within regulator framework.
Signed-off-by: NChristoph Fritz <chf.fritz@googlemail.com>
Signed-off-by: NChristian Hemp <c.hemp@phytec.de>
Signed-off-by: NStefan Riedmueller <s.riedmueller@phytec.de>
Link: https://lore.kernel.org/r/1573652416-9848-3-git-send-email-chf.fritz@googlemail.comSigned-off-by: NMark Brown <broonie@kernel.org>

This patch refactors buck modes into a header file so that device trees
can make use of these mode constants.

The new header filename uses da9063 because DA9063 was the earlier chip
and its driver code will want updating at some point in a similar manner.
Signed-off-by: NChristoph Fritz <chf.fritz@googlemail.com>
Link: https://lore.kernel.org/r/1573652416-9848-2-git-send-email-chf.fritz@googlemail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Set a default ramp delay value to the regulators with the worst
case value.
Signed-off-by: Npascal paillet <p.paillet@st.com>
Link: https://lore.kernel.org/r/20191113161529.27739-1-p.paillet@st.comSigned-off-by: NMark Brown <broonie@kernel.org>

Boot-on regulators are always kept on because their use_count value
is now incremented at boot time and never cleaned.

Only increment count value for alway-on regulators.
regulator_late_cleanup() is now able to power off boot-on regulators
when unused.

Fixes: 05f224ca ("regulator: core: Clean enabling always-on regulators + their supplies")
Signed-off-by: NPascal Paillet <p.paillet@st.com>
Link: https://lore.kernel.org/r/20191113102737.27831-1-p.paillet@st.comSigned-off-by: NMark Brown <broonie@kernel.org>

Those regulators are not actually supported by the AB8500 regulator
driver. There is no ab8500_regulator_info for them and no entry in
ab8505_regulator_match.

As such, they cannot be registered successfully, and looking them
up in ab8505_regulator_match causes an out-of-bounds array read.

Fixes: 547f384f ("regulator: ab8500: add support for ab8505")
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: NStephan Gerhold <stephan@gerhold.net>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20191106173125.14496-2-stephan@gerhold.netSigned-off-by: NMark Brown <broonie@kernel.org>

The USB regulator was removed for AB8500 in
commit 41a06aa7 ("regulator: ab8500: Remove USB regulator").
It was then added for AB8505 in
commit 547f384f ("regulator: ab8500: add support for ab8505").

However, there was never an entry added for it in
ab8505_regulator_match. This causes all regulators after it
to be initialized with the wrong device tree data, eventually
leading to an out-of-bounds array read.

Given that it is not used anywhere in the kernel, it seems
likely that similar arguments against supporting it exist for
AB8505 (it is controlled by hardware).

Therefore, simply remove it like for AB8500 instead of adding
an entry in ab8505_regulator_match.

Fixes: 547f384f ("regulator: ab8500: add support for ab8505")
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: NStephan Gerhold <stephan@gerhold.net>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20191106173125.14496-1-stephan@gerhold.netSigned-off-by: NMark Brown <broonie@kernel.org>

SYR83X is used in Rockpro64 and it has die ID == 9. All other
registers are the same as in SYR82X
Signed-off-by: NVasily Khoruzhick <anarsoul@gmail.com>
Link: https://lore.kernel.org/r/20191106161211.1700663-1-anarsoul@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Depends on board design, the gpio controlling regulator may
connects with a big capacitance. When need off, it takes some time
to let the regulator to be truly off. If not add enough delay, the
regulator might have always been on, so introduce off-on-delay to
handle such case.
Signed-off-by: NPeng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/1572311875-22880-3-git-send-email-peng.fan@nxp.comSigned-off-by: NMark Brown <broonie@kernel.org>

When disabling a fixed regulator, it may take some time to let the
voltage drop to the expected value, such as zero. If not delay
enough time, the regulator might have been always enabled.
Signed-off-by: NPeng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/1572311875-22880-2-git-send-email-peng.fan@nxp.comSigned-off-by: NMark Brown <broonie@kernel.org>

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>