At the start of driver initialization, we do not know what bias
setting the bootloader has configured the system for and we only know
for certain the very first time we do a transition.

However, since the initial value of the comparison index is -EINVAL,
this negative value results in an array out of bound access on the
very first transition.

Since we don't know what the setting is, we just set the bias
configuration as there is nothing to compare against. This prevents
the array out of bound access.

NOTE: Even though we could use a more relaxed check of "< 0" the only
valid values(ignoring cosmic ray induced bitflips) are -EINVAL, 0+.

Fixes: 40b1936e ("regulator: Introduce TI Adaptive Body Bias(ABB) on-chip LDO driver")
Link: https://lore.kernel.org/linux-mm/CA+G9fYuk4imvhyCN7D7T6PMDH6oNp6HDCRiTUKMQ6QXXjBa4ag@mail.gmail.com/Reported-by: NNaresh Kamboju <naresh.kamboju@linaro.org>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NNishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20201118145009.10492-1-nm@ti.comSigned-off-by: NMark Brown <broonie@kernel.org>

Workaround regulators whose supply name happens to be the same as its
own name. This fixes boards that used to work before the early supply
resolving was removed. The error message is left in place so that
offending drivers can be detected.

Fixes: aea6cb99 ("regulator: resolve supply after creating regulator")
Cc: stable@vger.kernel.org
Reported-by: NAhmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # stpmic1
Link: https://lore.kernel.org/r/d703acde2a93100c3c7a81059d716c50ad1b1f52.1605226675.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

When a regulator's name equals its supply's name the
regulator_resolve_supply() recurses indefinitely. Add a check
so that debugging the problem is easier. The "fixed" commit
just exposed the problem.

Fixes: aea6cb99 ("regulator: resolve supply after creating regulator")
Cc: stable@vger.kernel.org
Reported-by: NAhmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # stpmic1
Link: https://lore.kernel.org/r/c6171057cfc0896f950c4d8cb82df0f9f1b89ad9.1605226675.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

Fixed commit introduced a possible second call to
set_machine_constraints() and that allocates memory for
rdev->constraints. Move the allocation to the caller so
it's easier to manage and done once.

Fixes: aea6cb99 ("regulator: resolve supply after creating regulator")
Cc: stable@vger.kernel.org
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # stpmic1
Link: https://lore.kernel.org/r/78c3d4016cebc08d441aad18cb924b4e4d9cf9df.1605226675.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

Limit the fsl,pfuze-support-disable-sw to the pfuze100 and pfuze200
variants.
When enabling fsl,pfuze-support-disable-sw and using a pfuze3000 or
pfuze3001, the driver would choose pfuze100_sw_disable_regulator_ops
instead of the newly introduced and correct pfuze3000_sw_regulator_ops.
Signed-off-by: NSean Nyekjaer <sean@geanix.com>
Fixes: 6f1cf525 ("regualtor: pfuze100: correct sw1a/sw2 on pfuze3000")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201110174113.2066534-1-sean@geanix.comSigned-off-by: NMark Brown <broonie@kernel.org>

In regulator_late_cleanup when is_enabled failed, don't try to disable
the regulator since it would likely to fail too and causing confusing
error messages.
Signed-off-by: NPi-Hsun Shih <pihsun@chromium.org>
Link: https://lore.kernel.org/r/20201106064817.3290927-1-pihsun@chromium.orgSigned-off-by: NMark Brown <broonie@kernel.org>

regulator_get_voltage_rdev() is called in regulator probe() when
applying machine constraints.  The "fixed" commit exposed the problem
that non-bypassed regulators can forward the request to its parent
(like bypassed ones) supply. Return -EPROBE_DEFER when the supply
is expected but not resolved yet.

Fixes: aea6cb99 ("regulator: resolve supply after creating regulator")
Cc: stable@vger.kernel.org
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Reported-by: NOndřej Jirman <megous@megous.com>
Reported-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
Tested-by: NOndřej Jirman <megous@megous.com>
Link: https://lore.kernel.org/r/a9041d68b4d35e4a2dd71629c8a6422662acb5ee.1604351936.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

The print in probe is done using pr_info. Correct print call would be
dev_dbg because:
 - Severity should really be dbg
 - The dev pointer is given as first argument
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/c4f55add237455555df0597c72052022f7a669f6.1601885841.git.matti.vaittinen@fi.rohmeurope.comSigned-off-by: NMark Brown <broonie@kernel.org>

The PM8953 is commonly used on board with MSM8953 SoCs or its variants:
APQ8053, SDM(SDA)450 and SDM(SDA)632.
It provides 7 SMPS and 23 LDO regulators.
Signed-off-by: NVladimir Lypak <junak.pub@gmail.com>
Link: https://lore.kernel.org/r/20201004083413.324351-1-junak.pub@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

If debugging is disabled, print_constraints() does not print the actual
constraints, but still performs some processing and string formatting,
only to throw away the result later.

Fix this by moving all constraint debug processing to a separate
function, and replacing it by a dummy when debugging is disabled.
This reduces kernel size by almost 800 bytes (on arm/arm64).
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20201005131546.22448-1-geert+renesas@glider.beSigned-off-by: NMark Brown <broonie@kernel.org>

The only usage of qcom_labibb_ops is to assign it to the ops field in
the regulator_desc struct, which is a const pointer. The only usage of
pmi8998_lab_desc and pmi8998_ibb_desc is to assign their address to the
desc field in the labibb_regulator_data struct which can be made const,
since it is only copied into the desc field in the
labbibb_regulator_data struct. This struct is modified, but that's a
copy of the static one. Make them const to allow the compiler to put
them in read-only memory.
Signed-off-by: NRikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200930162602.18583-1-rikard.falkeborn@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The PM660 and PM660L are a very very common PMIC combo, found on
boards using the SDM630, SDM636, SDM660 (and SDA variants) SoC.

PM660 provides 6 SMPS and 19 LDOs (of which one is unaccesible),
while PM660L provides 5 SMPS (of which S3 and S4 are combined),
10 LDOs and a Buck-or-Boost (BoB) regulator.

The PM660L IC also provides other regulators that are very
specialized (for example, for the display) and will be managed
in the other appropriate drivers (for example, labibb).
Signed-off-by: NAngeloGioacchino Del Regno <kholk11@gmail.com>
Link: https://lore.kernel.org/r/20200926125549.13191-6-kholk11@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The PM660 PMIC is very often paired with the PM660L option on
SDM630/663/660 (and SDA variants) boards.

The PM660 has 11 "660" LDOs (2 NMOS, 9 PMOS) and 7 HT LDOs (4 NMOS,
3 PMOS) and a quirk: the L4 regulator is unaccessible or does not
exist on the PMIC.
The PM660L has 8 "660" LDOs (1 NMOS, 7 PMOS) and 2 HT NMOS LDOs.
Signed-off-by: NAngeloGioacchino Del Regno <kholk11@gmail.com>
Link: https://lore.kernel.org/r/20200926125549.13191-4-kholk11@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

This commit adds the support for some regulator types that are
missing in this driver, such as the ht nmos-ldo, ht-lv nmos-ldo
and new gen n/pmos-ldo, all belonging to the FTSMPS426 register
layout.
This is done in preparation for adding support for the PM660 and
PM660L PMICs.
Signed-off-by: NAngeloGioacchino Del Regno <kholk11@gmail.com>
Link: https://lore.kernel.org/r/20200926125549.13191-3-kholk11@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Some regulator drivers may be defining very long names: this is the
case with the qcom_smd and qcom_spmi regulators, where we need to
parse the regulator parents from DT.

For clarity, this is an example:
{ "l13a", QCOM_SMD_RPM_LDOA, 13, &pm660_ht_lvpldo,
  "vdd_l8_l9_l10_l11_l12_l13_l14" },
pm660-regulators {
	...
	vdd_l8_l9_l10_l11_l12_l13_l14-supply = <&vreg_s4a_2p04>
	...
};
Now, with a 32 characters limit, the function is trying to parse,
exactly, "vdd_l8_l9_l10_l11_l12_l13_l14-s" (32 chars) instead of
the right one, which is 37 chars long in this specific case.

... And this is not only the case with PM660/PM660L, but also with
PMA8084, PM8916, PM8950 and others that are not implemented yet.

The length of 64 chars was chosen based on the longest parsed property
name that I could find, which is in PM8916, and would be 53 characters
long.
At that point, rounding that to 64 looked like being the best idea.
Signed-off-by: NAngeloGioacchino Del Regno <kholk11@gmail.com>
Link: https://lore.kernel.org/r/20200926125549.13191-2-kholk11@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Use regmap accessors directly for register manipulation - removing
one layer of abstraction.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/e82886d0f8f5131c9fccf2a17e3a15acce507d6f.1601164493.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

Add missing regcache cache only before masked as dirty.
Signed-off-by: NChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1601461132-15251-1-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

1. Add vendor suffix to all proprietary properties.
2. Fix typo.
3. Change lsw to normal property, not pattern property.
4. Due to item 1, modify source code for property parsing.
Signed-off-by: NChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1601460480-4259-1-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add support for Richtek RTMV20 load switch regulator.
Signed-off-by: NChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1601277584-5526-1-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

When creating a new regulator its supply cannot create the sysfs link
because the device is not yet published. Remove early supply resolving
since it will be done later anyway. This makes the following error
disappear and the symlinks get created instead.

  DCDC_REG1: supplied by VSYS
  VSYS: could not add device link regulator.3 err -2

Note: It doesn't fix the problem for bypassed regulators, though.

Fixes: 45389c47 ("regulator: core: Add early supply resolution for regulators")
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/ba09e0a8617ffeeb25cb4affffe6f3149319cef8.1601155770.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

Change all error-printing messages to include error name via %pe instead
of numeric error or nothing.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/1dcf25f39188882eb56918a9aa281ab17b792aa5.1601155770.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

Make the initial state of the regulator shown when debugging.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/53c4f3d394d68f0989174f89e3b0882cebbbd787.1601155770.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

Currently we wrongly set the mask of value of LDO2/4 both to the mask of
LDO2, and the LDO4 voltage configuration is left untouched. This leads
to conflict when LDO2/4 are both in use.

Fix this issue by setting different vsel_mask to both regulators.

Fixes: db4a555f ("regulator: axp20x: use defines for masks")
Signed-off-by: NIcenowy Zheng <icenowy@aosc.io>
Link: https://lore.kernel.org/r/20200923005142.147135-1-icenowy@aosc.ioSigned-off-by: NMark Brown <broonie@kernel.org>

The driver was using subsys_initcall() because in old times deferred
probe was not supported everywhere and specific ordering was needed.
Since probe deferral works fine and specific ordering is discouraged
(hides dependencies between drivers and couples their boot order), the
driver can be converted to regular module_platform_driver.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200921203616.19623-1-krzk@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Most of Maxim and Samsung PMIC/MUIC regulator drivers can be compile
tested to increase build coverage.  This allows to build them on
configurations without I2C (as I2C is required by dependency - parent
MFD driver).
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200920214107.6299-1-krzk@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

There is a return statement that is indented with an extra
space, fix this by removing it.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20200920142454.33352-1-colin.king@canonical.comSigned-off-by: NMark Brown <broonie@kernel.org>

regulator_lock/unlock() was used only to guard
regulator_notifier_call_chain(). As no users remain, make the functions
internal.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/d3381aabd2632aff5e7b839d55868bec6e85c811.1600550732.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

Add initial support for ROHM BD9576MUF and BD9573MUF PMICs regulators.
These PMICs are mainly used to power the R-Car series processors.

The BD9576 includes some functional-safety features which are not
present on BD9573.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/78baea1d7922506827ca717e277e4e6b391bbb78.1600329307.git.matti.vaittinen@fi.rohmeurope.comSigned-off-by: NMark Brown <broonie@kernel.org>

The only usage of ti_abb_reg_ops is to assign its address to the ops
field in the regulator_desc struct, which is a const pointer. Make it
const to allow the compiler to put it in read-only memory.
Signed-off-by: NRikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200913084114.8851-6-rikard.falkeborn@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The only usages of these is to assign their address to the ops field in
the regulator_desc struct, which is a const pointer. Make them const to
allow the compiler to put them in read-only memory.
Signed-off-by: NRikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200913084114.8851-5-rikard.falkeborn@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The only usage of stw481x_vmmc_ops is to assign its address to the ops
field in the regulator_desc struct which is a const pointer.

The only usage of vmmc_regulator is to pass its address to
of_get_regulator_init_data() and devm_regulator_register(), both which
take const pointers.

Make both of them const to allow the compiler to put them in read-only
memory.
Signed-off-by: NRikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200913084114.8851-4-rikard.falkeborn@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The only usage of fixed_voltage_ops and fixed_voltage_clkenabled_ops is
to assign their address the ops field in the regulator_desc struct,
which is a const pointer. Make them const to allow the compiler to put
them in read-only memory.
make them const to allow the compiler to put them in read-only memory.
Signed-off-by: NRikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200913084114.8851-3-rikard.falkeborn@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The only usage of dummy_initdata is to assign its address to the
init_data field of the regulator_config struct and the only usage
dummy_ops is to assign its address to the ops field in the
regulator_desc struct, both which are const pointers. Make them const to
allow the compiler to put them in read-only memory.
Signed-off-by: NRikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200913084114.8851-2-rikard.falkeborn@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Fix sparse warnings:

drivers/regulator/bd718x7-regulator.c:576:28: warning: symbol 'bd71847_swcontrol_ops' was not declared. Should it be static?
drivers/regulator/bd718x7-regulator.c:585:28: warning: symbol 'bd71847_hwcontrol_ops' was not declared. Should it be static?
drivers/regulator/bd718x7-regulator.c:902:28: warning: symbol 'bd71837_swcontrol_ops' was not declared. Should it be static?
drivers/regulator/bd718x7-regulator.c:913:28: warning: symbol 'bd71837_hwcontrol_ops' was not declared. Should it be static?
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Acked-By: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/20200910034240.37268-1-yuehaibing@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>

In the case of an unrecognised mini-card the Lochnagar will not
initialise the VDDCORE voltage register leading to a value outside of the
current range. Add an additional range to cover these values, initially
this wasn't done since they are duplicates of the existing minimum
value.
Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200904122506.28017-1-ckeepax@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>

regulator_notifier_call_chain() doesn't need rdev lock and rdev's
existence is assumed in the code anyway. Remove the locks from drivers.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: NAdam Thomson <Adam.Thomson.Opensource@diasemi.com>
Reviewed-by: NDmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/42393f66dcc4d80dcd9797be45216b4035aa96cb.1597032945.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

Since 3801b86a ("regulator: Refactor supply implementation
to work as regular consumers") we no longer cascade notifications
and so notifier head's built-in rwsem is enough to protect the
notifier chain. Remove the requirement to fix one case where
rdev->mutex might be forced to be taken recursively.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: NDmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/5a0da9017c69a4dbc3f9b50f44476fce80a73387.1597032945.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

The BD718(37/47/50) regulator enable states can be controlled
either by SW or by PMIC internal state machine. The bd718x7
driver has not supported leaving the regulators under HW state
machine control (except for cases where this is required to
avoid boot-up problems due to critical regulators being turned
OFF at reset when SNVS used as reset state).

On some systems this is undesirable as there now are setups where
mixture of SW and HW state machine controlled regulators is needed.

Specifically, some SoCs signal SUSPEND state change to PMIC via
STBY_REQ line. Now there are setups that expect certain regulators
then to be disabled (by PMIC state machine) while other regulators
should stay enabled (regardless of HW state => SW control required).

Add support for a new device-tree property
"rohm,no-regulator-enable-control" which can be used to leave
regulator(s) under HW state machine control.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/6ebba33dd08f2dcc9f1137bbff4d2dc905278a5a.1599029335.git.matti.vaittinen@fi.rohmeurope.comSigned-off-by: NMark Brown <broonie@kernel.org>

The BD718x7 driver initialized common configs for all regulators.
Simplify initialization by moving the initialization of common configs
out of the loop.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/2d3e68c94d4813410da8c4c7eac3332d167d19a8.1599029334.git.matti.vaittinen@fi.rohmeurope.comSigned-off-by: NMark Brown <broonie@kernel.org>

If the zero duty cycle doesn't correspond to any voltage in the voltage
table, the PWM regulator returns an -EINVAL from get_voltage_sel() which
results in the core erroring out with a "failed to get the current
voltage" and ending up not applying the machine constraints.

Instead, return -ENOTRECOVERABLE which makes the core set the voltage
since it's at an unknown value.

For example, with this device tree:

	fooregulator {
		compatible = "pwm-regulator";
		pwms = <&foopwm 0 100000>;
		regulator-min-microvolt = <2250000>;
		regulator-max-microvolt = <2250000>;
		regulator-name = "fooregulator";
		regulator-always-on;
		regulator-boot-on;
		voltage-table = <2250000 30>;
	};

Before this patch:

  fooregulator: failed to get the current voltage(-22)

After this patch:

  fooregulator: Setting 2250000-2250000uV
  fooregulator: 2250 mV
Signed-off-by: NVincent Whitchurch <vincent.whitchurch@axis.com>
Link: https://lore.kernel.org/r/20200902130952.24880-1-vincent.whitchurch@axis.comSigned-off-by: NMark Brown <broonie@kernel.org>