regulator: core: return err value for regulator_get if there is no DT binding

commit 6d191a5fc7a969d972f1681e1c23781aecb06a61
(regulator: core: Don't defer probe if there's no DT binding for a supply)

Attempted to differentiate between regulator_get() with an actual
DT binding for the supply and when there is none to avoid unnecessary
deferal.

In cases where a driver, such as cpufreq driver, need to handle (based
on platform)_DT bindings which may or may not have regulator supply
binding, it is necessary to differentiate the return value. When there
is regulator supply binding, defering the probe is beneficial
as sequence of dependent regulator probe may not be predictable.
However, where is no regulator supply binding, it can operate without
the same as needed.

To provide an appropriate return result, when we cannot find an
regulator in regulator_dev_lookup and we run out of options,
use the regulator_dev_lookup result. This helps the caller to help make
informed decision.

Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
cpufreq: cpufreq-cpu0: defer probe when regulator is not ready

regulator_get will now return -EPROBE_DEFER when the cpu0-supply
node is present, but the regulator is not yet registered.

It is possible for this to occur when the regulator registration
by itself might be defered due to some dependent interface not
yet instantiated. For example: an regulator which uses I2C and GPIO
might need both systems available before proceeding, in this case,
the regulator might defer it's registration.

However, the cpufreq-cpu0 driver assumes that any un-successful return
result is equivalent of failure.

When the regulator_get returns failure other than -EPROBE_DEFER, it
makes sense to assume that supply node is not present and proceed
with the assumption that only clock control is necessary in the
platform.

With this change, we can now handle the following conditions:
a) cpu0-supply binding is not present, regulator_get will return
appropriate error result, resulting in cpufreq-cpu0 driver
b) cpu0-supply binding is present, regulator_get returns -EPROBE_DEFER,
we retry resulting in cpufreq-cpu0 driver registering later once the
regulator is available.
c) cpu0-supply binding is present, regulator_get returns -EPROBE_DEFER,
however, regulator never registers, we retry until cpufreq-cpu0
driver fails to register pointing at device tree information bug.
However, in this case, the fact that cpufreq-cpu0 operates with clock
only when the DT binding clearly indicates need of a supply is a bug of
it's own.
d) cpu0-supply gets an regulator at probe - this is the usual case and
original logic still holds good.

Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Nishanth Menon <nm@ti.com>