Make it easier to identify regulator consumers when consumer device
uses more than one supply.

Before:

  regulator                      ena use open bypass voltage current min     max
 -----------------------------------------------------------------------------------
  regulator-dummy                  1   0    2      0     0mV     0mA 0mV     0mV
     1-0010                                                          0mV     0mV
     1-0010                                                          0mV     0mV

After:

  regulator                      ena use open bypass voltage current min     max
 -----------------------------------------------------------------------------------
  regulator-dummy                  1   0    2      0     0mV     0mA 0mV     0mV
     1-0010-vccio                                                    0mV     0mV
     1-0010-vcc33                                                    0mV     0mV
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/731a4b299c6ae0ee9d8995157600a3477f21a36c.1585959068.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

With current code:
	st-gyro-i2c i2c-PRP0001:00: i2c-PRP0001:00 supply vdd not found, using dummy regulator

which looks a bit oververbose.

Replace this with simplified format string for the above case, and drop
"deviceless" case since for all dev_*() macros used in _regulator_get()
the "(null)" will be printed anyway.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200312183245.1612-1-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

The regulator_init_complete_work logic defers the cleanup for an
arbitrary 30 seconds of time to allow modules loaded by userland
to start.

This arbitrary timeout is similar to the
driver_deferred_probe_timeout value, and its been suggested we
align these so users have a method to extend the timeouts as
needed.

So this patch changes the logic to use the
driver_deferred_probe_timeout value for the delay value if it
is set (using a delay of 0 if it is not).

Cc: linux-pm@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Saravana Kannan <saravanak@google.com>
Cc: Todd Kjos <tkjos@google.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Kevin Hilman <khilman@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Rob Herring <robh@kernel.org>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Link: https://lore.kernel.org/r/20200225050828.56458-7-john.stultz@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Change the exported symbols introduced by commit e9153311
("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage")
from EXPORT_SYMBOL() to EXPORT_SYMBOL_GPL(), like is used for all the core
parts.

Fixes: e9153311 ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage")
Reported-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20200120123921.1204339-1-enric.balletbo@collabora.comSigned-off-by: NMark Brown <broonie@kernel.org>

`cat /sys/kernel/debug/regulator/regulator_summary` ends on a deadlock
when you have a voltage controlled regulator (vctrl).

The problem is that the vctrl_get_voltage() and vctrl_set_voltage() calls the
regulator_get_voltage() and regulator_set_voltage() and that will try to lock
again the dependent regulators (the regulator supplying the control voltage).

Fix the issue by exporting the unlocked version of the regulator_get_voltage()
and regulator_set_voltage() API so drivers that need it, like the voltage
controlled regulator driver can use it.

Fixes: f8702f9e ("regulator: core: Use ww_mutex for regulators locking")
Reported-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20200116094543.2847321-1-enric.balletbo@collabora.comSigned-off-by: NMark Brown <broonie@kernel.org>

Inside machine_constraints_voltage() a loop is in charge of verifying that
each of the defined voltages are within the configured constraints and
that those constraints are in fact compatible with the available voltages'
list.

When the registered regulator happens to be defined with a wide range of
possible voltages the above O(n) loop can be costly.
Moreover since this behaviour is triggered during the registration process,
it means also that it can be easily triggered at probe time, slowing down
considerably some module loading.

On the other side if such wide range of voltage values happens to be also
continuous and without discontinuity of any kind, the above potentially
cumbersome operation is also useless.

For these reasons, avoid such .list_voltage poll loop when regulator is
described as 'continuous_voltage_range' as is, indeed, similarly already
done inside regulator_is_supported_voltage().
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20191209125239.46054-1-cristian.marussi@arm.comSigned-off-by: NMark Brown <broonie@kernel.org>

There are several issues with the error handling code of
the regulator_register() function:
        ret = device_register(&rdev->dev);
        if (ret != 0) {
                put_device(&rdev->dev); --> rdev released
                goto unset_supplies;
        }
...
unset_supplies:
...
        unset_regulator_supplies(rdev); --> use-after-free
...
clean:
        if (dangling_of_gpiod)
                gpiod_put(config->ena_gpiod);
        kfree(rdev);                     --> double free

We add a variable to record the failure of device_register() and
move put_device() down a bit to avoid the above issues.

Fixes: c438b9d0 ("regulator: core: Move registration of regulator device")
Signed-off-by: NWen Yang <wenyang@linux.alibaba.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/20191201030250.38074-1-wenyang@linux.alibaba.comSigned-off-by: NMark Brown <broonie@kernel.org>

This is caused by dereferencing 'rdev' after put_device() in
the _regulator_get()/_regulator_put() functions.
This patch just moves the put_device() down a bit to avoid the
issue.
Signed-off-by: NWen Yang <wenyang@linux.alibaba.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/20191124145835.25999-1-wenyang@linux.alibaba.comSigned-off-by: NMark Brown <broonie@kernel.org>

Boot-on regulators are always kept on because their use_count value
is now incremented at boot time and never cleaned.

Only increment count value for alway-on regulators.
regulator_late_cleanup() is now able to power off boot-on regulators
when unused.

Fixes: 05f224ca ("regulator: core: Clean enabling always-on regulators + their supplies")
Signed-off-by: NPascal Paillet <p.paillet@st.com>
Link: https://lore.kernel.org/r/20191113102737.27831-1-p.paillet@st.comSigned-off-by: NMark Brown <broonie@kernel.org>

device_link_add() might not always succeed depending on the type of
device link and the rest of the dependencies in the system. If
device_link_add() didn't succeed, then we shouldn't try to remove the
link later on as it might remove a link someone else created.
Signed-off-by: NSaravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20191115000438.45970-1-saravanak@google.comSigned-off-by: NMark Brown <broonie@kernel.org>

The generic voltage balancer doesn't work correctly if one of regulator
couples turns off. Currently there are no users in kernel for that case,
although let's explicitly show that this case is unsupported for those who
will try to use that feature.

Link: https://lore.kernel.org/linux-samsung-soc/20191008170503.yd6GscYPLxjgrXqDuCO7AJc6i6egNZGJkVWHLlCxvA4@z/Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20191025002240.25288-2-digetx@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

This patch fixes memory leak which should happen if regulator's coupling
fails to initialize.

Fixes: d8ca7d18 ("regulator: core: Introduce API for regulators coupling customization")
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20191025002240.25288-1-digetx@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Sometimes it can happen that the regulator_of_get_init_data() can't
retrieve the config due to a not probed device the regulator depends on.
Fix that by checking the return value of of_parse_cb() and return
EPROBE_DEFER in such cases.
Signed-off-by: NMarco Felsch <m.felsch@pengutronix.de>
Link: https://lore.kernel.org/r/20190917154021.14693-4-m.felsch@pengutronix.deSigned-off-by: NMark Brown <broonie@kernel.org>

regulator_uV_show() is missing error handling if regulator_get_voltage_rdev()
returns negative values. Instead it prints the errno as a string, e.g. -EINVAL
as "-22" which could be interpreted as -22 µV.

We also do not need to hold the lock while converting the integer to a string.
Reported-by: NAdam Ford <aford173@gmail.com>
Signed-off-by: NH. Nikolaus Schaller <hns@goldelico.com>
Tested-by: NAdam Ford <aford173@gmail.com>
Link: https://lore.kernel.org/r/f37f2a1276efcb34cf3b7f1a25481175be048806.1568143348.git.hns@goldelico.comSigned-off-by: NMark Brown <broonie@kernel.org>

The kernel has no way of knowing when we have finished instantiating
drivers, between deferred probe and systems that build key drivers as
modules we might be doing this long after userspace has booted. This has
always been a bit of an issue with regulator_init_complete since it can
power off hardware that's not had it's driver loaded which can result in
user visible effects, the main case is powering off displays. Practically
speaking it's not been an issue in real systems since most systems that
use the regulator API are embedded and build in key drivers anyway but
with Arm laptops coming on the market it's becoming more of an issue so
let's do something about it.

In the absence of any better idea just defer the powering off for 30s
after late_initcall(), this is obviously a hack but it should mask the
issue for now and it's no more arbitrary than late_initcall() itself.
Ideally we'd have some heuristics to detect if we're on an affected
system and tune or skip the delay appropriately, and there may be some
need for a command line option to be added.

Link: https://lore.kernel.org/r/20190904124250.25844-1-broonie@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>
Tested-by: NLee Jones <lee.jones@linaro.org>
Cc: stable@vger.kernel.org

In function of_get_child_regulator(), the loop for_each_child_of_node()
contains two mid-loop return statements, each preceded by a statement
putting child. In order to reduce this repetition, create a new label,
err_node_put, that puts child and then returns the required value;
edit the mid-loop return blocks to instead go to this new label.
Signed-off-by: NNishka Dasgupta <nishkadg.linux@gmail.com>
Link: https://lore.kernel.org/r/20190815053704.32156-1-nishkadg.linux@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Each iteration of for_each_child_of_node puts the previous node, but in
the case of a return from the middle of the loop, there is no put, thus
causing a memory leak. Hence add an of_node_put before the return in
two places.
Issue found with Coccinelle.
Signed-off-by: NNishka Dasgupta <nishkadg.linux@gmail.com>
Link: https://lore.kernel.org/r/20190804162023.5673-1-nishkadg.linux@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Some regulators require that the requested voltage be reached gradually
by setting all or some of the intermediate values. Implement a new field
in the regulator description struct that allows users to specify the
number of selectors by which the regulator API should step when ramping
the voltage up/down.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20190703161035.31808-2-brgl@bgdev.plSigned-off-by: NMark Brown <broonie@kernel.org>

Expose some of internal functions that are required for implementation of
customized regulator couplers.
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Right now regulator core supports only one type of regulators coupling,
the "voltage max-spread" which keeps voltages of coupled regulators in a
given range from each other. A more sophisticated coupling may be required
in practice, one example is the NVIDIA Tegra SoCs which besides the
max-spreading have other restrictions that must be adhered. Introduce API
that allow platforms to provide their own customized coupling algorithms.
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Makes things look more consistent.
Signed-off-by: NMark Brown <broonie@kernel.org>

The conversion here is really trivial: just a bunch of title
markups and very few puntual changes is enough to make it to
be parsed by Sphinx and generate a nice html.

The conversion is actually:
  - add blank lines and identation in order to identify paragraphs;
  - fix tables markups;
  - add some lists markups;
  - mark literal blocks;
  - adjust title markups.

At its new index.rst, let's add a :orphan: while this is not linked to
the main index.rst file, in order to avoid build warnings.
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation either version 2 of the license or at
  your option any later version

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 3029 file(s).
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NAllison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The logic is equivalent, but it looks more straightforward this way:
If rdev->desc->ops->enable_time is set, call it.
Otherwise fallback to return rdev->desc->enable_time.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

All the current clients of this API  assume that 0 corresponds
to a failure and non-zero to a pass therefore ignoring the need to
handle a negative error code.

This commit modifies the API to follow that standard since returning a
negative (EINVAL) doesn't seem to provide enough value to justify
the need to handle it.
Signed-off-by: NJorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Temporary failures to get a regulator (EPROBE_DEFER) should be logged
as debug information instead of errors.
Signed-off-by: NJorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

I went to great lengths to hand over the management of the GPIO
descriptors to the regulator core, and some stray rebased
oneliner in the old patch must have been assuming the devices
were still doing devres management of it.

We handed the management over to the regulator core, so of
course the regulator core shall issue gpiod_put() when done.

Sorry for the descriptor leak.

Fixes: 541d052d ("regulator: core: Only support passing enable GPIO descriptors")
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Lockdep reports the following issue on my setup:

Possible unsafe locking scenario:

CPU0                    CPU1
----                    ----
lock((work_completion)(&(&rdev->disable_work)->work));
                        lock(regulator_list_mutex);
                        lock((work_completion)(&(&rdev->disable_work)->work));
lock(regulator_list_mutex);

The problem is that regulator_unregister takes the
regulator_list_mutex and then calls flush_work on disable_work. But
regulator_disable_work calls regulator_lock_dependent which will
also take the regulator_list_mutex. Resulting in a deadlock if the
flush_work call actually needs to flush the work.

Fix this issue by moving the flush_work outside of the
regulator_list_mutex. The list mutex is not used to guard the point at
which the delayed work is queued, so its use adds no additional safety.

Fixes: f8702f9e ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

During several error paths in the function
regulator_set_voltage_unlocked() the value of 'ret' can take on negative
error values. However, in calls that go through the 'goto out' statement,
this return value is lost and return 0 is used instead, indicating a
'pass'.

There are several cases where this function should legitimately return a
fail instead of a pass: one such case includes constraints check during
voltage selection in the call to regulator_check_voltage(), which can
have -EINVAL for the case when an unsupported voltage is incorrectly
requested. In that case, -22 is expected as the return value, not 0.

Fixes: 9243a195 ("regulator: core: Change voltage setting path")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NSteve Twiss <stwiss.opensource@diasemi.com>
Reviewed-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

[The original commit was sent against -next but needed to be sent as a
bugfix, however -next had some additional changes which needed to be
reverted.  Now everything is all in one branch applying the rest of the
changes to fix up the merge issue -- broonie]

commit e5e21f70 ("regulator: core: Take lock before applying system
load") took the regulator lock before calling drms_uA_update() in order
to silence a lockdep warning during regulator_register().

However, we are not supposed to need locks at this point as the regulator
is in the process of being registered, so there should be no possibility
of concurrent access.

Instead, remove the unnecessary locking and simply drop the lockdep
annotation, since it is no longer valid.

Fixes: e5e21f70 ("regulator: core: Take lock before applying system load")
Signed-off-by: NNiklas Cassel <niklas.cassel@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

When REGULATOR_CHANGE_DRMS is not set, drms_uA_update is a no-op.
It used to print a debug message, which was dropped in commit
8a34e979 ("regulator: refactor valid_ops_mask checking code")

Let's bring the debug message back, because it helps find missing
regulator-allow-set-load properties.
Signed-off-by: NMarc Gonzalez <marc.w.gonzalez@free.fr>
Signed-off-by: NMark Brown <broonie@kernel.org>

commit e5e21f70 ("regulator: core: Take lock before applying system
load") took the regulator lock before calling drms_uA_update() in order
to silence a lockdep warning during regulator_register().

However, we are not supposed to need locks at this point as the regulator
is in the process of being registered, so there should be no possibility
of concurrent access.

Instead, remove the unnecessary locking and simply drop the lockdep
annotation, since it is no longer valid.

Fixes: e5e21f70 ("regulator: core: Take lock before applying system load")
Signed-off-by: NNiklas Cassel <niklas.cassel@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

This is a remnant of commit 70a7fb80 ("regulator: core: Fix nested
locking of supplies").
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Take the regulator lock before applying system load.

Fixes the following lockdep splat:

[    5.583581] WARNING: CPU: 1 PID: 16 at drivers/regulator/core.c:925 drms_uA_update+0x114/0x360
[    5.588467] Modules linked in:
[    5.596833] CPU: 1 PID: 16 Comm: kworker/1:0 Not tainted 5.0.0-rc6-next-20190213-00002-g0fce66ab480f #18
[    5.599933] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
[    5.609544] Workqueue: events qcom_channel_state_worker
[    5.616209] pstate: 60000005 (nZCv daif -PAN -UAO)
[    5.621152] pc : drms_uA_update+0x114/0x360
[    5.626006] lr : drms_uA_update+0x110/0x360
[    5.630084] sp : ffff0000124b3490
[    5.634242] x29: ffff0000124b3490 x28: ffff800005326e00
[    5.637735] x27: ffff0000124b35f8 x26: 000000000032bc48
[    5.643117] x25: ffff800004c7e800 x24: ffff800004c6d500
[    5.648411] x23: ffff800004c38a80 x22: 00000000000000d1
[    5.653706] x21: 00000000001ab3f0 x20: ffff800004c7e800
[    5.659001] x19: ffff0000114c3000 x18: ffffffffffffffff
[    5.664297] x17: 0000000000000000 x16: 0000000000000000
[    5.669592] x15: ffff0000114c3808 x14: 0720072007200720
[    5.674888] x13: 00000000199c9b28 x12: ffff80002bcccc40
[    5.680183] x11: ffff000012286000 x10: ffff0000114c3808
[    5.685477] x9 : 0720072007200720 x8 : ffff000010e9e808
[    5.690772] x7 : ffff0000106da568 x6 : 0000000000000000
[    5.696067] x5 : 0000000000000000 x4 : 0000000000000000
[    5.701362] x3 : 0000000000000004 x2 : 0000000000000000
[    5.706658] x1 : 0000000000000000 x0 : 0000000000000000
[    5.711952] Call trace:
[    5.717223]  drms_uA_update+0x114/0x360
[    5.719405]  regulator_register+0xb30/0x1140
[    5.723230]  devm_regulator_register+0x4c/0xa8
[    5.727745]  rpm_reg_probe+0xfc/0x1b0
[    5.731992]  platform_drv_probe+0x50/0xa0
[    5.735727]  really_probe+0x20c/0x2b8
[    5.739718]  driver_probe_device+0x58/0x100
[    5.743368]  __device_attach_driver+0x90/0xd0
[    5.747363]  bus_for_each_drv+0x64/0xc8
[    5.751870]  __device_attach+0xd8/0x138
[    5.755516]  device_initial_probe+0x10/0x18
[    5.759341]  bus_probe_device+0x98/0xa0
[    5.763502]  device_add+0x3d0/0x640
[    5.767319]  of_device_add+0x48/0x58
[    5.770793]  of_platform_device_create_pdata+0xb0/0x128
[    5.774629]  of_platform_bus_create+0x174/0x370
[    5.779569]  of_platform_populate+0x78/0xe0
[    5.784082]  qcom_smd_rpm_probe+0x80/0xa0
[    5.788245]  rpmsg_dev_probe+0x114/0x1a0
[    5.792411]  really_probe+0x20c/0x2b8
[    5.796401]  driver_probe_device+0x58/0x100
[    5.799964]  __device_attach_driver+0x90/0xd0
[    5.803960]  bus_for_each_drv+0x64/0xc8
[    5.808468]  __device_attach+0xd8/0x138
[    5.812115]  device_initial_probe+0x10/0x18
[    5.815936]  bus_probe_device+0x98/0xa0
[    5.820099]  device_add+0x3d0/0x640
[    5.823916]  device_register+0x1c/0x28
[    5.827391]  rpmsg_register_device+0x4c/0x90
[    5.831216]  qcom_channel_state_worker+0x170/0x298
[    5.835651]  process_one_work+0x294/0x6e8
[    5.840241]  worker_thread+0x40/0x450
[    5.844318]  kthread+0x11c/0x120
[    5.847961]  ret_from_fork+0x10/0x18
[    5.851260] irq event stamp: 9090
[    5.854820] hardirqs last  enabled at (9089): [<ffff000010160798>] console_unlock+0x3e0/0x5b0
[    5.858086] hardirqs last disabled at (9090): [<ffff0000100817cc>] do_debug_exception+0x104/0x140
[    5.866596] softirqs last  enabled at (9086): [<ffff000010082024>] __do_softirq+0x474/0x574
[    5.875446] softirqs last disabled at (9079): [<ffff0000100f2254>] irq_exit+0x13c/0x148
[    5.883598] ---[ end trace 6984ef7f081afa21 ]---

Fixes: fa94e48e ("regulator: core: Apply system load even if no consumer loads")
Signed-off-by: NNiklas Cassel <niklas.cassel@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Device links are refcounted, device_link_remove() has to be called as
many times as device_link_add().
Signed-off-by: NGuennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Now that we changed all providers to pass descriptors into the core
for enable GPIOs instead of a global GPIO number, delete the support
for passing GPIO numbers in, and we get a cleanup and size reduction
in the core, and from a GPIO point of view we use the modern, cleaner
interface.
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

This pushes the handling of inversion semantics and open drain
settings to the GPIO descriptor and gpiolib. All affected board
files are also augmented.

This is especially nice since we don't have to have any
confusing flags passed around to the left and right littering
the fixed and GPIO regulator drivers and the regulator core.
It is all just very straight-forward: the core asks the GPIO
line to be asserted or deasserted and gpiolib deals with the
rest depending on how the platform is configured: if the line
is active low, it deals with that, if the line is open drain,
it deals with that too.

Cc: Alexander Shiyan <shc_work@mail.ru> # i.MX boards user
Cc: Haojian Zhuang <haojian.zhuang@gmail.com> # MMP2 maintainer
Cc: Aaro Koskinen <aaro.koskinen@iki.fi> # OMAP1 maintainer
Cc: Tony Lindgren <tony@atomide.com> # OMAP1,2,3 maintainer
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com> # EM-X270 maintainer
Cc: Robert Jarzmik <robert.jarzmik@free.fr> # EZX maintainer
Cc: Philipp Zabel <philipp.zabel@gmail.com> # Magician maintainer
Cc: Petr Cvek <petr.cvek@tul.cz> # Magician
Cc: Robert Jarzmik <robert.jarzmik@free.fr> # PXA
Cc: Paul Parsons <lost.distance@yahoo.com> # hx4700
Cc: Daniel Mack <zonque@gmail.com> # Raumfeld maintainer
Cc: Marc Zyngier <marc.zyngier@arm.com> # Zeus maintainer
Cc: Geert Uytterhoeven <geert+renesas@glider.be> # SuperH pinctrl/GPIO maintainer
Cc: Russell King <rmk+kernel@armlinux.org.uk> # SA1100
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> #OMAP1 Amstrad Delta
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Provide a helper allowing to access regulator's regmap.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Fix few trivial language typos in core and drivers.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: NYangtao Li <tiny.windzz@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>