A race condition between queueing and processing the disable_work
instances results in having a work instance in the queue and the
deferred_disables variable of regulator device structure having a
value '0'. If no new regulator_disable_deferred() call later from
clients, the deferred_disables variable value remains '0' and hits
BUG() in regulator_disable_work() when the queued instance scheduled
for processing the work.

The race occurs as below:

	Core-0					     Core-1
	.....	       /* deferred_disables = 2 */   .....
	.....	       /* disable_work is queued */  .....
	.....					     .....
regulator_disable_deferred: 		regulator_disable_work:
   mutex_lock(&rdev->mutex);			     .....
   rdev->deferred_disables++;		             .....
   mutex_unlock(&rdev->mutex);			     .....
   queue_delayed_work(...)		    mutex_lock(&rdev->mutex);
	.....				    count =rdev->deferred_disables;
	.....				    rdev->deferred_disables = 0;
	.....					     .....
	.....				    mutex_unlock(&rdev->mutex);
	.....					     .....
	.....				    return;
	.....					     .....
	/* No new regulator_disable_deferred() calls from clients */
	/* The newly queued instance is scheduled for processing */
	.....					     .....
regulator_disable_work:
	.....
   mutex_lock(&rdev->mutex);
   BUG_ON(!rdev->deferred_disables); /* deferred_disables = 0 */

The race is fixed by removing the work instance that is queued while
processing the previous queued instance. Cancel the newly queued instance
from disable_work() handler just after reset the deferred_disables variable
to value '0'. Also move the work queueing step before mutex_unlock in
regulator_disable_deferred().

Also use mod_delayed_work() in the pace of queue_delayed_work() as
queue_delayed_work() always uses the delay requested in the first call
when multiple consumers call regulator_disable_deferred() close in time
and does not guarantee the semantics of regulator_disable_deferred().

Signed-off-by: Tirupathi Reddy <tirupath@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>

Now that we have a custom printf format specifier, convert users of
full_name to use %pOF instead. This is preparation to remove storing
of the full path string for each node.

Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>

Now the debugfs file supply_map has a size limit PAGE_SIZE and the user
can not see the whole content of regulator_map_list when it is larger
than this limit.

This patch uses seq_file instead to make sure supply_map shows the full
information of regulator_map_list.

Signed-off-by: Haishan Zhou <zhssmail@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Some regulators support get_voltage() and some support get_voltage_sel()
operations but currently we only propagate changes if the regulator has
a get_voltage() operation.  Also do this if we've got get_voltage_sel()

[Rewite commit message for clarity -- broonie]

Signed-off-by: Tirupathi Reddy <tirupath@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>

Currently, when looking up a regulator supply, the regulator name
takes priority over the consumer mappings. As there are a lot of
regulator names that are in fairly common use (VDD, MICVDD, etc.) this
can easily lead to obtaining the wrong supply, when a system contains
two regulators that share a name.

The explicit consumer mappings contain much less ambiguity as they
specify both a name and a consumer device. As such prioritise those if
one exists and only fall back to the regulator name if there are no
matching explicit mappings.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Some regulators have different settling times for voltage increases and
decreases. To avoid a time penalty on the faster transition allow for
different settings for up- and downward transitions.

Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>