The only usage of tps51632_dcdc_ops is to assign its address to the ops
field in the regulator_desc struct, which is a const pointer. Make it
const to allow the compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200829221104.20870-2-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The recent commit 7d8196641e ("regulator: Remove pointer table
overallocation") changed the size of coupled_rdevs and now KASAN is able
to detect slab-out-of-bounds problem in regulator_unlock_recursive(),
which is a legit problem caused by a typo in the code. The recursive
unlock function uses n_coupled value of a parent regulator for unlocking
supply regulator, while supply's n_coupled should be used. In practice
problem may only affect platforms that use coupled regulators.
Cc: stable@vger.kernel.org # 5.0+
Fixes: f8702f9e4a ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20200831204335.19489-1-digetx@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
As Rob suggested, use the "mps,switch-frequency-hz" instead of the
"mps,switch-frequency" for switch frequency. Fortunately, the switch
frequency support isn't released, so we can modify it now without
any concern.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200824102402.4047fa5f@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
The following build warning is seen after commit 8bdaa43808 ("regulator:
dbx500: no need to check return value of debugfs_create functions"):
drivers/regulator/dbx500-prcmu.c:144:1: warning: label 'exit_no_debugfs' defined but not used [-Wunused-label]
Remove the unused label and its associated error message.
Fixes: 8bdaa43808 ("regulator: dbx500: no need to check return value of debugfs_create functions")
Reported-by: Olof's autobuilder <build@lixom.net>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20200821144823.13404-1-festevam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/tps65023-regulator.c:319:34: warning: ‘tps65023_of_match’ defined but not used [-Wunused-const-variable=]
319 | static const struct of_device_id tps65023_of_match[] = {
| ^~~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821112009.58ee8511@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/qcom-rpmh-regulator.c:970:34: warning: ‘rpmh_regulator_match_table’ defined but not used [-Wunused-const-variable=]
970 | static const struct of_device_id rpmh_regulator_match_table[] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111913.1096f7cc@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/sy8106a-regulator.c:126:34: warning: ‘sy8106a_i2c_of_match’ defined but not used [-Wunused-const-variable=]
126 | static const struct of_device_id sy8106a_i2c_of_match[] = {
| ^~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111820.5c6ddb04@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/stm32-pwr.c:169:34: warning: ‘stm32_pwr_of_match’ defined but not used [-Wunused-const-variable=]
169 | static const struct of_device_id stm32_pwr_of_match[] = {
| ^~~~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111726.38e0e746@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/pwm-regulator.c:393:34: warning: ‘pwm_of_match’ defined but not used [-Wunused-const-variable=]
393 | static const struct of_device_id pwm_of_match[] = {
| ^~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111658.59a7218b@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/max77826-regulator.c:277:34: warning: ‘max77826_of_match’ defined but not used [-Wunused-const-variable=]
277 | static const struct of_device_id max77826_of_match[] = {
| ^~~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111631.4e799c86@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/max1586.c:204:34: warning: ‘max1586_of_match’ defined but not used [-Wunused-const-variable=]
204 | static const struct of_device_id max1586_of_match[] = {
| ^~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111601.26243417@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/ltc3676.c:371:34: warning: ‘ltc3676_of_match’ defined but not used [-Wunused-const-variable=]
371 | static const struct of_device_id ltc3676_of_match[] = {
| ^~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111517.59d7b8c8@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/ltc3589.c:460:34: warning: ‘ltc3589_of_match’ defined but not used [-Wunused-const-variable=]
460 | static const struct of_device_id ltc3589_of_match[] = {
| ^~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111449.7cf580f2@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warnings when CONFIG_OF=n:
drivers/regulator/fixed.c:48:36: warning: ‘fixed_clkenable_data’ defined but not used [-Wunused-const-variable=]
48 | static const struct fixed_dev_type fixed_clkenable_data = {
| ^~~~~~~~~~~~~~~~~~~~
drivers/regulator/fixed.c:44:36: warning: ‘fixed_voltage_data’ defined but not used [-Wunused-const-variable=]
44 | static const struct fixed_dev_type fixed_voltage_data = {
| ^~~~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111403.3e8b58a3@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/fan53555.c:439:34: warning: ‘fan53555_dt_ids’ defined but not used [-Wunused-const-variable=]
439 | static const struct of_device_id fan53555_dt_ids[] = {
| ^~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111324.430fe1da@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/da9210-regulator.c:128:34: warning: ‘da9210_dt_ids’ defined but not used [-Wunused-const-variable=]
128 | static const struct of_device_id da9210_dt_ids[] = {
| ^~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/20200821111235.14473a88@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/88pg86x.c:87:34: warning: ‘pg86x_dt_ids’ defined but not used [-Wunused-const-variable=]
87 | static const struct of_device_id pg86x_dt_ids [] = {
| ^~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111210.0a0bed94@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/20200818133701.462958-1-gregkh@linuxfoundation.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This allows the regulator to be found by devm_regulator_get().
Fixes: 4fe66d5a62 ("regulator: Add support for QCOM PMIC VBUS booster")
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Link: https://lore.kernel.org/r/20200818162508.5246-1-jonathan@marek.ca
Signed-off-by: Mark Brown <broonie@kernel.org>
Jisheng Zhang <Jisheng.Zhang@synaptics.com>:
From: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
This is to improve the mp886x regulator driver support.
patch1 implments .set_ramp_delay
patch2 and patch3 support the switch freq setting
patch4 converts dt binding to json-schema
Since v2:
- put any schema conversions at the end of the series as Mark
suggested.
Jisheng Zhang (4):
regulator: mp886x: implement set_ramp_delay
dt-bindings: regulator: mp886x: support mps,switch-frequency
regulator: mp886x: support setting switch freq
dt-bindings: regulator: Convert mp886x to json-schema
.../devicetree/bindings/regulator/mp886x.txt | 27 -----
.../bindings/regulator/mps,mp886x.yaml | 58 ++++++++++
drivers/regulator/mp886x.c | 109 +++++++++++++++++-
3 files changed, 164 insertions(+), 30 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/regulator/mp886x.txt
create mode 100644 Documentation/devicetree/bindings/regulator/mps,mp886x.yaml
--
2.28.0.rc1
For systems that have eg. eMMC storage using voltage regulator, memory
reclaim path might call back into regulator subsystem. This means we
have to make sure no allocations happen with a regulator or regulator
list locked.
After this series I see no more lockdep complaints on my test system,
but please review and test further.
First four patches move allocations out of locked regions, next three
came as a drive-by cleanups.
---
v2: fix bug in patch #4 spotted by kernel test robot
reworded commit #7 description
Michał Mirosław (7):
regulator: push allocation in regulator_init_coupling() outside of
lock
regulator: push allocation in regulator_ena_gpio_request() out of lock
regulator: push allocations in create_regulator() outside of lock
regulator: push allocation in set_consumer_device_supply() out of lock
regulator: plug of_node leak in regulator_register()'s error path
regulator: cleanup regulator_ena_gpio_free()
regulator: remove superfluous lock in regulator_resolve_coupling()
drivers/regulator/core.c | 164 +++++++++++++++++++++------------------
1 file changed, 87 insertions(+), 77 deletions(-)
--
2.20.1
By checking data->pin_ctrl_enable / data->pin_ctrl_hpm flags first, then
use switch-case to improve readability.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20200801054820.134859-1-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This regulator/backlight driver handles the ATTINY88 present on the
RPi 7" touchscreen panel and exposes the power/backlight interfaces.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Eric Anholt <eric@anholt.net>
Cc: Mark Brown <broonie@kernel.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
To: dri-devel@lists.freedesktop.org
Link: https://lore.kernel.org/r/20200809105938.6388-2-marex@denx.de
Signed-off-by: Mark Brown <broonie@kernel.org>
I see it takes about 5us per regulator to grab the lock, check that this
regulator isn't going to do anything for suspend, and then release the
lock. When that is combined with PMICs that have dozens of regulators we
get into a state where we spend a few miliseconds doing a bunch of
locking operations synchronously to figure out that there's nothing to
do. Let's reorganize the code here a bit so that we don't grab the lock
until we're actually going to do something so that suspend is a little
faster.
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Cc: Matthias Kaehlcke <mka@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20200804070837.1084024-1-swboyd@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Fixing W=1 build warning when no support for device tree is there.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200810095753.59ce9f75@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Add regmap_cache to reduce wakeups events of interrupt if regulator is
accessed frequently. This results in saving more power.
Suggested-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/20200812133101.2513317-1-hsinyi@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Adds support for the RT4801 DSV. It has two regulators (DSVP/DSVN) with
an I2C interface. DSVP/DSVN can provide the display panel module for the
positive/negative voltage range from (+/-)4V to (+/-)6V.
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1597461262-25878-1-git-send-email-u0084500@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The code modifies rdev, but locks c_rdev instead. Remove the lock
as this is held together by regulator_list_mutex taken in the caller.
Fixes: f9503385b1 ("regulator: core: Mutually resolve regulators coupling")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/25eb81cefb37a646f3e44eaaf1d8ae8881cfde52.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Since only regulator_ena_gpio_request() allocates rdev->ena_pin, and it
guarantees that same gpiod gets same pin structure, it is enough to
compare just the pointers. Also we know there can be only one matching
entry on the list. Rework the code take advantage of the facts.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/3ff002c7aa3bd774491af4291a9df23541fcf892.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
By calling device_initialize() earlier and noting that kfree(NULL) is
ok, we can save a bit of code in error handling and plug of_node leak.
Fixed commit already did part of the work.
Fixes: 9177514ce3 ("regulator: fix memory leak on error path of regulator_register()")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
Acked-by: Vladimir Zapolskiy <vz@mleia.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/f5035b1b4d40745e66bacd571bbbb5e4644d21a1.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Move all allocations outside of the regulator_lock()ed section.
======================================================
WARNING: possible circular locking dependency detected
5.7.13+ #535 Not tainted
------------------------------------------------------
f2fs_discard-179:7/702 is trying to acquire lock:
c0e5d920 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x2c0
but task is already holding lock:
cb95b080 (&dcc->cmd_lock){+.+.}-{3:3}, at: __issue_discard_cmd+0xec/0x5f8
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
[...]
-> #3 (fs_reclaim){+.+.}-{0:0}:
fs_reclaim_acquire.part.11+0x40/0x50
fs_reclaim_acquire+0x24/0x28
__kmalloc_track_caller+0x54/0x218
kstrdup+0x40/0x5c
create_regulator+0xf4/0x368
regulator_resolve_supply+0x1a0/0x200
regulator_register+0x9c8/0x163c
[...]
other info that might help us debug this:
Chain exists of:
regulator_list_mutex --> &sit_i->sentry_lock --> &dcc->cmd_lock
[...]
Fixes: f8702f9e4a ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/6eebc99b2474f4ffaa0405b15178ece0e7e4f608.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Move another allocation out of regulator_list_mutex-protected region, as
reclaim might want to take the same lock.
WARNING: possible circular locking dependency detected
5.7.13+ #534 Not tainted
------------------------------------------------------
kswapd0/383 is trying to acquire lock:
c0e5d920 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x2c0
but task is already holding lock:
c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (fs_reclaim){+.+.}-{0:0}:
fs_reclaim_acquire.part.11+0x40/0x50
fs_reclaim_acquire+0x24/0x28
kmem_cache_alloc_trace+0x40/0x1e8
regulator_register+0x384/0x1630
devm_regulator_register+0x50/0x84
reg_fixed_voltage_probe+0x248/0x35c
[...]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(fs_reclaim);
lock(regulator_list_mutex);
lock(fs_reclaim);
lock(regulator_list_mutex);
*** DEADLOCK ***
[...]
2 locks held by kswapd0/383:
#0: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
#1: cb70e5e0 (hctx->srcu){....}-{0:0}, at: hctx_lock+0x60/0xb8
[...]
Fixes: 541d052d72 ("regulator: core: Only support passing enable GPIO descriptors")
[this commit only changes context]
Fixes: f8702f9e4a ("regulator: core: Use ww_mutex for regulators locking")
[this is when the regulator_list_mutex was introduced in reclaim locking path]
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/41fe6a9670335721b48e8f5195038c3d67a3bf92.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Allocating memory with regulator_list_mutex held makes lockdep unhappy
when memory pressure makes the system do fs_reclaim on eg. eMMC using
a regulator. Push the lock inside regulator_init_coupling() after the
allocation.
======================================================
WARNING: possible circular locking dependency detected
5.7.13+ #533 Not tainted
------------------------------------------------------
kswapd0/383 is trying to acquire lock:
cca78ca4 (&sbi->write_io[i][j].io_rwsem){++++}-{3:3}, at: __submit_merged_write_cond+0x104/0x154
but task is already holding lock:
c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (fs_reclaim){+.+.}-{0:0}:
fs_reclaim_acquire.part.11+0x40/0x50
fs_reclaim_acquire+0x24/0x28
__kmalloc+0x54/0x218
regulator_register+0x860/0x1584
dummy_regulator_probe+0x60/0xa8
[...]
other info that might help us debug this:
Chain exists of:
&sbi->write_io[i][j].io_rwsem --> regulator_list_mutex --> fs_reclaim
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(fs_reclaim);
lock(regulator_list_mutex);
lock(fs_reclaim);
lock(&sbi->write_io[i][j].io_rwsem);
*** DEADLOCK ***
1 lock held by kswapd0/383:
#0: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
[...]
Fixes: d8ca7d184b ("regulator: core: Introduce API for regulators coupling customization")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/1a889cf7f61c6429c9e6b34ddcdde99be77a26b6.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Both MP8867 and MP8869 support different switch frequency.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200729131023.77cc1dd2@xhacker
Signed-off-by: Mark Brown <broonie@kernel.org>
Implement the .set_ramp_delay for MP8867 and MP8869. MP8867 and MP8869
could share the implementation, the only difference is the slew_rates
array.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200729130913.3ac38b32@xhacker
Signed-off-by: Mark Brown <broonie@kernel.org>
The desc->name field is allocated with devm_kstrdup, but is also kfreed
on the error path, causing it to be double freed. Remove the kfree on
the error path.
Fixes: 8d9f8d57e0 ("regulator: Add driver for cros-ec-regulator")
Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20200728091909.2009771-1-pihsun@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The change corrects registration and deregistration on error path
of a regulator, the problem was manifested by a reported memory
leak on deferred probe:
as3722-regulator as3722-regulator: regulator 13 register failed -517
# cat /sys/kernel/debug/kmemleak
unreferenced object 0xecc43740 (size 64):
comm "swapper/0", pid 1, jiffies 4294937640 (age 712.880s)
hex dump (first 32 bytes):
72 65 67 75 6c 61 74 6f 72 2e 32 34 00 5a 5a 5a regulator.24.ZZZ
5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
backtrace:
[<0c4c3d1c>] __kmalloc_track_caller+0x15c/0x2c0
[<40c0ad48>] kvasprintf+0x64/0xd4
[<109abd29>] kvasprintf_const+0x70/0x84
[<c4215946>] kobject_set_name_vargs+0x34/0xa8
[<62282ea2>] dev_set_name+0x40/0x64
[<a39b6757>] regulator_register+0x3a4/0x1344
[<16a9543f>] devm_regulator_register+0x4c/0x84
[<51a4c6a1>] as3722_regulator_probe+0x294/0x754
...
The memory leak problem was introduced as a side ef another fix in
regulator_register() error path, I believe that the proper fix is
to decouple device_register() function into its two compounds and
initialize a struct device before assigning any values to its fields
and then using it before actual registration of a device happens.
This lets to call put_device() safely after initialization, and, since
now a release callback is called, kfree(rdev->constraints) shall be
removed to exclude a double free condition.
Fixes: a3cde9534e ("regulator: core: fix regulator_register() error paths to properly release rdev")
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Cc: Wen Yang <wenyang@linux.alibaba.com>
Link: https://lore.kernel.org/r/20200724005013.23278-1-vz@mleia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20200719200623.61524-1-grandmaster@al2klimov.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Consider the following example:
- regulator-X is provided by device-X.
- regulator-X is a supplier to device-A, device-B and device-C.
- device-A is off/inactive from boot.
- device-B and device-C are left on/active by the bootloader
- regulator-X is left on boot by the bootloader at 2000 mV to supply
device-B and device-C.
Example boot sequence 1:
1. device-X is probed successfully.
2. device-A is probed by driver-A
a. driver-A gets regulator-X
b. driver-A votes on regulator-X
c. driver-A initializes device-A
d. driver-A votes off regulator-X
e. regulator-X is turned off.
3. System crashes or device-B and device-C become unreliable because
regulator-X was turned off without following the proper quiescing
steps for device-B and device-C.
Example boot sequence 2:
1. device-X is probed successfully.
2. device-B is probed by driver-B
a. driver-B gets regulator-X
b. driver-B votes on regulator-X
c. driver-B lowers device-B performance point.
d. driver-B lowers voltage vote to 1000 mV.
e. regulator-X voltage is lowered to 1000 mV.
3. System crashes or device-C becomes unreliable because regulator-X
voltage was lowered to 1000 mV when device-C still needed it at 2000 mV
This patch series makes sure these examples are handled correctly and
system crash or device instability is avoided and the system remains
usable.
More details provided in the commit texts.
v2->v3:
Patch 2/4 - No functional change. Simple refactor.
Patch 3/4
- Was Patch 2/2 in v2.
- Rewrote commit text to hopefully address all previous points.
- Renamed variable/functions. Hope it's clearer.
- Added more comments.
- Added logging
- Fixed timeout functionality.
- Handle exclusive consumers properly
- Handle coupled regulators properly
Patch 4/4 - Prevents voltage from going too low during boot.
v1->v2:
Patch 1/2
- New patch
Patch 2/2
- This was the only patch in v1
- Made the late_initcall_sync timeout a commandline param
- If timeout is set, we also give up waiting for all consumers after
the timeout expires.
- Made every regulator driver add sync_state() support
Saravana Kannan (4):
driver core: Add dev_set_drv_sync_state()
regulator: core: Add destroy_regulator()
regulator: core: Add basic enable/disable support for sync_state()
callbacks
regulator: core: Add voltage support for sync_state() callbacks
drivers/regulator/core.c | 200 ++++++++++++++++++++++++++++---
include/linux/device.h | 12 ++
include/linux/regulator/driver.h | 2 +
3 files changed, 198 insertions(+), 16 deletions(-)
--
2.28.0.rc0.105.gf9edc3c819-goog
When requesting the enable GPIO, the driver should do so with the
correct output level matching some expected state. This is especially
important if the regulator is a critical one, such as a supply for
the boot CPU. This is currently done by checking for the enable-at-boot
property, but this is not documented in the device tree binding, nor
does it match the common regulator properties.
Honor the common regulator-boot-on property by checking the boot_on
constraint setting within the DT probe path. This is the same as what
is done in the fixed regulator driver.
Also add a comment stating that the enable-at-boot property should not
be used.
Fixes: 006694d099 ("regulator: gpio-regulator: Allow use of GPIO controlled regulators though DT")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20200720132809.26908-1-wens@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Part of the regulator_get() code is already factored out into
create_regulator(). This patch factors out some of the regulator_put()
code into destroy_regulator() so that create_regulator() has a
corresponding unwind function. Subsequent patches will use this
function.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20200716042053.1927676-3-saravanak@google.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Qualcomm platforms have LAB(LCD AMOLED Boost)/IBB(Inverting Buck Boost)
regulators, labibb for short, which are used as power supply for
LCD Mode displays.
This patch adds labibb regulator driver for pmi8998 PMIC, found on
SDM845 platforms.
[sumits: reworked the driver design as per upstream review]
Signed-off-by: Nisha Kumari <nishakumari@codeaurora.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Link: https://lore.kernel.org/r/20200622124110.20971-5-sumit.semwal@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Some regulators might need to verify that they have indeed been enabled
after the enable() call is made and enable_time delay has passed.
This is implemented by repeatedly checking is_enabled() upto
poll_enabled_time, waiting for the already calculated enable delay in
each iteration.
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Link: https://lore.kernel.org/r/20200622124110.20971-2-sumit.semwal@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
It is never modified, so make it const to allow the compiler to put it
in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Acked-by: Pi-Hsun Shih <pihsun@chromium.org>
Link: https://lore.kernel.org/r/20200711114409.9911-1-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Line up descriptions, start description with a lower-case character and
omit old definitions such as quoting the old argument "consumer".
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200708124832.3441649-4-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Kerneldoc validation gets confused if syntax isn't "@.*: ".
Adding the missing colons squashes the following W=1 warnings:
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Rajendra Nayak <rnayak@ti.com>
Link: https://lore.kernel.org/r/20200708124832.3441649-3-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Provide descriptions for some missing function args and
rename others to match the names used.
Fixes the following W=1 warning(s):
drivers/regulator/devres.c:187: warning: Function parameter or member 'dev' not described in 'devm_regulator_register'
drivers/regulator/devres.c:226: warning: Function parameter or member 'dev' not described in 'devm_regulator_unregister'
drivers/regulator/devres.c:226: warning: Function parameter or member 'rdev' not described in 'devm_regulator_unregister'
drivers/regulator/devres.c:226: warning: Excess function parameter 'regulator' description in 'devm_regulator_unregister'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200708124832.3441649-2-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds support for COMPILE_TEST while fixing a warning when
no support for device tree is there.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
Link: https://lore.kernel.org/r/1c437154873ace65ff738a0ebca511308f1cecc1.camel@googlemail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds support for ON Semiconductor FAN53880 regulator.
The FAN53880 is an I2C porgrammable power management IC (PMIC)
that contains a BUCK (step-down converter), four LDOs (low dropouts)
and one BOOST (step-up converter). It is designed for mobile power
applications.
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
Link: https://lore.kernel.org/r/20200702210846.31659-2-chf.fritz@googlemail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patchset adds support for being able to change regulator modes for
the mt6397 regulator. This is needed to allow the voltage scaling
support in the MT8173 SoC to be used on the elm (Acer Chromebook R13)
and hana (several Lenovo Chromebooks) devices.
Without a of_map_mode implementation, the regulator-allowed-modes
devicetree field is skipped, and attempting to change the regulator mode
results in an error:
[ 1.439165] vpca15: mode operation not allowed
Changes in v2:
- Introduce constants in dt-bindings
- Improve conditional readability
Anand K Mistry (4):
regulator: mt6397: Move buck modes into header file
dt-bindings: regulator: mt6397: Document valid modes
regulator: mt6397: Implement of_map_mode
arm64: dts: mediatek: Update allowed mt6397 regulator modes for elm
boards
.../bindings/regulator/mt6397-regulator.txt | 3 +++
arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 4 +++-
drivers/regulator/mt6397-regulator.c | 17 ++++++++++++++---
.../regulator/mediatek,mt6397-regulator.h | 15 +++++++++++++++
4 files changed, 35 insertions(+), 4 deletions(-)
create mode 100644 include/dt-bindings/regulator/mediatek,mt6397-regulator.h
--
2.27.0.212.ge8ba1cc988-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.orghttp://lists.infradead.org/mailman/listinfo/linux-arm-kernel
This patchset adds support for being able to change regulator modes for
the da9211 regulator. This is needed to allow the voltage scaling
support in the MT8173 SoC to be used in the elm (Acer Chromebook R13)
and hana (several Lenovo Chromebooks) devices.
Anand K Mistry (4):
regulator: da9211: Move buck modes into header file
dt-bindings: regulator: da9211: Document allowed modes
regulator: da9211: Implement of_map_mode
arm64: dts: mediatek: Update allowed regulator modes for elm boards
.../devicetree/bindings/regulator/da9211.txt | 4 +++
arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 4 ++-
drivers/regulator/da9211-regulator.c | 30 +++++++++++++++----
.../regulator/dlg,da9211-regulator.h | 16 ++++++++++
4 files changed, 47 insertions(+), 7 deletions(-)
create mode 100644 include/dt-bindings/regulator/dlg,da9211-regulator.h
--
2.27.0.212.ge8ba1cc988-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.orghttp://lists.infradead.org/mailman/listinfo/linux-arm-kernel
The SY8827N from Silergy Corp is a single output DC/DC converter. The
voltage can be controlled via I2C.
Jisheng Zhang (2):
dt-bindings: regulator: add document bindings for sy8827n
regulator: add support for SY8827N regulator
.../bindings/regulator/silergy,sy8827n.yaml | 45 +++++
drivers/regulator/Kconfig | 7 +
drivers/regulator/Makefile | 1 +
drivers/regulator/sy8827n.c | 185 ++++++++++++++++++
4 files changed, 238 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/silergy,sy8827n.yaml
create mode 100644 drivers/regulator/sy8827n.c
--
2.27.0
Use the new .probe_new for mp886x. It does not use the const
struct i2c_device_id * argument, so convert it to utilise the
simplified i2c driver registration.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200702100200.1a4c65d1@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
The null pointer check on regmap that checks for a dev_get_regmap failure
is currently returning -ENOENT if the regmap succeeded. Fix this by adding
in the missing ! operator.
Fixes: 4fe66d5a62 ("regulator: Add support for QCOM PMIC VBUS booster")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Addresses-Coverity: ("Dereference after null check")
Link: https://lore.kernel.org/r/20200702115659.38208-1-colin.king@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The SY8827N from Silergy Corp is a single output DC/DC converter. The
voltage can be controlled via I2C.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200702171438.20edc523@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Changes in v4:
- Modified qcom,pmic-typec binding to include the SS mux and the DRD remote
endpoint nodes underneath port@1, which is assigned to the SSUSB path
according to usb-connector
- Added usb-connector reference to the typec dt-binding
- Added tags to the usb type c and vbus nodes
- Removed "qcom" tags from type c and vbus nodes
- Modified Kconfig module name, and removed module alias from the typec driver
Changes in v3:
- Fix driver reference to match driver name in Kconfig for
qcom_usb_vbus-regulator.c
- Utilize regulator bitmap helpers for enable, disable and is enabled calls in
qcom_usb_vbus-regulator.c
- Use of_get_regulator_init_data() to initialize regulator init data, and to
set constraints in qcom_usb_vbus-regulator.c
- Remove the need for a local device structure in the vbus regulator driver
Changes in v2:
- Use devm_kzalloc() in qcom_pmic_typec_probe()
- Add checks to make sure return value of typec_find_port_power_role() is
valid
- Added a VBUS output regulator driver, which will be used by the PMIC USB
type c driver to enable/disable the source
- Added logic to control vbus source from the PMIC type c driver when
UFP/DFP is detected
- Added dt-binding for this new regulator driver
- Fixed Kconfig typec notation to match others
- Leave type C block disabled until enabled by a platform DTS
Add the required drivers for implementing type C orientation and role
detection using the Qualcomm PMIC. Currently, PMICs such as the PM8150B
have an integrated type C block, which can be utilized for this. This
series adds the dt-binding, PMIC type C driver, and DTS nodes.
The PMIC type C driver will register itself as a type C port w/ a
registered type C switch for orientation, and will fetch a USB role switch
handle for the role notifications. It will also have the ability to enable
the VBUS output to any connected devices based on if the device is behaving
as a UFP or DFP.
Wesley Cheng (6):
usb: typec: Add QCOM PMIC typec detection driver
dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding
arm64: boot: dts: qcom: pm8150b: Add node for USB type C block
regulator: Add support for QCOM PMIC VBUS booster
dt-bindings: regulator: Add dt-binding for QCOM PMIC VBUS output
regulator
arm64: boot: dts: qcom: pm8150b: Add DTS node for PMIC VBUS booster
.../regulator/qcom,usb-vbus-regulator.yaml | 41 +++
.../bindings/usb/qcom,pmic-typec.yaml | 113 +++++++
arch/arm64/boot/dts/qcom/pm8150b.dtsi | 13 +
arch/arm64/boot/dts/qcom/sm8150-mtp.dts | 4 +
drivers/regulator/Kconfig | 10 +
drivers/regulator/Makefile | 1 +
drivers/regulator/qcom_usb_vbus-regulator.c | 97 ++++++
drivers/usb/typec/Kconfig | 12 +
drivers/usb/typec/Makefile | 1 +
drivers/usb/typec/qcom-pmic-typec.c | 275 ++++++++++++++++++
10 files changed, 567 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
create mode 100644 drivers/regulator/qcom_usb_vbus-regulator.c
create mode 100644 drivers/usb/typec/qcom-pmic-typec.c
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
IPQ6018 SoC uses the PMIC MP5496. SMPA2 and LDOA2 regulator of MP5496
controls the APSS and SDCC voltage scaling respectively. Add support
for the same.
changes since V1:
- Moved YAML conversion to the last as per Mark's comments
Kathiravan T (6):
dt-bindings: soc: qcom: Add IPQ6018 compatible
soc: qcom: smd-rpm: Add IPQ6018 compatible
dt-bindings: regulator: add MP5496 regulator compatible
regulator: qcom_smd: Add MP5496 regulators
dt-bindings: soc: qcom: convert the SMD-RPM document to YAML schema
dt-bindings: regulator: convert QCOM SMD-RPM regulator document to
YAML schema
.../bindings/regulator/qcom,smd-rpm-regulator.txt | 320 ---------------------
.../bindings/regulator/qcom,smd-rpm-regulator.yaml | 106 +++++++
.../devicetree/bindings/soc/qcom/qcom,smd-rpm.txt | 62 ----
.../devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml | 92 ++++++
drivers/regulator/qcom_smd-regulator.c | 34 +++
drivers/soc/qcom/smd-rpm.c | 1 +
6 files changed, 233 insertions(+), 382 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
create mode 100644 Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml
delete mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
This driver enables outputs by setting bit EN_BUCKn in the BUCKn_CTRL1
register. However, if bit EN_PIN_CTRLn in the same register is set, the
output is actually enabled only if EN_BUCKn is set AND an enable pin is
active. Since the driver does not touch EN_PIN_CTRLn, the choice is left to
the hardware, which in turn gets this bit from OTP memory, and in absence
of OTP data it uses a default value that is documented in the datasheet for
LP8752x, but not for LP8756x.
Thus the driver doesn't really "know" whether it is actually enabling the
output or not.
In order to make sure activation is always driver-controlled, just clear
the EN_PIN_CTRLn bit. Now all activation solely depend on the EN_BUCKn bit.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Link: https://lore.kernel.org/r/20200622204329.11147-2-luca@lucaceresoli.net
Signed-off-by: Mark Brown <broonie@kernel.org>
IPQ6018 SoC uses the PMIC MP5496. SMPA2 and LDOA2 regulator controls the
APSS and SDCC voltage scaling respectively. Add support for the same.
Signed-off-by: Kathiravan T <kathirav@codeaurora.org>
Link: https://lore.kernel.org/r/1592889472-6843-5-git-send-email-kathirav@codeaurora.org
Signed-off-by: Mark Brown <broonie@kernel.org>
These are never modified, so make them const to allow the compiler to
put them in read-only memory.
Before:
text data bss dec hex filename
20362 2592 152 23106 5a42 drivers/regulator/qcom_spmi-regulator.o
After:
text data bss dec hex filename
21814 1140 152 23106 5a42 drivers/regulator/qcom_spmi-regulator.o
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200629194632.8147-3-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
These are never modified, so make them const to allow the compiler to
put them in read-only memory.
Before:
text data bss dec hex filename
17485 500 8 17993 4649 drivers/regulator/qcom_rpm-regulator.o
After:
text data bss dec hex filename
17881 104 8 17993 4649 drivers/regulator/qcom_rpm-regulator.o
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200629194632.8147-2-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some Qualcomm PMICs have the capability to source the VBUS output to
connected peripherals. This driver will register a regulator to the
regulator list to enable or disable this source by an external driver.
Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/20200626185516.18018-5-wcheng@codeaurora.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This was an upstreaming error. Remove it as it's not to be used.
Fixes the following W=1 kernel build warning:
drivers/regulator/qcom_smd-regulator.c:477:36: warning: ‘pmi8994_boost’ defined but not used [-Wunused-const-variable=]
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: linux-arm-msm@vger.kernel.org
Link: https://lore.kernel.org/r/20200626065738.93412-10-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
W=1 kernel builds report a lack of descriptions for various
function arguments. In reality they are documented, but the
formatting was not as expected '@.*:'. Instead, some weird
arg identifiers were used.
This change fixes the following warnings:
drivers/regulator/wm8400-regulator.c:243: warning: Function parameter or member 'dev' not described in 'wm8400_register_regulator'
drivers/regulator/wm8400-regulator.c:243: warning: Function parameter or member 'reg' not described in 'wm8400_register_regulator'
drivers/regulator/wm8400-regulator.c:243: warning: Function parameter or member 'initdata' not described in 'wm8400_register_regulator'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Cc: patches@opensource.cirrus.com
Link: https://lore.kernel.org/r/20200626065738.93412-9-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
'rid' is declared as unsigned int, so there is little point checking for <0.
Removing these checks fixes the following W=1 warnings:
drivers/regulator/tps65218-regulator.c: In function ‘tps65218_pmic_set_suspend_enable’:
drivers/regulator/tps65218-regulator.c:131:10: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
131 | if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1)
| ^
drivers/regulator/tps65218-regulator.c: In function ‘tps65218_pmic_set_suspend_disable’:
drivers/regulator/tps65218-regulator.c:144:10: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
144 | if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1)
| ^
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Dave Gerlach <d-gerlach@ti.com>
Cc: linux-omap@vger.kernel.org
Link: https://lore.kernel.org/r/20200626065738.93412-8-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Until now the aforementioned return value has been ignored.
Previous and current calls to tps65217_reg_read() return
instantly when the value is not 0, so let's do that.
Fixes the following W=1 warning:
drivers/regulator/tps65217-regulator.c: In function ‘tps65217_regulator_probe’:
drivers/regulator/tps65217-regulator.c:227:9: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable]
227 | int i, ret;
| ^~~
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Russ Dill <Russ.Dill@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: AnilKumar Ch <anilkumar@ti.com>
Cc: linux-omap@vger.kernel.org
Link: https://lore.kernel.org/r/20200626065738.93412-7-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
'rid' is declared as unsigned int, so there is little point checking for <0.
Removing these checks fixes the following W=1 warnings:
drivers/regulator/tps65217-regulator.c: In function ‘tps65217_pmic_set_suspend_enable’:
drivers/regulator/tps65217-regulator.c:127:10: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
127 | if (rid < TPS65217_DCDC_1 || rid > TPS65217_LDO_4)
| ^
drivers/regulator/tps65217-regulator.c: In function ‘tps65217_pmic_set_suspend_disable’:
drivers/regulator/tps65217-regulator.c:140:10: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
140 | if (rid < TPS65217_DCDC_1 || rid > TPS65217_LDO_4)
| ^
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Russ Dill <Russ.Dill@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: AnilKumar Ch <anilkumar@ti.com>
Cc: linux-omap@vger.kernel.org
Link: https://lore.kernel.org/r/20200626065738.93412-6-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
In kerneldoc format, data structures have to start with 'struct'
else the kerneldoc tooling/parsers/validators get confused.
Fixes the following W=1 kernel build warning:
drivers/regulator/stpmic1_regulator.c:25: warning: cannot understand function prototype: 'struct stpmic1_regulator_cfg '
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Pascal Paillet <p.paillet@st.com>
Link: https://lore.kernel.org/r/20200626065738.93412-5-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This particular comment doesn't have anything to do with documenting
functions or data structures. Instead it is used as a section header.
Fixes W=1 warning:
drivers/regulator/pwm-regulator.c:55: warning: Function parameter or member 'rdev' not described in 'pwm_regulator_init_state'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200626065738.93412-4-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
W=1 kernel builds report a lack of descriptions for various
enum properties and function arguments. In reality they are
documented, but the formatting was not as expected '@.*:'.
Instead, some weird arg identifiers were used or none at all.
This change fixes the following warnings:
drivers/regulator/qcom-rpmh-regulator.c:33: warning: Enum value 'VRM' not described in enum 'rpmh_regulator_type'
drivers/regulator/qcom-rpmh-regulator.c:33: warning: Enum value 'XOB' not described in enum 'rpmh_regulator_type'
drivers/regulator/qcom-rpmh-regulator.c:416: warning: Function parameter or member 'vreg' not described in 'rpmh_regulator_init_vreg'
drivers/regulator/qcom-rpmh-regulator.c:416: warning: Function parameter or member 'dev' not described in 'rpmh_regulator_init_vreg'
drivers/regulator/qcom-rpmh-regulator.c:416: warning: Function parameter or member 'node' not described in 'rpmh_regulator_init_vreg'
drivers/regulator/qcom-rpmh-regulator.c:416: warning: Function parameter or member 'pmic_id' not described in 'rpmh_regulator_init_vreg'
drivers/regulator/qcom-rpmh-regulator.c:416: warning: Function parameter or member 'pmic_rpmh_data' not described in 'rpmh_regulator_init_vreg'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: linux-arm-msm@vger.kernel.org
Link: https://lore.kernel.org/r/20200626065738.93412-3-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
max8998_get_current_limit() is only used via the .get_current_limit,
so it doesn't need to be publicly supported, or to have its own
external prototype. Instead, we'll make it static.
Fixes the following W=1 warning:
drivers/regulator/max8998.c:418:5: warning: no previous prototype for ‘max8998_get_current_limit’ [-Wmissing-prototypes]
418 | int max8998_get_current_limit(struct regulator_dev *rdev)
| ^~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20200626065738.93412-2-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Nothing about this comment identifies it as a kerneldoc header.
It's missing all of it's function argument descriptions and the
correct function header.
Fixes the following W=1 warning(s):
drivers/regulator/max14577-regulator.c:166: warning: Function parameter or member 'max14577' not described in 'max14577_get_regma
drivers/regulator/max14577-regulator.c:166: warning: Function parameter or member 'reg_id' not described in 'max14577_get_regmap'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200625163614.4001403-11-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Nothing about this comment identifies it as a kerneldoc header.
They're missing all of their struct's property descriptions and
the correct 'struct *' header.
Fixes the following W=1 warning(s):
drivers/regulator/cpcap-regulator.c:99: warning: cannot understand function prototype: 'struct cpcap_regulator '
drivers/regulator/cpcap-regulator.c:337: warning: cannot understand function prototype: 'const struct cpcap_regulator omap4_regulators[] = '
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200625163614.4001403-9-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
It's okay to not check the return value that you're not conserned
about, however it is not okay to assign a variable and not check or
use the result.
Fixes W=1 warnings(s):
drivers/regulator/cpcap-regulator.c:172:13: warning: variable ‘ignore’ set but not used [-Wunused-but-set-variable]
172 | int error, ignore;
| ^~~~~~
drivers/regulator/cpcap-regulator.c: In function ‘cpcap_regulator_disable’:
drivers/regulator/cpcap-regulator.c:196:13: warning: variable ‘ignore’ set but not used [-Wunused-but-set-variable]
196 | int error, ignore;
| ^~~~~~
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200625163614.4001403-8-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Kerneldoc expects function arguments to be in the format '@.*:'. If
this format is not followed the kerneldoc tooling/parsers/validators
get confused.
Fixes the following W=1 warning(s):
drivers/regulator/wm8350-regulator.c🔢 warning: Function parameter or member 'wm8350' not described in 'wm8350_register_led'
drivers/regulator/wm8350-regulator.c🔢 warning: Function parameter or member 'lednum' not described in 'wm8350_register_led'
drivers/regulator/wm8350-regulator.c🔢 warning: Function parameter or member 'dcdc' not described in 'wm8350_register_led'
drivers/regulator/wm8350-regulator.c🔢 warning: Function parameter or member 'isink' not described in 'wm8350_register_led'
drivers/regulator/wm8350-regulator.c🔢 warning: Function parameter or member 'pdata' not described in 'wm8350_register_led'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200625163614.4001403-7-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Used primarily for the AB8540 which lost support in early 2018.
It is now deemed safe to remove this legacy data structure.
Also fixes W=1 issue:
drivers/regulator/ab8500.c:88: warning: Function parameter or member 'expand_register' not described in 'ab8500_regulator_info'
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200625163614.4001403-6-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
There isn't any code present within the current kernel to
override this 'weak' function. Besides returning '0', which
is never checked anyway, the whole function appears to be
superfluous.
Consequently fixes W=1 warning:
drivers/regulator/dbx500-prcmu.c:113:27: warning: no previous prototype for ‘dbx500_regulator_testcase’ [-Wmissing-prototypes]
113 | int __attribute__((weak)) dbx500_regulator_testcase(
| ^~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200625163614.4001403-5-lee.jones@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This module shares the same name as its parent PMIC driver, which
confuses tools like kmod. Rename the regulator driver to avoid
such problems.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Link: https://lore.kernel.org/r/20200624171010.845271-1-seth.forshee@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
These are not modified so make them const to allow the compiler to put
them in read-only memory.
Before:
text data bss dec hex filename
13114 8596 0 21710 54ce drivers/regulator/max8997-regulator.o
After:
text data bss dec hex filename
14038 7672 0 21710 54ce drivers/regulator/max8997-regulator.o
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200617223247.25566-6-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
These are not modified so make them const to allow the compiler to put
them in read-only memory.
Before:
text data bss dec hex filename
2753 7328 0 10081 2761 drivers/regulator/max8907-regulator.o
After:
text data bss dec hex filename
9405 684 0 10089 2769 drivers/regulator/max8907-regulator.o
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200617223247.25566-5-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ltc3676_regulators is not modified and can be made const to allow the
compiler to put it in read-only memory.
Before:
text data bss dec hex filename
4361 2064 8 6433 1921 drivers/regulator/ltc3676.o
After:
text data bss dec hex filename
6121 304 8 6433 1921 drivers/regulator/ltc3676.o
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200617223247.25566-4-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
cpcap_regulator_ops is not modified and can be made const to allow the
compiler to put it in read-only memory.
Before:
text data bss dec hex filename
14472 236 0 14708 3974 drivers/regulator/cpcap-regulator.o
After:
text data bss dec hex filename
14604 104 0 14708 3974 drivers/regulator/cpcap-regulator.o
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200617223247.25566-3-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
anatop_core_rops is not modified and can therefore be made const which
allows the compiler to put it in read-only memory.
Before:
text data bss dec hex filename
4502 412 0 4914 1332 drivers/regulator/anatop-regulator.o
After:
text data bss dec hex filename
4634 280 0 4914 1332 drivers/regulator/anatop-regulator.o
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20200617223247.25566-2-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for controlling voltage regulator that is connected and
controlled by ChromeOS EC. Kernel controls these regulators through
newly added EC host commands.
Changes from v5:
* Move new host command to a separate patch.
* Use devm_regulator_register.
* Address review comments.
Changes from v4:
* Change compatible name from regulator-cros-ec to cros-ec-regulator.
Changes from v3:
* Fix dt bindings file name.
* Remove check around CONFIG_OF in driver.
* Add new host commands to cros_ec_trace.
* Address review comments.
Changes from v2:
* Add 'depends on OF' to Kconfig.
* Add Kconfig description about compiling as module.
Changes from v1:
* Change compatible string to google,regulator-cros-ec.
* Use reg property in device tree.
* Change license for dt binding according to checkpatch.pl.
* Address comments on code styles.
Pi-Hsun Shih (3):
dt-bindings: regulator: Add DT binding for cros-ec-regulator
platform/chrome: cros_ec: Add command for regulator control.
regulator: Add driver for cros-ec-regulator
.../regulator/google,cros-ec-regulator.yaml | 51 ++++
drivers/platform/chrome/cros_ec_trace.c | 5 +
drivers/regulator/Kconfig | 10 +
drivers/regulator/Makefile | 1 +
drivers/regulator/cros-ec-regulator.c | 257 ++++++++++++++++++
.../linux/platform_data/cros_ec_commands.h | 82 ++++++
6 files changed, 406 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml
create mode 100644 drivers/regulator/cros-ec-regulator.c
base-commit: b791d1bdf9
--
2.27.0.290.gba653c62da-goog
Add driver for cros-ec-regulator, representing a voltage regulator that
is connected and controlled by ChromeOS EC, and is controlled by kernel
with EC host commands.
Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
Reviewed-by: Prashant Malani <pmalani@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20200612040526.192878-4-pihsun@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
PFUZE100_SWB_REG is not proper for sw1a/sw2, because enable_mask/enable_reg
is not correct. On PFUZE3000, sw1a/sw2 should be the same as sw1a/sw2 on
pfuze100 except that voltages are not linear, so add new PFUZE3000_SW_REG
and pfuze3000_sw_regulator_ops which like the non-linear PFUZE100_SW_REG
and pfuze100_sw_regulator_ops.
Fixes: 1dced996ee ("regulator: pfuze100: update voltage setting for pfuze3000 sw1a")
Reported-by: Christophe Meynard <Christophe.Meynard@ign.fr>
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Link: https://lore.kernel.org/r/1592171648-8752-1-git-send-email-yibin.gong@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pickable ranges mapping function never used range min selector. Thus
existing drivers broke when proper linear_ranges functionality was taken
in use. Fix this for now just by ignoring the minimum selector.
Fixes: 60ab7f4153 ("regulator: use linear_ranges helper")
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/20200612090225.GA3243@localhost.localdomain
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 99f75ce666 ("regulator: da9063: fix suspend") converted
the regulators to use a common (corrected) suspend bit setting but
one of regulators (LDO9) slipped through the crack.
This means that the original problem was not fixed for LDO9 and
also leads to a warning found by the test robot.
da9063-regulator.c:515:3: warning: initialized field overwritten
Fix this by converting that regulator too like the others.
Fixes: 99f75ce666 ("regulator: da9063: fix suspend")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
Link: https://lore.kernel.org/r/1591959073-16792-1-git-send-email-martin.fuzzey@flowbird.group
Signed-off-by: Mark Brown <broonie@kernel.org>
Add new trace points for the start and end of enabling bypass on a
regulator, to allow monitoring of when regulators are moved into bypass
and how long that takes.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200529152216.9671-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Hi!
This patchset is another attempt to fix the regulator coupling on
Exynos5800/5422 SoCs. Here are links to the previous attempts:
https://lore.kernel.org/linux-samsung-soc/20191008101709.qVNy8eijBi0LynOteWFMnTg4GUwKG599n6OyYoX1Abs@z/https://lore.kernel.org/lkml/20191017102758.8104-1-m.szyprowski@samsung.com/https://lore.kernel.org/linux-pm/cover.1589528491.git.viresh.kumar@linaro.org/https://lore.kernel.org/linux-pm/20200528131130.17984-1-m.szyprowski@samsung.com/
The problem is with "vdd_int" regulator coupled with "vdd_arm" on Odroid
XU3/XU4 boards family. "vdd_arm" is handled by CPUfreq. "vdd_int" is
handled by devfreq. CPUfreq initialized quite early during boot and it
starts changing OPPs and "vdd_arm" value. Sometimes CPU activity during
boot goes down and some low-frequency OPPs are selected, what in turn
causes lowering "vdd_arm". This happens before devfreq applies its
requirements on "vdd_int". Regulator balancing code reduces "vdd_arm"
voltage value, what in turn causes lowering "vdd_int" value to the lowest
possible value. This is much below the operation point of the wcore bus,
which still runs at the highest frequency.
The issue was hard to notice because in the most cases the board managed
to boot properly, even when the regulator was set to lowest value allowed
by the regulator constraints. However, it caused some random issues,
which can be observed as "Unhandled prefetch abort" or low USB stability.
Adding more and more special cases to the generic code has been rejected,
so the only way to ensure the desired behavior on Exynos5800-based SoCs
is to make a custom regulator coupler driver.
Best regards,
Marek Szyprowski
Patch summary:
Marek Szyprowski (2):
regulator: extract voltage balancing code to separate function
soc: samsung: Add simple voltage coupler for Exynos5800
arch/arm/mach-exynos/Kconfig | 1 +
drivers/regulator/core.c | 49 ++++++++-------
drivers/soc/samsung/Kconfig | 3 +
drivers/soc/samsung/Makefile | 1 +
.../soc/samsung/exynos-regulator-coupler.c | 59 +++++++++++++++++++
include/linux/regulator/coupler.h | 8 +++
6 files changed, 101 insertions(+), 20 deletions(-)
create mode 100644 drivers/soc/samsung/exynos-regulator-coupler.c
--
2.17.1
base-commit: 8f3d9f3542
Move the coupled regulators voltage balancing code to the separate
function and allow to call it from the custom regulator couplers.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20200529124940.10675-2-m.szyprowski@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The max8998 has a current regulator for charging control. The
charger driver in drivers/power/supply/max8998_charger.c has a
comment in it stating that 'charger control is done by a current
regulator "CHARGER"', but this regulator was never added until
now.
The current values have been extracted from a downstream driver
for the SGH-T959V.
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Link: https://lore.kernel.org/r/BN6PR04MB0660E1F4A3D5A348BE88311CA3BA0@BN6PR04MB0660.namprd04.prod.outlook.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add maintainer entries to a few ROHM devices and Linear Ranges
Linear Ranges helpers were refactored out of regulator core to lib so
that other drivers could utilize them too. (I guess power/supply drivers
and possibly clk drivers can benefit from them). As regulators is
currently the main user it makes sense the changes to linear_ranges go
through Mark's tree.
During past two years few ROHM PMIC drivers have been added to
mainstream. They deserve a supporter from ROHM side too :)
Patch 1:
Maintainer entries for few ROHM IC drivers
Patch 2:
Maintainer entry for linear ranges helpers
---
Matti Vaittinen (2):
MAINTAINERS: Add entry for ROHM power management ICs
MAINTAINERS: Add maintainer entry for linear ranges helper
MAINTAINERS | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
base-commit: b9bbe6ed63
--
2.21.0
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =]
The BD71837 had a HW "feature" where changing the regulator output
voltages of other regulators but bucks 1-4 might cause spikes if
regulators were enabled. Thus SW prohibit voltage changes for other
regulators except for bucks 1-4 when regulator is enabled.
The HW colleagues did inadvertly fix this issue for BD71847 and
BD71850.
The power-good detection for LDOs can still cause false alarms if
LDO voltage is changed upwards when LDO is enabled.
Allow LDO voltage changes and disabe the power-good monioring for
the duration of the LDO voltage change and enable it after LDO
voltage has stabilized. ROHM HW colleagues measured the safety
limit of 1000uS for guaranteeing the voltage has stabilized. Let's
use that for starters and add confiurable stabilization wait-time
later if needed.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/20200513143921.GA22143@localhost.localdomain
Signed-off-by: Mark Brown <broonie@kernel.org>
Series extracts a "linear ranges" helper out of the regulator
framework. Linear ranges helper is intended to help converting
real-world values to register values when conversion is linear. I
suspect this is useful also for power subsystem and possibly for clk.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl61lKwTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0HxeB/9dblIbC+28MvcEHXCcYBZBouOnrM8E
bIOMXkgEj1uL78ozOm7tMCgEpaKgv6BHdDuClCBvjbr0uOtAi0qUiv0IBotuVrdo
lq73l8l7OPz6TFFKIt8WsgwKnzdkuQC08+qrZasAdluRQnqnmkU2tvl2y9zaaaR4
6hGw+Nwx/pgeCXCa3pu+rCYwA7g0Tf8a6DDC6LyQWZameBJ1ey/YDjhJEeSmY7P7
306zs8YVxHhQMLUQ5T7DA6r/KWMNkO1SOueCqTjxWZc/XamGEcbsZG1cWrAnkoE2
VKLXBtYC75coNxIiu8ZxnQwLLdz1EQPdtg0qmzSjXJ68QjbWWzf4K1ra
=LG9G
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl61lPUTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0GuGB/9kDFxKo0DWsH6tqZGS/retk0ddT+4B
mnkkZGvoKkkDe1lh84vRbrPHhiI9LIXaj3lFgzyYeTuAi9tb77mPNnYIPLDye7bO
OvgJgovo4tK3dUVSUFatvOhuAMSZLyN2WjWRX+YeHMd1nNZSHxEz0CuG3npNtuKa
KoZd0Dfom4ds66qDlWdfonFhMJbMvQbEs4BhnfdvpD/soylyDB+29SHlhTBv8+UC
I7BNzsmVDlp/JyrX3yJbuTum9wbPaMLcyL96EbvRykmTywz5FXudffqzPfPnoQxT
rbN5DfwKsnySToUYDfp9dcIMyTF0/MtneaeBMRu2NIkpMmnicvExNrbU
=/+DM
-----END PGP SIGNATURE-----
Merge tag 'linear-ranges-lib' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-5.8
lib: Add linear ranges helper library and start using it
Series extracts a "linear ranges" helper out of the regulator
framework. Linear ranges helper is intended to help converting
real-world values to register values when conversion is linear. I
suspect this is useful also for power subsystem and possibly for clk.
Change the regulator helpers to use common linear_ranges code.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/64f01d5e381b8631a271616b7790f9d5640974fb.1588944082.git.matti.vaittinen@fi.rohmeurope.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix the following coccicheck warning:
drivers/regulator/db8500-prcmu.c:184:1-17: WARNING: Assignment of 0/1 to
bool variable
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Link: https://lore.kernel.org/r/20200506061726.19289-1-yanaijie@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This reverts commit dca0b44957 ("regulator: Use
driver_deferred_probe_timeout for regulator_init_complete_work"),
as we ended up reverting the default deferred_probe_timeout
value back to zero, to preserve behavior with 5.6 we need to
decouple the regulator timeout which was previously 30 seconds.
This avoids breaking some systems that depend on the regulator
timeout but don't require the deferred probe timeout.
Cc: linux-pm@vger.kernel.org
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
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>
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20200429172349.55979-1-john.stultz@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The BD71837 had a HW "feature" where changing the regulator output
voltages of other regulators but bucks 1-4 might cause spikes if
regulators were enabled. Thus SW prohibit voltage changes for other
regulators except for bucks 1-4 when regulator is enabled.
The HW colleagues did inadvertly fix this issue for BD71847 and
BD71850. Remove voltage change restrictions from other PMICs but
BD71837.
The LDO voltage changing is still restricted. I did not yet receive
answer whether there is voltage spikes to be expected for LDOs. I
only know that the power-good detection for LDOs can cause false
alarms if LDO voltage is changed when LDO is enabled. We might be
able to work-around this by disabling the power-good monioring for
the duration of the LDO voltage change - but as I said, I don't
know yet. Let's fix it later if we can confirm that also LDO voltage
changes are safe.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/20200428092930.GA9721@localhost.localdomain
Signed-off-by: Mark Brown <broonie@kernel.org>
Adding regulator driver for the Maxim max77826 device.
The max77826 PMIC contains a high-efficiency BUCK regulator, a BUCK
BOOST regulator and 15 LDOs. It is designed for smartphone and tablet
applications and is accessed over I2C.
Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com>
Link: https://lore.kernel.org/r/20200414172250.2363235-2-iskren.chernev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The variables ret and val are being initialized with values that are
never read and are being updated later with a new value. The
initializations are redundant and can be removed.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Addresses-Coverity: ("Unused value")
Link: https://lore.kernel.org/r/20200410133406.24458-1-colin.king@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix the following gcc warning:
drivers/regulator/ab8500.c:195:27: warning: ‘ldo_vdmic_voltages’ defined
but not used [-Wunused-const-variable=]
static const unsigned int ldo_vdmic_voltages[] = {
^~~~~~~~~~~~~~~~~~
drivers/regulator/ab8500.c:169:27: warning: ‘fixed_3300000_voltage’
defined but not used [-Wunused-const-variable=]
static const unsigned int fixed_3300000_voltage[] = {
^~~~~~~~~~~~~~~~~~~~~
drivers/regulator/ab8500.c:142:27: warning: ‘ldo_sdio_voltages’ defined
but not used [-Wunused-const-variable=]
static const unsigned int ldo_sdio_voltages[] = {
^~~~~~~~~~~~~~~~~
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Link: https://lore.kernel.org/r/20200410073343.39031-1-yanaijie@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/731a4b299c6ae0ee9d8995157600a3477f21a36c.1585959068.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix the following gcc warning:
drivers/regulator/qcom_rpm-regulator.c:607:34: warning: ‘pm8921_ftsmps’
defined but not used [-Wunused-const-variable=]
static const struct qcom_rpm_reg pm8921_ftsmps = {
^~~~~~~~~~~~~
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20200409114026.38383-1-yanaijie@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
At one point in the release cycle I managed to fat finger things and
apply some SPI fixes onto a regulator branch and merge that into the SPI
tree, then pull in a change shared with the MTD tree moving the Mediatek
quadspi driver over to become the Mediatek spi-nor driver in the SPI
tree. This has made a mess which I only just noticed while preparing
this and I can't see a sensible way to unpick things due to other
subsequent merge commits especially the pull from MTD so it looks like
the most sensible thing to do is give up and combine the two pull
requests - I hope this is OK. Sorry about this, I've changed some bits
of workflow which should hopefully help me spot such issues earlier in
future.
Fortunately both subsystems were fairly quiet this cycle, the highlights
are:
regulator:
- Support for Monoloithic Power Systems MP5416, MP8867 and MPS8869 and
Qualcomm PMI8994 and SMB208.
SPI:
- Lots of enhancements for spi-fsl-dspi, including XSPI mode support,
from Vladimir Oltean.
- Support for amlogic Meson G12A, IBM FSI, Mediatek spi-nor (moved from
MTD), NXP i.MX8Mx, Rockchip PX30, RK3308 and RK3328, and Qualcomm
Atheros AR934x/QCA95xx.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl6B5OUTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0F64B/wMN9AALiI+L8yLWbhlCebJLrtX4Nc5
2Pe25eJNnYRor+s8SxWK7rJ1IlMHQv/lkD2kCtjtmAvLXQwxyy2r8gW0hsZ8bmUS
O1otrQ8wqfY8Enr8w/qXBMxR46U6vs1sfKDsAEPPUDt5voPbiDGpNazHytWU5Nnp
yLh/8LdACFbanueeth5b14aYZNRVHb04Dh6yDjZOKu0zgNtBmkTQGNN8A4jJyVHC
0SFE0vo1nYsc2w02U6i9ko/GEA/lRSTNZZslXif3wvZQXvy0EgC8sQGLbCdxu8ES
K2EBdeSCaMEoU+s2mFZ2Fuvd3RvGliHxWbn4SZtpaDp+/SBIu52kM4B+
=Eqwk
-----END PGP SIGNATURE-----
Merge tag 'regulator-spi-v5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc
Pull spi and regulator updates from Mark Brown:
"At one point in the release cycle I managed to fat finger things and
apply some SPI fixes onto a regulator branch and merge that into the
SPI tree, then pull in a change shared with the MTD tree moving the
Mediatek quadspi driver over to become the Mediatek spi-nor driver in
the SPI tree.
This has made a mess which I only just noticed while preparing this
and I can't see a sensible way to unpick things due to other
subsequent merge commits especially the pull from MTD so it looks like
the most sensible thing to do is give up and combine the two pull
requests.
Fortunately both subsystems were fairly quiet this cycle, the
highlights are:
regulator:
- Support for Monoloithic Power Systems MP5416, MP8867 and MPS8869
and Qualcomm PMI8994 and SMB208.
SPI:
- Lots of enhancements for spi-fsl-dspi, including XSPI mode support,
from Vladimir Oltean.
- Support for amlogic Meson G12A, IBM FSI, Mediatek spi-nor (moved
from MTD), NXP i.MX8Mx, Rockchip PX30, RK3308 and RK3328, and
Qualcomm Atheros AR934x/QCA95xx"
* tag 'regulator-spi-v5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc: (118 commits)
spi: efm32: Convert to use GPIO descriptors
regulator: qcom_smd: Add pmi8994 regulator support
regulator: da9063: Fix get_mode() functions to read sleep field
spi: spi-fsl-lpspi: Replace zero-length array with flexible-array member
spi: spi-s3c24xx: Replace zero-length array with flexible-array member
spi: stm32: Fix comments compilation warnings
spi: atmel-quadspi: Add verbose debug facilities to monitor register accesses
spi: spi-fsl-dspi: Add support for LS1028A
spi: spi-fsl-dspi: Move invariant configs out of dspi_transfer_one_message
spi: spi-fsl-dspi: Fix interrupt-less DMA mode taking an XSPI code path
spi: spi-fsl-dspi: Avoid NULL pointer in dspi_slave_abort for non-DMA mode
spi: spi-fsl-dspi: Replace interruptible wait queue with a simple completion
spi: spi-fsl-dspi: Protect against races on dspi->words_in_flight
spi: spi-fsl-dspi: Avoid reading more data than written in EOQ mode
spi: spi-fsl-dspi: Fix bits-per-word acceleration in DMA mode
spi: spi-fsl-dspi: Fix little endian access to PUSHR CMD and TXDATA
spi: spi-fsl-dspi: Don't access reserved fields in SPI_MCR
regulator: driver.h: fix regulator_map_* function names
regulator: da9063: fix suspend
spi: mxs: Drop GPIO includes
...
The pmi8994 is commonly found on MSM8996 based devices, such as the
Dragonboard 820c, where it supplies power to a number of LDOs on the
primary PMIC.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20200324041424.518160-1-bjorn.andersson@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
get_mode() is used to retrieve the active mode state. Settings-A
config is used during active state, whilst Settings-B is for
suspend. This means we only need to check the sleep field of each
buck and LDO as that field solely relates to Settings-A config.
This change is a clone of the get_mode() update which was committed
as part of:
- regulator: da9062: fix suspend_enable/disable preparation
[a72865f057]
Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/20200324092516.60B5C3FB8D@swsrvapps-01.diasemi.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The .set_suspend_enable() and .set_suspend_disable() methods are not
supposed to immediately change the regulator state but just indicated
if the regulator should be enabled or disabled when standby mode is
entered (by a hardware signal).
However currently they set control the SEL bits in the DVC registers,
which causes the voltage to change to immediately between the "A"
(normal) and "B" (standby) values as programmed and does nothing for
the enable state...
This means that "regulator-on-in-suspend" does not work (the regulator
is switched off when the PMIC enters standby mode on the hardware
signal) and, potentially, depending on the A and B voltage
configurations the voltage could be incorrectly changed *before*
actually entering suspend.
The right bit to use for the functionality is the "CONF" bit in the
"CONT" register.
The detailed register description says "Sequencer target state"
for this bit which is not very clear but the functional description
is clearer.
>From 5.1.5 System Enable:
De-asserting SYS_EN (changing from active to passive state)
clears control SYSTEM_EN which triggers a power down sequence
into hibernate/standby mode
...
With the exception of supplies that have the xxxx_CONF control
bit asserted, all regulators in power domains POWER1, POWER, and
SYSTEM are sequentially disabled in reverse order.
Regulators with the <x>_CONF bit set remain on but change the
active voltage controlregisters from V<x>_A to V<x>_B
(if V<x>_B is notalready selected).
Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
Link: https://lore.kernel.org/r/1584461691-14344-1-git-send-email-martin.fuzzey@flowbird.group
Signed-off-by: Mark Brown <broonie@kernel.org>
MP8867 is an I2C-controlled adjustable voltage regulator made by
Monolithic Power Systems. The difference between MP8867 and MP8869
are:
1.If V_BOOT, the vref of MP8869 is fixed at 600mv while vref of
MP8867 is determined by the I2C control.
2.For MP8867, when setting voltage, if the step is within 5, we
need to manually set the GO BIT to 0.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200316223127.4b1ecc92@xhacker
Signed-off-by: Mark Brown <broonie@kernel.org>
The MP8869 from Monolithic Power Systems is a single output DC/DC
converter. The voltage can be controlled via I2C.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200316223020.1a6d92ae@xhacker
Signed-off-by: Mark 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: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200312183245.1612-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Rikard Falkeborn