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: Mark Brown <broonie@kernel.org>
Tested-by: Dong Aisheng <aisheng.dong@nxp.com>
Reviewed-by: Dong 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: Dong Aisheng <aisheng.dong@nxp.com>
Tested-by: Dong Aisheng <aisheng.dong@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Mark 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: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Commit 26988efe11b1 ("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: 26988efe11b1 ("regulator: core: Allow to get voltage count and
  list from parent")
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark 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: Tamara Diaconita <diaconita.tamara@gmail.com>
Signed-off-by: Mark 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: Harald Geyer <harald@ccbib.org>
Signed-off-by: Mark 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: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>

When creating the link to the device sysfs entry, the regulator core
calls scnprintf() and then checks if the returned value is greater or
equal than the buffer size.

The former can never happen as scnprintf() returns the number of bytes
that were actually written to the buffer, not the bytes that *would*
have been written.

Use the right function in this case: snprintf().

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>