During the resolution of a regulator's supply, we may attempt to enable
the supply if the regulator itself is already enabled. If enabling the
supply fails, then we will call _regulator_put() for the supply.
However, the pointer to the supply has not been cleared for the
regulator and this will cause a crash if we then unregister the
regulator and attempt to call regulator_put() a second time for the
supply. Fix this by clearing the supply pointer if enabling the supply
after fails when resolving the supply for a regulator.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The function regulator_register_resolve_supply() is called from the
context of class_for_each_dev() (during the regulator registration) to
resolve any supplies added. regulator_register_resolve_supply() will
return an error if a regulator's supply cannot be resolved and this will
terminate the loop in class_for_each_dev(). This means that we will not
attempt to resolve any other supplies after one has failed. Hence, this
may delay the resolution of other regulator supplies until the failing
one itself can be resolved.

Rather than terminating the loop early, don't return an error code and
keep attempting to resolve any other supplies for regulators that have
been registered.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

device_register() is calling ->get_voltage() as part of it's sysfs attribute
initialization process, and this functions might need to know the regulator
constraints to return a valid value.
This is at least true for the pwm regulator driver (when operating in
continuous mode) which needs to know the minimum and maximum voltage values
to calculate the current voltage:

min_uV + (((max_uV - min_uV) * dutycycle) / 100);

Move device_register() after set_machine_constraints() to make sure those
constraints are correctly initialized when ->get_voltage() is called.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: NStephen Barber <smbarber@chromium.org>
Tested-by: NCaesar Wang <wxt@rock-chips.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Commit 5e3ca2b3 ("regulator: Try to resolve regulators supplies on
registration") added a call to regulator_resolve_supply() within
regulator_register() where the regulator_list_mutex is held. This causes
a deadlock to occur on the Tegra114 Dalmore board when the palmas PMIC
is registered because regulator_register_resolve_supply() calls
regulator_dev_lookup() which may try to acquire the regulator_list_mutex
again.

Fix this by releasing the mutex before calling
regulator_register_resolve_supply() and update the error exit path to
ensure the mutex is released on an error.

[Made commit message more legible -- broonie]
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Commit 6261b06d ("regulator: Defer lookup of supply to regulator_get")
moved the regulator supplies lookup logic from the regulators registration
to the regulators get time.

Unfortunately, that changed the behavior of the regulator core since now a
parent supply with a child regulator marked as always-on, won't be enabled
unless a client driver attempts to get the child regulator during boot.

This patch tries to resolve the parent supply for the already registered
regulators each time that a new regulator is registered. So the regulators
that have child regulators marked as always on will be enabled regardless
if a driver gets the child regulator or not.

That was the behavior before the mentioned commit, since parent supplies
were looked up at regulator registration time instead of during child get.

Since regulator_resolve_supply() checks for rdev->supply, most of the times
it will be a no-op. Errors aren't checked to keep the possible out of order
dependencies which was the motivation for the mentioned commit.

Also, the supply being available will be enforced on regulator get anyways
in case the resolve fails on regulators registration.

Fixes: 6261b06d ("regulator: Defer lookup of supply to regulator_get")
Suggested-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org> # 4.1+

Some of platforms like Nvidia's Tegra210 Jetson-TX1 platform has
multiple PMW based regulators. Add support to have multiple instances
of the driver by not changing any global data of pwm regulator and
if required, making instance specific copy and then making changes.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

With following equation for calculating
voltage_to_duty_cycle_percentage
	100 - (((req_uV * 100) - (min_uV * 100)) / diff);

we get 0% for max_uV and 100% for min_uV.

Correcting this to
	((req_uV * 100) - (min_uV * 100)) / diff;
 to get proper duty cycle.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

OF interface provides to read the u32 value via standard interface
of_property_read_u32(). Use this API to read "regulator-min-microvolts"
and "regulator-max-microvolt".

This will make consistent with other property value reads.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This is a patch to fix incorrect clear of event register.
Signed-off-by: NJames Ban <James.Ban.opensource@diasemi.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This is a patch to fix incorrect clear of event register.
Signed-off-by: NJames Ban <James.Ban.opensource@diasemi.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add regulator ops callback for configuration of active-discharge
and provide necessarily information via regulator descriptor.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add support to enable/disable active discharge of regulator via
machine constraints. This configuration is done when setting
machine constraint during regulator register and if regulator
driver implemented the callback ops.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add helper function to set the state of active-discharge of
regulator using regmap. The HW regulator driver can directly
use this by providing the necessary information in the regulator
descriptor.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add support to enable/disable active discharge of regulator via
machine constraints. This configuration is done when setting
machine constraint during regulator register and if regulator
driver implemented the callback ops.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The documentation lists both 1.8V and 3.3V for this regulator output,
but 3.3V is mentioned more often and also matches what JZ4770 and
JZ4780 expect as an input.

Note that the voltage of REG9 is not programmable, so this commit only
changes the voltage reported in sysfs and debugfs, not the actual
output voltage of the hardware.
Signed-off-by: NMaarten ter Huurne <maarten@treewalker.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Make the field name match its type.
Signed-off-by: NMaarten ter Huurne <maarten@treewalker.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

There is no need to preserve its value between calls. I guess this
was a copy-paste slip-up.
Signed-off-by: NMaarten ter Huurne <maarten@treewalker.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The same alias is already in .id_table.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

These fields are never used and not required at all, remove them.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This problem was introduced by:
commit daad134d ("regulator: core: Request GPIO before creating
sysfs entries")

The error path was not updated correctly after moving GPIO registration
code and in case regulator_ena_gpio_free failed, device_unregister() was
called even though device_register() was not yet called.

This problem breaks the boot at least on all Tegra 32-bit devices. It
will also crash each device that specifices GPIO that is unavaiable at
regulator_register call. Here's error log I've got when forced GPIO to
be invalid:

[    1.116612] usb-otg-vbus-reg: Failed to request enable GPIO10: -22
[    1.122794] Unable to handle kernel NULL pointer dereference at
virtual address 00000044
[    1.130894] pgd = c0004000
[    1.133598] [00000044] *pgd=00000000
[    1.137205] Internal error: Oops: 5 [#1] SMP ARM

and here's backtrace from KDB:

Exception stack(0xef11fbd0 to 0xef11fc18)
fbc0:                                     00000000 c0738a14 00000000 00000000
fbe0: c0b2a0b0 00000000 00000000 c0738a14 c0b5fdf8 00000001 ef7f6074 ef11fc4c
fc00: ef11fc50 ef11fc20 c02a8344 c02a7f1c 60000013 ffffffff
[<c010cee0>] (__dabt_svc) from [<c02a7f1c>] (kernfs_find_ns+0x18/0xf8)
[<c02a7f1c>] (kernfs_find_ns) from [<c02a8344>] (kernfs_find_and_get_ns+0x40/0x58)
[<c02a8344>] (kernfs_find_and_get_ns) from [<c02ac4a4>] (sysfs_unmerge_group+0x28/0x68)
[<c02ac4a4>] (sysfs_unmerge_group) from [<c044389c>] (dpm_sysfs_remove+0x30/0x5c)
[<c044389c>] (dpm_sysfs_remove) from [<c0436ba8>] (device_del+0x48/0x1f4)
[<c0436ba8>] (device_del) from [<c0436d84>] (device_unregister+0x30/0x6c)
[<c0436d84>] (device_unregister) from [<c0403910>] (regulator_register+0x6d0/0xdac)
[<c0403910>] (regulator_register) from [<c04052d4>] (devm_regulator_register+0x50/0x84)
[<c04052d4>] (devm_regulator_register) from [<c0406298>] (reg_fixed_voltage_probe+0x25c/0x3c0)
[<c0406298>] (reg_fixed_voltage_probe) from [<c043d21c>] (platform_drv_probe+0x60/0xb0)
[<c043d21c>] (platform_drv_probe) from [<c043b078>] (driver_probe_device+0x24c/0x440)
[<c043b078>] (driver_probe_device) from [<c043b5e8>] (__device_attach_driver+0xc0/0x120)
[<c043b5e8>] (__device_attach_driver) from [<c043901c>] (bus_for_each_drv+0x6c/0x98)
[<c043901c>] (bus_for_each_drv) from [<c043ad20>] (__device_attach+0xac/0x138)
[<c043ad20>] (__device_attach) from [<c043b664>] (device_initial_probe+0x1c/0x20)
[<c043b664>] (device_initial_probe) from [<c043a074>] (bus_probe_device+0x94/0x9c)
[<c043a074>] (bus_probe_device) from [<c043a610>] (deferred_probe_work_func+0x80/0xcc)
[<c043a610>] (deferred_probe_work_func) from [<c01381d0>] (process_one_work+0x158/0x454)
[<c01381d0>] (process_one_work) from [<c013854c>] (worker_thread+0x38/0x510)
[<c013854c>] (worker_thread) from [<c013e154>] (kthread+0xe8/0x104)
[<c013e154>] (kthread) from [<c0108638>] (ret_from_fork+0x14/0x3c)
Signed-off-by: NKrzysztof Adamski <krzysztof.adamski@tieto.com>
Reported-by: NJon Hunter <jonathanh@nvidia.com>
Acked-by: NJon Hunter <jonathanh@nvidia.com>
Tested-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

regulator_attr_is_visible (which is a .is_visible callback of
regulator_dev_group attribute_grpup) checks rdev->ena_pin to decide if
"status" file should be present in sysfs. This field is set at the end
of regulator_ena_gpio_request so it has to be called before
device_register() otherwise this test will always fail, causing "status"
file to not be visible.

Since regulator_attr_is_visible also tests for is_enabled() op, this
problem is only visible for regulators that does not define this
callback, like regulator-fixed.c.
Signed-off-by: NKrzysztof Adamski <krzysztof.adamski@tieto.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Don't print out an error with the driver sees EPROBE_DEFER when
attempting to get the gpio.  These errors are usually transient; the
probe will be retried later.
Signed-off-by: NRabin Vincent <rabin.vincent@axis.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Remove the s2mps11_info.rdev_num because it is not used outside of
probe.
Suggested-by: NAndi Shyti <andi.shyti@samsung.com>
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: NAndi Shyti <andi.shyti@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

i2c_master_send() returns the number of bytes written on success.
So current code returns 2 if ad5398_write_reg() success.
This return value is propagated to .set_current_limit, .enable and .disable
callbacks of regulator_ops. This can be a problem, for example, if the
users test if the return value of regulator_set_current_limit() is 0.
Fix it by making ad5398_write_reg() return 0 on success.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

MAXIM Semiconductor's PMIC, MAX77620 and MAX20024 have the
multiple DCDC and LDOs. This supplies the power to different
components of the system.
Also these rails has configuration for ramp time, flexible
power sequence, slew rate etc.

Add regulator driver to access these rails via regulator APIs.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMallikarjun Kasoju <mkasoju@nvidia.com>
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Following BUILD_BUG_ON using a variable fails for some of the compilers
and optimization levels (reported for gcc 4.9):
	var = ARRAY_SIZE(s2mps15_regulators);
	BUILD_BUG_ON(S2MPS_REGULATOR_MAX < var);
Fix this by using ARRAY_SIZE directly.

Additionally add missing BUILD_BUG_ON check for S2MPS15 device (the
check ensures that internal arrays are big enough to hold data for all
of regulators on all devices).
Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Tested-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

The s5m8767_pmic_probe() function calls s5m8767_get_register() to
read data without checking the return code, which produces a compile-time
warning when that data is accessed:

drivers/regulator/s5m8767.c: In function 's5m8767_pmic_probe':
drivers/regulator/s5m8767.c:924:7: error: 'enable_reg' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/regulator/s5m8767.c:944:30: error: 'enable_val' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This changes the s5m8767_get_register() function to return a -EINVAL
not just for an invalid register number but also for an invalid
regulator number, as both would result in returning uninitialized
data. The s5m8767_pmic_probe() function is then changed accordingly
to fail on a read error, as all the other callers of s5m8767_get_register()
already do.

In practice this probably cannot happen, as we don't call
s5m8767_get_register() with invalid arguments, but the gcc
warning seems valid in principle, in terms writing safe
error checking.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 9c4c6055 ("regulator: s5m8767: Convert to use regulator_[enable|disable|is_enabled]_regmap")
Signed-off-by: NMark Brown <broonie@kernel.org>

The vexpress regulator implementation is currently just called vexpress.
This is a problem because it clashes with another module with the same
name in hardware monitors.

This patch renames the vexpress regulator implementation to
vexpress-regulator so that there will be no clash in the module namespace.

Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Reported-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Originally the helper macros used uppercase regulator names, which
are primarily used to expand to the regulator ID enum, as the default
names. This is aestheticly unpleasent.

Since the of_match bits are the same, just lowercase, use that as the
default names instead.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add the regulator driver for hi655x PMIC.
Signed-off-by: NChen Feng <puck.chen@hisilicon.com>
Signed-off-by: NFei Wang <w.f@huawei.com>
Signed-off-by: NXinwei Kong <kong.kongxinwei@hisilicon.com>
Reviewed-by: NHaojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

It's perfectly valid to use the LTC3589 without an interrupt pin
connected to it. Currently, the driver probing fails when client->irq
is 0 (which means "no interrupt"). Don't register the interrupt
handler in that case but successfully finish the device probing instead.
Signed-off-by: NBernhard Walle <bernhard@bwalle.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

The max77686 and max77802 regulator drivers are for sub-devices of a MFD
driver for some PMIC blocks. But the same object file name (max77686.o)
was used for both the common MFD driver and the max77686 regulator one.

This confuses kbuild if both drivers are built as module causing the MFD
driver to not be copied when installing the modules.

Also, max77{686,802} are a quite generic name for MFD subdevices drivers
so it is better to rename them to max77{686,802}-regulator like it's the
case for most regulator drivers.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
It is functionally identical to AXP221; only the regulator default
voltage/status and the external host interface are different.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Reviewed-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

This patch adds support for TPS65912 PMIC regulators.

The regulators set consists of 4 DCDCs and 10 LDOs. The output
voltages are configurable and are meant to supply power to the
main processor and other components.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

The old tps65912 driver is being replaced, delete old driver.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Acked-by: NMark Brown <broonie@kernel.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

LP872x regulators are made active via the EN pin, which might be hooked to a
GPIO. This adds support for driving the GPIO high when the driver is in use.
Signed-off-by: NPaul Kocialkowski <contact@paulk.fr>
Signed-off-by: NMark Brown <broonie@kernel.org>

Some devices don't hook the DVS pin to a GPIO but to ground or VCC.
In those cases, it is not a problem to have no DVS GPIO provided, as the current
code will already switch to software-only DVS selection:

When the DVS GPIO is invalid, lp872x_init_dvs jumps to the set_default_dvs_mode
label, which instructs the chip not to use the DVS pin at all and do it all in
software instead (by clearing the LP8720_EXT_DVS_M bit in the
LP872X_GENERAL_CFG register).

That is reflected later in the code, when setting the bucks (the DVS pin only
applies to the bucks) by checking for the LP8720_EXT_DVS_M bit on the
LP872X_GENERAL_CFG register (in lp872x_select_buck_vout_addr) to decide whether
to use software or hardware DVS selection.

Thus, there is no need to print a warning when the DVS GPIO is invalid.
Signed-off-by: NPaul Kocialkowski <contact@paulk.fr>
Signed-off-by: NMark Brown <broonie@kernel.org>

This patch adds new regulator driver to support ACT8945A MFD
chip's regulators.

The ACT8945A has three step-down DC/DC converters and four
low-dropout regulators.
Signed-off-by: NWenyou Yang <wenyou.yang@atmel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

AXP20X datasheet lists the possible voltage settings for LDO4, so
it was implemented using a voltage table. Upon closer examination,
the valid voltages can be mapped into 3 linear ranges.

Move AXP20X LDO4 to use linear ranges. The supporting code can be
reused with later AXP8xx PMICs, which have a number of regulators
that have 2 linear ranges.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMark Brown <broonie@kernel.org>