commit cb3543cff90a4448ed560ac86c98033ad5fecda9 upstream.
When updating the operating mode as part of regulator enable, the caller
has already locked the regulator tree and drms_uA_update() must not try
to do the same in order not to trigger a deadlock.
The lock inversion is reported by lockdep as:
======================================================
WARNING: possible circular locking dependency detected
6.1.0-next-20221215 #142 Not tainted
------------------------------------------------------
udevd/154 is trying to acquire lock:
ffffc11f123d7e50 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x280
but task is already holding lock:
ffff80000e4c36e8 (regulator_ww_class_acquire){+.+.}-{0:0}, at: regulator_enable+0x34/0x80
which lock already depends on the new lock.
...
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(regulator_ww_class_acquire);
lock(regulator_list_mutex);
lock(regulator_ww_class_acquire);
lock(regulator_list_mutex);
*** DEADLOCK ***
just before probe of a Qualcomm UFS controller (occasionally) deadlocks
when enabling one of its regulators.
Fixes: 9243a195be ("regulator: core: Change voltage setting path")
Fixes: f8702f9e4a ("regulator: core: Use ww_mutex for regulators locking")
Cc: stable@vger.kernel.org # 5.0
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20221215104646.19818-1-johan+linaro@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 0591b14ce0398125439c759f889647369aa616a0 ]
I found a use_count leakage towards supply regulator of rdev with
boot-on option.
┌───────────────────┐ ┌───────────────────┐
│ regulator_dev A │ │ regulator_dev B │
│ (boot-on) │ │ (boot-on) │
│ use_count=0 │◀──supply──│ use_count=1 │
│ │ │ │
└───────────────────┘ └───────────────────┘
In case of rdev(A) configured with `regulator-boot-on', the use_count
of supplying regulator(B) will increment inside
regulator_enable(rdev->supply).
Thus, B will acts like always-on, and further balanced
regulator_enable/disable cannot actually disable it anymore.
However, B was also configured with `regulator-boot-on', we wish it
could be disabled afterwards.
Signed-off-by: Rui Zhang <zr.zhang@vivo.com>
Link: https://lore.kernel.org/r/20221201033806.2567812-1-zr.zhang@vivo.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit f2b41b748c19962b82709d9f23c6b2b0ce9d2f91 ]
I got the the following report:
OF: ERROR: memory leak, expected refcount 1 instead of 2,
of_node_get()/of_node_put() unbalanced - destroy cset entry:
attach overlay node /i2c/pmic@62/regulators/exten
In of_get_regulator(), the node is returned from of_parse_phandle()
with refcount incremented, after using it, of_node_put() need be called.
Fixes: 69511a452e ("regulator: map consumer regulator based on device tree")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221115091508.900752-1-yangyingliang@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 1f386d6894d0f1b7de8ef640c41622ddd698e7ab ]
I got a UAF report as following:
==================================================================
BUG: KASAN: use-after-free in __lock_acquire+0x935/0x2060
Read of size 8 at addr ffff88810e838220 by task python3/268
Call Trace:
<TASK>
dump_stack_lvl+0x67/0x83
print_report+0x178/0x4b0
kasan_report+0x90/0x190
__lock_acquire+0x935/0x2060
lock_acquire+0x156/0x400
_raw_spin_lock+0x2a/0x40
lockref_get+0x11/0x30
simple_recursive_removal+0x41/0x440
debugfs_remove.part.12+0x32/0x50
debugfs_remove+0x29/0x30
_regulator_put.cold.54+0x3e/0x27f
regulator_put+0x1f/0x30
release_nodes+0x6a/0xa0
devres_release_all+0xf8/0x150
Allocated by task 37:
kasan_save_stack+0x1c/0x40
kasan_set_track+0x21/0x30
__kasan_slab_alloc+0x5d/0x70
slab_post_alloc_hook+0x62/0x510
kmem_cache_alloc_lru+0x222/0x5a0
__d_alloc+0x31/0x440
d_alloc+0x30/0xf0
d_alloc_parallel+0xc4/0xd20
__lookup_slow+0x15e/0x2f0
lookup_one_len+0x13a/0x150
start_creating+0xea/0x190
debugfs_create_dir+0x1e/0x210
create_regulator+0x254/0x4e0
_regulator_get+0x2a1/0x467
_devm_regulator_get+0x5a/0xb0
regulator_virtual_probe+0xb9/0x1a0
Freed by task 30:
kasan_save_stack+0x1c/0x40
kasan_set_track+0x21/0x30
kasan_save_free_info+0x2a/0x50
__kasan_slab_free+0x102/0x190
kmem_cache_free+0xf6/0x600
rcu_core+0x54c/0x12b0
__do_softirq+0xf2/0x5e3
Last potentially related work creation:
kasan_save_stack+0x1c/0x40
__kasan_record_aux_stack+0x98/0xb0
call_rcu+0x42/0x700
dentry_free+0x6c/0xd0
__dentry_kill+0x23b/0x2d0
dput.part.31+0x431/0x780
simple_recursive_removal+0xa9/0x440
debugfs_remove.part.12+0x32/0x50
debugfs_remove+0x29/0x30
regulator_unregister+0xe3/0x230
release_nodes+0x6a/0xa0
==================================================================
Here is how happened:
processor A processor B
regulator_register()
rdev_init_debugfs()
rdev->debugfs = debugfs_create_dir()
devm_regulator_get()
rdev = regulator_dev_lookup()
create_regulator(rdev)
// using rdev->debugfs as parent
debugfs_create_dir(rdev->debugfs)
mfd_remove_devices_fn()
release_nodes()
regulator_unregister()
// free rdev->debugfs
debugfs_remove_recursive(rdev->debugfs)
release_nodes()
destroy_regulator()
debugfs_remove_recursive() <- causes UAF
In devm_regulator_get(), after getting rdev, the refcount
is get, so fix this by moving debugfs_remove_recursive()
to regulator_dev_release(), then it can be proctected by
the refcount, the 'rdev->debugfs' can not be freed until
the refcount is 0.
Fixes: 5de705194e ("regulator: Add basic per consumer debugfs")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221116033706.3595812-1-yangyingliang@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 5f4b204b6b8153923d5be8002c5f7082985d153f ]
Here is a warning report about lack of registered release()
from kobject lib:
Device '(null)' does not have a release() function, it is broken and must be fixed.
WARNING: CPU: 0 PID: 48430 at drivers/base/core.c:2332 device_release+0x104/0x120
Call Trace:
kobject_put+0xdc/0x180
put_device+0x1b/0x30
regulator_register+0x651/0x1170
devm_regulator_register+0x4f/0xb0
When regulator_register() returns fail and directly goto `clean` symbol,
rdev->dev has not registered release() function yet (which is registered
by regulator_class in the following), so rdev needs to be freed manually.
If rdev->dev.of_node is not NULL, which means the of_node has gotten by
regulator_of_get_init_data(), it needs to call of_node_put() to avoid
refcount leak.
Otherwise, only calling put_device() would lead memory leak of rdev
in further:
unreferenced object 0xffff88810d0b1000 (size 2048):
comm "107-i2c-rtq6752", pid 48430, jiffies 4342258431 (age 1341.780s)
backtrace:
kmalloc_trace+0x22/0x110
regulator_register+0x184/0x1170
devm_regulator_register+0x4f/0xb0
When regulator_register() returns fail and goto `wash` symbol,
rdev->dev has registered release() function, so directly call
put_device() to cleanup everything.
Fixes: d3c731564e ("regulator: plug of_node leak in regulator_register()'s error path")
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
Link: https://lore.kernel.org/r/20221116074339.1024240-1-zengheng4@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 8d8e16592022c9650df8aedfe6552ed478d7135b ]
By using a ratio of delay to poll_enabled_time that is not integer
time_remaining underflows and does not exit the loop as expected.
As delay could be derived from DT and poll_enabled_time is defined
in the driver this can easily happen.
Use a signed iterator to make sure that the loop exits once
the remaining time is negative.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Link: https://lore.kernel.org/r/20220909125954.577669-1-patrick.rudolph@9elements.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit c32f1ebfd26bece77141257864ed7b4720da1557 ]
If regulator_enable() fails, enable_count is incremented still.
A consumer, assuming no matching regulator_disable() is necessary on
failure, will then get this error message upon regulator_put()
since enable_count is non-zero:
[ 1.277418] WARNING: CPU: 3 PID: 1 at drivers/regulator/core.c:2304 _regulator_put.part.0+0x168/0x170
The consumer could try to fix this in their driver by cleaning up on
error from regulator_enable() (i.e. call regulator_disable()), but that
results in the following since regulator_enable() failed and didn't
increment user_count:
[ 1.258112] unbalanced disables for vreg_l17c
[ 1.262606] WARNING: CPU: 4 PID: 1 at drivers/regulator/core.c:2899 _regulator_disable+0xd4/0x190
Fix this by decrementing enable_count upon failure to enable.
With this in place, just the reason for failure to enable is printed
as expected and developers can focus on the root cause of their issue
instead of thinking their usage of the regulator consumer api is
incorrect. For example, in my case:
[ 1.240426] vreg_l17c: invalid input voltage found
Fixes: 5451781dad ("regulator: core: Only count load for enabled consumers")
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Link: https://lore.kernel.org/r/20220819194336.382740-1-ahalaney@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit c3e3ca05dae37f8f74bb80358efd540911cbc2c8 ]
Since the introduction of regulator->enable_count, a driver that did
an exclusive get on an already-enabled regulator would end up with
enable_count initialized to 0 but rdev->use_count initialized to 1.
With that starting point the regulator is effectively stuck enabled,
because if the driver attempted to disable it it would fail the
enable_count underflow check in _regulator_handle_consumer_disable().
The EXCLUSIVE_GET path in _regulator_get() now initializes
enable_count along with rdev->use_count so that the regulator can be
disabled without underflowing the former.
Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Fixes: 5451781dad ("regulator: core: Only count load for enabled consumers")
Link: https://lore.kernel.org/r/20220505043152.12933-1-zev@bewilderbeest.net
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 4e2a354e3775870ca823f1fb29bbbffbe11059a6 ]
The check done by regulator_late_cleanup() to detect whether a regulator
is on was inconsistent with the check done by _regulator_is_enabled().
While _regulator_is_enabled() takes the enable GPIO into account,
regulator_late_cleanup() was not doing that.
This resulted in a false positive, e.g. when a GPIO-controlled fixed
regulator was used, which was not enabled at boot time, e.g.
reg_disp_1v2: reg_disp_1v2 {
compatible = "regulator-fixed";
regulator-name = "display_1v2";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
gpio = <&tlmm 148 0>;
enable-active-high;
};
Such regulator doesn't have an is_enabled() operation. Nevertheless
it's state can be determined based on the enable GPIO. The check in
regulator_late_cleanup() wrongly assumed that the regulator is on and
tried to disable it.
Signed-off-by: Oliver Barta <oliver.barta@aptiv.com>
Link: https://lore.kernel.org/r/20220208084645.8686-1-oliver.barta@aptiv.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Extend regulator notification support
This series extends the regulator notification and error flag support.
Initial discussion on the topic can be found here:
https://lore.kernel.org/lkml/6046836e22b8252983f08d5621c35ececb97820d.camel@fi.rohmeurope.com/
In a nutshell - the series adds:
1. WARNING level events/error flags. (Patch 3)
Current regulator 'ERROR' event notifications for over/under
voltage, over current and over temperature are used to indicate
condition where monitored entity is so badly "off" that it actually
indicates a hardware error which can not be recovered. The most
typical hanling for that is believed to be a (graceful)
system-shutdown. Here we add set of 'WARNING' level flags to allow
sending notifications to consumers before things are 'that badly off'
so that consumer drivers can implement recovery-actions.
2. Device-tree properties for specifying limit values. (Patches 1, 5)
Add limits for above mentioned 'ERROR' and 'WARNING' levels (which
send notifications to consumers) and also for a 'PROTECTION' level
(which will be used to immediately shut-down the regulator(s) W/O
informing consumer drivers. Typically implemented by hardware).
Property parsing is implemented in regulator core which then calls
callback operations for limit setting from the IC drivers. A
warning is emitted if protection is requested by device tree but the
underlying IC does not support configuring requested protection.
3. Helpers which can be registered by IC. (Patch 4)
Target is to avoid implementing IRQ handling and IRQ storm protection
in each IC driver. (Many of the ICs implementin these IRQs do not allow
masking or acking the IRQ but keep the IRQ asserted for the whole
duration of problem keeping the processor in IRQ handling loop).
4. Emergency poweroff function (refactored out of the thermal_core to
kernel/reboot.c) which is called if IC fires error IRQs but IC reading
fails and given retry-count is exceeded. (Patches 2, 4)
Please note that the mutex in the emergency shutdown was replaced by a
simple atomic in order to allow call from any context.
The helper was attempted to be done so it could be used to implement
roughly same logic as is used in qcom-labibb regulator. This means
amongst other things a safety shut-down if IC registers are not readable.
Using these shut-down retry counters are optional. The idea is that the
helper could be also used by simpler ICs which do not provide status
register(s) which can be used to check if error is still active.
ICs which do not have such status register can simply omit the 'renable'
callback (and retry-counts etc) - and helper assumes the situation is Ok
and re-enables IRQ after given time period. If problem persists the
handler is ran again and another notification is sent - but at least the
delay allows processor to avoid IRQ loop.
Patch 7 takes this notification support in use at BD9576MUF.
Patch 8 is related to MFD change which is not really related to the RFC
here. It was added to this series in order to avoid potential conflicts.
Patch 9 adds a maintainers entry.
Changelog v10-RESEND:
- rebased on v5.13-rc4
Changelog v10:
- rebased on v5.13-rc2
- Move rdev_*() print macros to the internal.h and use rdev_dbg()
from irq_helpers.c
- Export rdev_get_name() and move it from coupler.h to driver.h for
others to use. (It was already in coupler.h but not exported -
usage was limited and coupler.h does not sound like optimal place
as rdev_name is not only used by coupled regulators)
- Send all regulator notifications from irq_helpers.c at one OR'd
event for the sake of simplicity. For BD9576 this does not matter
as it has own IRQ for each event case. Header defining events says
they may be OR'd.
- Change WARN() at protection shutdown to pr_emerg as suggested by
Petr.
Changelog v9:
- rebases on v5.13-rc1
- Update thermal documentation
- Fix regulator notification event number
Changelog v8:
- split shutdown API adding and thermal core taking it in use to
own patches.
- replace the spinlock with atomic when ensuring the emergency
shutdown is only called once.
Changelog v7:
general:
- rebased on v5.12-rc7
- new patch for refactoring the hw-failure reboot logic out of
thermal_core.c for others to use.
notification helpers:
- fix regulator error_flags query
- grammar/typos
- do not BUG() but attempt to shut-down the system
- use BITS_PER_TYPE()
Changelog v6:
Add MAINTAINERS entry
Changes to IRQ notifiers
- move devm functions to drivers/regulator/devres.c
- drop irq validity check
- use devm_add_action_or_reset()
- fix styling issues
- fix kerneldocs
Changelog v5:
- Fix the badly formatted pr_emerg() call.
Changelog v4:
- rebased on v5.12-rc6
- dropped RFC
- fix external FET DT-binding.
- improve prints for cases when expecting HW failure.
- styling and typos
Changelog v3:
Regulator core:
- Fix dangling pointer access at regulator_irq_helper()
stpmic1_regulator:
- fix function prototype (compile error)
bd9576-regulator:
- Update over current limits to what was given in new data-sheet
(REV00K)
- Allow over-current monitoring without external FET. Set limits to
values given in data-sheet (REV00K).
Changelog v2:
Generic:
- rebase on v5.12-rc2 + BD9576 series
- Split devm variant of delayed wq to own series
Regulator framework:
- Provide non devm variant of IRQ notification helpers
- shorten dt-property names as suggested by Rob
- unconditionally call map_event in IRQ handling and require it to be
populated
BD9576 regulators:
- change the FET resistance property to micro-ohms
- fix voltage computation in OC limit setting
Some NVIDIA Tegra devices use a CPU soft-reset method for the reboot and
in this case we need to restore the coupled voltages to the state that is
suitable for hardware during boot. Add new regulator_sync_voltage_rdev()
helper which is needed by regulator drivers in order to sync voltage of
a coupled regulators.
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The jiffies-based off_on_delay implementation has a couple of problems
that cause it to sometimes not actually delay for the required time:
(1) If, for example, the off_on_delay time is equivalent to one jiffy,
and the ->last_off_jiffy is set just before a new jiffy starts,
then _regulator_do_enable() does not wait at all since it checks
using time_before().
(2) When jiffies overflows, the value of "remaining" becomes higher
than "max_delay" and the code simply proceeds without waiting.
Fix these problems by changing it to use ktime_t instead.
[Note that since jiffies doesn't start at zero but at INITIAL_JIFFIES
("-5 minutes"), (2) above also led to the code not delaying if
the first regulator_enable() is called when the ->last_off_jiffy is not
initialised, such as for regulators with ->constraints->boot_on set.
It's not clear to me if this was intended or not, but I've preserved
this behaviour explicitly with the check for a non-zero ->last_off.]
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Link: https://lore.kernel.org/r/20210423114524.26414-1-vincent.whitchurch@axis.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We currently do not respect off_on_delay the first time we turn on a
regulator. This is problematic since the regulator could have been
turned off by the bootloader, or it could it have been turned off during
the probe of the regulator driver (such as when regulator-fixed requests
the enable GPIO), either of which could potentially have happened less
than off_on_delay microseconds ago before the first time a client
requests for the regulator to be turned on.
We can't know exactly when the regulator was turned off, but initialise
off_on_delay to the current time when registering the regulator, so that
we guarantee that we respect the off_on_delay in all cases.
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Link: https://lore.kernel.org/r/20210422083044.11479-1-vincent.whitchurch@axis.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Sometimes regulator_get() gets called twice for the same supply on the
same device. This may happen e.g. when a framework / library is used
which uses the regulator; and the driver itself also needs to enable
the regulator in some cases where the framework will not enable it.
Commit ff268b56ce ("regulator: core: Don't spew backtraces on
duplicate sysfs") already takes care of the backtrace which would
trigger when creating a duplicate consumer symlink under
/sys/class/regulator/regulator.%d in this scenario.
Commit c33d442328 ("debugfs: make error message a bit more verbose")
causes a new error to get logged in this scenario:
[ 26.938425] debugfs: Directory 'wm5102-codec-MICVDD' with parent 'spi-WM510204:00-MICVDD' already present!
There is no _nowarn variant of debugfs_create_dir(), but we can detect
and avoid this problem by checking the return value of the earlier
sysfs_create_link_nowarn() call.
Add a check for the earlier sysfs_create_link_nowarn() failing with
-EEXIST and skip the debugfs_create_dir() call in that case, avoiding
this error getting logged.
Fixes: c33d442328 ("debugfs: make error message a bit more verbose")
Cc: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20210122183250.370571-1-hdegoede@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
With commit eaa7995c52 (regulator: core: avoid
regulator_resolve_supply() race condition) we started holding the rdev
lock while resolving supplies, an operation that requires holding the
regulator_list_mutex. This results in lockdep warnings since in other
places we take the list mutex then the mutex on an individual rdev.
Since the goal is to make sure that we don't call set_supply() twice
rather than a concern about the cost of resolution pull the rdev lock
and check for duplicate resolution down to immediately before we do the
set_supply() and drop it again once the allocation is done.
Fixes: eaa7995c52 (regulator: core: avoid regulator_resolve_supply() race condition)
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210122132042.10306-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The final step in regulator_register() is to call
regulator_resolve_supply() for each registered regulator
(including the one in the process of being registered). The
regulator_resolve_supply() function first checks if rdev->supply
is NULL, then it performs various steps to try to find the supply.
If successful, rdev->supply is set inside of set_supply().
This procedure can encounter a race condition if two concurrent
tasks call regulator_register() near to each other on separate CPUs
and one of the regulators has rdev->supply_name specified. There
is currently nothing guaranteeing atomicity between the rdev->supply
check and set steps. Thus, both tasks can observe rdev->supply==NULL
in their regulator_resolve_supply() calls. This then results in
both creating a struct regulator for the supply. One ends up
actually stored in rdev->supply and the other is lost (though still
present in the supply's consumer_list).
Here is a kernel log snippet showing the issue:
[ 12.421768] gpu_cc_gx_gdsc: supplied by pm8350_s5_level
[ 12.425854] gpu_cc_gx_gdsc: supplied by pm8350_s5_level
[ 12.429064] debugfs: Directory 'regulator.4-SUPPLY' with parent
'17a00000.rsc:rpmh-regulator-gfxlvl-pm8350_s5_level'
already present!
Avoid this race condition by holding the rdev->mutex lock inside
of regulator_resolve_supply() while checking and setting
rdev->supply.
Signed-off-by: David Collins <collinsd@codeaurora.org>
Link: https://lore.kernel.org/r/1610068562-4410-1-git-send-email-collinsd@codeaurora.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The function regulator_set_device_supply() is referenced a few times in
comments in regulator/core.c; however this function was removed a long
time ago by commit a5766f11cf ("regulator: core - Rework machine API to
remove string based functions."). Update those references to point to
set_consumer_device_supply(), which replaced the old function.
Signed-off-by: Daniel Scally <djrscally@gmail.com>
Link: https://lore.kernel.org/r/20210103165541.784360-1-djrscally@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Hi,
This series adds support for ramp delay on mcp16502. It also adds
some cleanup on mcp16502.
Apart from that patches 1/6 fixes the selector validation in case
the regulator::desc::linear_min_sel is not zero.
Thank you,
Claudiu Beznea
Changes in v3:
- fix compilation error in patch 5/6
Reported-by: kernel test robot <lkp@intel.com>
Changes in v2:
- rebase on top of regulator/for-next
- checked 1/6 and 3/6 applies on top of regulator/for-5.10
Claudiu Beznea (6):
regulator: core: validate selector against linear_min_sel
regulator: core: do not continue if selector match
regulator: mcp16502: add linear_min_sel
regulator: mcp16502: adapt for get/set on other registers
regulator: mcp16502: add support for ramp delay
regulator: mcp16502: remove void documentation of struct mcp16502
drivers/regulator/core.c | 12 +++-
drivers/regulator/helpers.c | 3 +-
drivers/regulator/mcp16502.c | 135 ++++++++++++++++++++++++++++++++++++-------
3 files changed, 127 insertions(+), 23 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.orghttp://lists.infradead.org/mailman/listinfo/linux-arm-kernel
If debugging is disabled, print_constraints() does not print the actual
constraints, but still performs some processing and string formatting,
only to throw away the result later.
Fix this by moving all constraint debug processing to a separate
function, and replacing it by a dummy when debugging is disabled.
This reduces kernel size by almost 800 bytes (on arm/arm64).
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20201005131546.22448-1-geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
Some regulator drivers may be defining very long names: this is the
case with the qcom_smd and qcom_spmi regulators, where we need to
parse the regulator parents from DT.
For clarity, this is an example:
{ "l13a", QCOM_SMD_RPM_LDOA, 13, &pm660_ht_lvpldo,
"vdd_l8_l9_l10_l11_l12_l13_l14" },
pm660-regulators {
...
vdd_l8_l9_l10_l11_l12_l13_l14-supply = <&vreg_s4a_2p04>
...
};
Now, with a 32 characters limit, the function is trying to parse,
exactly, "vdd_l8_l9_l10_l11_l12_l13_l14-s" (32 chars) instead of
the right one, which is 37 chars long in this specific case.
... And this is not only the case with PM660/PM660L, but also with
PMA8084, PM8916, PM8950 and others that are not implemented yet.
The length of 64 chars was chosen based on the longest parsed property
name that I could find, which is in PM8916, and would be 53 characters
long.
At that point, rounding that to 64 looked like being the best idea.
Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com>
Link: https://lore.kernel.org/r/20200926125549.13191-2-kholk11@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When creating a new regulator its supply cannot create the sysfs link
because the device is not yet published. Remove early supply resolving
since it will be done later anyway. This makes the following error
disappear and the symlinks get created instead.
DCDC_REG1: supplied by VSYS
VSYS: could not add device link regulator.3 err -2
Note: It doesn't fix the problem for bypassed regulators, though.
Fixes: 45389c4752 ("regulator: core: Add early supply resolution for regulators")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/ba09e0a8617ffeeb25cb4affffe6f3149319cef8.1601155770.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
