commit 06423121d9eba0a56b9341cf82b88479017bce14 upstream.

When resolving regulator-regulator supplies we ignore probe deferral
returns from regulator_dev_lookup() (such as are generated for DT when
we can see a supply is registered) and just fall back to the dummy
regulator if there are full constraints (as is the case for DT).  This
means that probe deferral is broken for DT systems, fix that by paying
attention to -EPROBE_DEFER return codes like we do -ENODEV.

A further patch will simplify this further, this is a minimal fix for
the specific issue.

Fixes: 9f7e25edb1575a6d2 (regulator: core: Handle full constraints systems when resolving supplies)
Reported-by: Sascha Hauer <s.hauer@pengutronix.de>
Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Mark Brown <broonnie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b3600b4ba0810c84437cf76556d9afbd55c1bfc upstream.

The enable bit indexes for DCDC4 and DCDC5 regulators are off by 1.

We haven't run into any problems with this since either the regulators
aren't defined in the DT and aren't used, or all the DCDC regulators
have the "always-on" property set, as they are almost always used
for system critical loads.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23c3f310e897837aeb8ffe8700b803cb58e7b35d upstream.

The ret pointer passed to regulator_dev_lookup is only filled with a
valid error code if regulator_dev_lookup returned NULL. Currently
regulator_resolve_supply checks this ret value before it checks if a
regulator was returned, this can result in valid regulator lookups being
ignored.

Fixes: 6261b06de565 ("regulator: Defer lookup of supply to regulator_get")
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c329061be51bef655f28c9296093984c977aff85 upstream.

regulator_disable of pbias always writes '0' to the enable_reg.
However actual disable value of pbias regulator is not always '0'.
Fix it by populating the disable_val in pbias_reg_info for the
various platforms and assign it to the disable_val of
pbias regulator descriptor. This will be used by
regulator_disable_regmap while disabling pbias regulator.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The regulator_resolve_supply() function calls set_supply() which in turn
calls create_regulator() to allocate a supply regulator.

If an error occurs after set_supply() succeeded, the allocated regulator
has to be freed before propagating the error code.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

When a regulator is unregistered with regulator_unregister(), a call to
regulator_put() is made for its input supply if there is one. This does
a module_put() to decrement the refcount of the module that owns the
supply but there isn't a corresponding try_module_get() in set_supply()
to make the calls balanced.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

When resolving device supplies if we fail to look up the regulator we
substitute in the dummy supply instead if the system has fully specified
constraints. When resolving supplies for regulators we do not have the
equivalent code and instead just directly use the regulator_dev_lookup()
result causing spurious failures.

This does not affect DT systems since we are able to detect missing
mappings directly as part of regulator_dev_lookup() and so have appropriate
handling in the DT specific code.

Reported-by: Christian Hartmann <cornogle@googlemail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

As per datasheet,
Except LDO2, all other LDO's use bit [3:0] for VOUT select.

Current code uses wrong mask value of 0x1f, So this patch
fixes it to use 0xf.

Signed-off-by: Yi Zhang <yizhang@marvell.com>
[vaibhav.hiremath@linaro.org: Updated changelog with more detailed description]
Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>

The control flag for the bias control is MAX8973_CONTROL_BIAS_ENABLE
rather than MAX8973_BIAS_ENABLE which is macro for the bits in
register.

Fix this typo.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>