regulator_is_supported_voltage() should return true only if the voltage
of fixed/constant regulator is between min_uV and max_uV.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org

When regulator_register fails and exits through the scrub path the
regulator_put function was called whilst holding the
regulator_list_mutex, causing deadlock.

This patch adds a private version of the regulator_put function which
can be safely called whilst holding the mutex, replacing the
aforementioned call.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

If the gpio_request_one() fails, or returns EPROBE_DEFER, the
regulator must be device_unregister()ed. When this is not done,
there are WARNING: from sysfs:

WARNING: at fs/sysfs/file.c:343 sysfs_open_file+0x238/0x268()
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Many regulators support a bypass mode where they simply switch their
input supply to the output. This is mainly used in low power retention
states where power consumption is extremely low so higher voltage or
less clean supplies can be used.

Support this by providing ops for the drivers and a consumer API which
allows the device to be put into bypass mode if all consumers enable it
and the machine enables permission for this.

This is not supported as a mode since the existing modes are rarely used
due to fuzzy definition and mostly redundant with modern hardware which is
able to respond promptly to load changes.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: NGraeme Gregory <gg@slimlogic.co.uk>

If the device doesn't have a regmap specified by the driver and we can't
find one on the device itself try its parent, providing a useful defualt
for many MFDs.

[Rewrite commit message -- broonie]
Signed-off-by: NAnilKumar Ch <anilkumar@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Users (especially framework code) may end up passing in a zero deferral
time depending on runtime conditions or configuration. If they do then
just call regulator_disable() directly to save scheduling.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

If a regulator only supports a single voltage list_voltage() can be used
to report what that voltage is so add this as one of the criteria for
creating the microvolts file in sysfs.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Fix regulator kernel-doc warnings:

Warning(drivers/regulator/core.c:2308): No description found for parameter 'rdev'
Warning(drivers/regulator/core.c:2308): Excess function parameter 'regulator' description in 'regulator_set_voltage_time_sel'
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Cc:	Liam Girdwood <lrg@ti.com>
Cc:	Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

flush[_delayed]_work_sync() are now spurious.  Mark them deprecated
and convert all users to flush[_delayed]_work().

If you're cc'd and wondering what's going on: Now all workqueues are
non-reentrant and the regular flushes guarantee that the work item is
not pending or running on any CPU on return, so there's no reason to
use the sync flushes at all and they're going away.

This patch doesn't make any functional difference.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Mattia Dongili <malattia@linux.it>
Cc: Kent Yoder <key@linux.vnet.ibm.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: Bryan Wu <bryan.wu@canonical.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Alasdair Kergon <agk@redhat.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Cc: Anton Vorontsov <cbou@mail.ru>
Cc: Sangbeom Kim <sbkim73@samsung.com>
Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Eric Van Hensbergen <ericvh@gmail.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Petr Vandrovec <petr@vandrovec.name>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Avi Kivity <avi@redhat.com> 

Fix regulator kernel-doc warnings:

Warning(drivers/regulator/core.c:2308): No description found for parameter 'rdev'
Warning(drivers/regulator/core.c:2308): Excess function parameter 'regulator' description in 'regulator_set_voltage_time_sel'
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Cc:	Liam Girdwood <lrg@ti.com>
Cc:	Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Commit 65f73508 ("regulator: core: Add core support for GPIO controlled
enable lines") introduced enable gpio entry in regulator configuration
structure. Some drivers use '-1' as a placeholder for marking that such
gpio line is not available, because '0' is considered as a valid gpio
number. This patch fixes initialization of such drivers (like MAX8952
on UniversalC210 board), when '-1' is provided as enable gpio pin in the
regulator's platform data.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

If the regulator doesn't supply a way of reading back the voltage but does
provide a list_voltage() operation then use that with a selector of zero
to read the voltage.  Regulators doing this means that we have the list
operation there for consumers that want to configure themselves.
Reported-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This prevents the output of just

	dummy:

in the boot log. Now it says:

	regulator-dummy: no parameters

which at least doesn't make it look like an accidental printk and also doesn't
only use "dummy" which could mean anything.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This is to address the following warning during compilation time: (Compile on x86_64)

  CC      drivers/regulator/core.o
drivers/regulator/core.c: In function '_regulator_do_set_voltage':
drivers/regulator/core.c:2183:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]

This patch adds a temporary variable to avoid double cast.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

When registering the regulator and setting supply for the regulator
then increment open_count to reflect correct number of users.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This is in preparation for teaching async_synchronize_full() to sync all
pending async work, and not just on the async_running domain.  This
conversion is functionally equivalent, just embedding the existing list
in a new async_domain type.

The .registered attribute is used in a later patch to distinguish
between domains that want to be flushed by async_synchronize_full()
versus those that only expect async_synchronize_{full|cookie}_domain to
be used for flushing.

[jejb: add async.h to scsi_priv.h for struct async_domain]
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Acked-by: NArjan van de Ven <arjan@linux.intel.com>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Tested-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

REGULATOR_STATUS_UNDEFINED is to be returned by regulator, if any other state
doesn't really apply.
Signed-off-by: NKrystian Garbaciak <krystian.garbaciak@diasemi.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Case REGULATOR_STATUS_STANDBY -> REGULATOR_MODE_STANDBY.
Signed-off-by: NKrystian Garbaciak <krystian.garbaciak@diasemi.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Since DT doesn't provide an idiomatic mechanism for enabling full
constraints and since it's much more natural with DT to provide them
just assume that a DT enabled system has full constraints.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

With changes introduced by commit 222cc7b1 (regulator: core: Allow
multiple requests of a single supply mapping) on create_regulator,
regulator_put needs a corresponding update on sysfs entry removing.

Also regulator->dev still needs to get assigned in create_regulator,
otherwise, sysfs_remove_link call in regulator_put will get bypassed.
Reported-by: NFabio Estevam <festevam@gmail.com>
Tested-by: NDong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

It is very common for regulators to support having their enable signal
controlled by a GPIO. Since there are a bunch of fiddly things to get
right like handling the operations when the enable signal is tied to
a rail and it's just replicated code add support for this to the core.

Drivers should set ena_gpio in their config if they have a GPIO control,
using ena_gpio_flags to specify any flags (including GPIOF_OUT_INIT_ for
the initial state) and ena_gpio_invert if the GPIO is active low. The
core will then override any enable and disable operations the driver has
and instead control the specified GPIO.

This will in the future also allow us to further extend the core by
identifying when several enable signals have been tied together and
handling this properly.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Create new _regulator_do_enable() and _regulator_do_disable() operations
which deal with the mechanics of performing the enable and disable, partly
to cut down on the levels of indentation and partly to support some future
work.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Many regulators have a fixed specification for their enable time. Allow
this to be set in the regulator_desc as a number to save them having to
implement an explicit operation.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Lots of regulator drivers have checks in their map_voltage() functions
to verify that the result of the mapping is in the range originally
specified. Factor these out in the core and provide a bit of extra
defensiveness for other drivers by doing the check in the core.

Since we're now doing a list_voltage() earlier move the current mapping
back to a voltage out into the set_voltage() call to save redoing it.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Currently regulator_is_supported_voltage() works by enumerating the set
of voltages which can be set by the regulator but the checks we're doing
to impose constraints mean that if we can't vary the voltage we'll not
report any voltages as supported even though the regulator is actually
set at that voltage.

We could fix the voltage listing but this would mean that list_voltage()
could end up going to the hardware to get the current voltage which isn't
expected (it's supposed to be very cheap) so instead special case things
when we can't change the voltage and compare the requested range against
the current voltage.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

A recursive lockdep warning occurs if you call
regulator_set_optimum_mode() on a regulator with a supply because
there is no nesting annotation for the rdev->mutex. To avoid this
warning, get the supply's load before locking the regulator's
mutex to avoid grabbing the same class of lock twice.

=============================================
[ INFO: possible recursive locking detected ]
3.4.0 #3257 Tainted: G        W
---------------------------------------------
swapper/0/1 is trying to acquire lock:
 (&rdev->mutex){+.+.+.}, at: [<c036e9e0>] regulator_get_voltage+0x18/0x38

but task is already holding lock:
 (&rdev->mutex){+.+.+.}, at: [<c036ef38>] regulator_set_optimum_mode+0x24/0x224

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&rdev->mutex);
  lock(&rdev->mutex);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

3 locks held by swapper/0/1:
 #0:  (&__lockdep_no_validate__){......}, at: [<c03dbb48>] __driver_attach+0x40/0x8c
 #1:  (&__lockdep_no_validate__){......}, at: [<c03dbb58>] __driver_attach+0x50/0x8c
 #2:  (&rdev->mutex){+.+.+.}, at: [<c036ef38>] regulator_set_optimum_mode+0x24/0x224

stack backtrace:
[<c001521c>] (unwind_backtrace+0x0/0x12c) from [<c00cc4d4>] (validate_chain+0x760/0x1080)
[<c00cc4d4>] (validate_chain+0x760/0x1080) from [<c00cd744>] (__lock_acquire+0x950/0xa10)
[<c00cd744>] (__lock_acquire+0x950/0xa10) from [<c00cd990>] (lock_acquire+0x18c/0x1e8)
[<c00cd990>] (lock_acquire+0x18c/0x1e8) from [<c080c248>] (mutex_lock_nested+0x68/0x3c4)
[<c080c248>] (mutex_lock_nested+0x68/0x3c4) from [<c036e9e0>] (regulator_get_voltage+0x18/0x38)
[<c036e9e0>] (regulator_get_voltage+0x18/0x38) from [<c036efb8>] (regulator_set_optimum_mode+0xa4/0x224)
...
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

commit 222cc7b1 (regulator: core: Allow multiple requests of a single supply mapping)
removed the usage of get_device_regulator().

Remove the function definition too amd get rid of the following warning:

drivers/regulator/core.c:112:26: warning: 'get_device_regulator' defined but not used [-Wunused-function]
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Sometimes it may be useful to allow a device to request a supply multiple
times, for example in order to allow framework management of some uses of
the supply with some additional driver specific management or in order to
allow multiple children of an MFD to work with the supply. Currently this
is not possible due to the creation of

Solve this by removing the requested_uA entry (we have no current users
of this feature anyway) and ignoring errors creating the symlink to the
consumer. We should do something nicer than this as this causes sysfs to
spew enormous warnings but it allows users to run for now.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

There is no need to consider waiting for the voltage to ramp if we
didn't manage to set it and looking at the return value is going to be
cheaper than is_enabled().
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

With this change, regulator_set_voltage_time_sel() can be more generic and not
limited to linear and table based mapping now.
One side-effect of this change is that list_voltage() must be implemented.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This change makes it possible to set ramp_delay with 0.xxx mV/uS without
truncation issue.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

For table based mapping, we can calculate voltage difference by below equation:
abs(rdev->desc->volt_table[new_selector] - rdev->desc->volt_table[old_selector])

Thus we can make regulator_set_voltage_time_sel work for table based mapping.

regulator_set_voltage_time_sel() only supports linear or table based mapping.
In case it is misused, also warn if neither linear nor table based mapping
is used with regulator_set_voltage_time_sel().
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

For some hardwares ramp_delay for BUCKs is a configurable parameter which can
be configured through DT or board file.This patch adds ramp_delay to regulator
constraints and allow user to configure it for regulators which supports this
feature, through DT or board file. It will provide two ways of setting the
ramp_delay for a regulator:
	First, by setting it as constraints in board file(for configurable
regulators) and set_machine_constraints() will take care of setting it on
hardware by calling(the provided) .set_ramp_delay() operation(callback).
	Second, by setting it as data in regulator_desc(as fixed/default
ramp_delay rate) for a regulator in driver.

regulator_set_voltage_time_sel() will give preference to
constraints->ramp_delay while reading ramp_delay rate for regulator. Similarly
users should also take care accordingly while refering ramp_delay rate(in case
of implementing their private .set_voltage_time_sel() callbacks for different
regulators).

[Rewrote subject for 80 columns -- broonie]
Signed-off-by: NYadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

minor optimization: move delay code to where delay is set and
thus where it is used vs in the main line path.
Signed-off-by: NPhilip Rakity <prakity@marvell.com>
Acked-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The voltage being set should be passed to the call in handler
requesting the callback.  Currently this is not done.

The calling handler cannot call regulator_get_voltage() to get the
information since the mutex is held by the regulator and
deadlock occurs.

Without this change the receiver of the call in cannot know what
action to take.  This is used, for example, to set PAD voltages
when doing SD vccq voltage changes.

[Review and spelling fix in the commit log from Pankaj Jangra]
Signed-off-by: NPhilip Rakity <prakity@marvell.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Reported-by: NPankaj Jangra <jangra.pankaj9@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

rdev->desc->uV_step * abs(new_selector - old_selector) returns uV.
The unit of ramp_delay is mV/us.

Current code multiples 1000 at wrong place.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>