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>
