This commit introduces netlink event support to the regulator subsystem.
Changes:
- Introduce event.c and regnl.h for netlink event handling.
- Implement reg_generate_netlink_event to broadcast regulator events.
- Update Makefile to include the new event.c file.
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Link: https://lore.kernel.org/r/20231205105207.1262928-1-naresh.solanki@9elements.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The use_count of a regulator should only be incremented when the
enable_count changes from 0 to 1. Similarly, the use_count should
only be decremented when the enable_count changes from 1 to 0.
In the previous implementation, use_count was sometimes decremented
to 0 when some consumer called unbalanced disable,
leading to unexpected disable even the regulator is enabled by
other consumers. With this change, the use_count accurately reflects
the number of users which the regulator is enabled.
This should make things more robust in the case where a consumer does
leak references.
Signed-off-by: Rui Zhang <zr.zhang@vivo.com>
Link: https://lore.kernel.org/r/20231103074231.8031-1-zr.zhang@vivo.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This may be useful for debugging and develompent purposes, when there are
drivers that depend on regulators to be enabled but do not request them.
It is inspired from the clk_ignore_unused and pd_ignore_unused parameters,
that are used to keep firmware-enabled clocks and power domains on even if
these are not used by drivers.
The parameter is not expected to be used in normal cases and should not be
needed on a platform with proper driver support.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20231107190926.1185326-1-javierm@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add 'uv_survival_time' field to regulation_constraints for specifying
survival time post critical under-voltage event. Update the regulator
notifier call chain and Device Tree property parsing to use this new
field, allowing a configurable timeout before emergency shutdown.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20231026144824.4065145-6-o.rempel@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Handle under-voltage events for crucial regulators to maintain system
stability and avoid issues during power drops.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20231026144824.4065145-3-o.rempel@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
When fixing a memory leak in commit d3c731564e ("regulator: plug
of_node leak in regulator_register()'s error path") it moved the
device_initialize() call earlier, but did not move the `dev->class`
initialization. The bug was spotted and fixed by reverting part of
the commit (in commit 5f4b204b6b "regulator: core: fix kobject
release warning and memory leak in regulator_register()") but
introducing a different bug: now early error paths use `kfree(dev)`
instead of `put_device()` for an already initialized `struct device`.
Move the missing assignments to just after `device_initialize()`.
Fixes: d3c731564e ("regulator: plug of_node leak in regulator_register()'s error path")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/b5b19cb458c40c9d02f3d5a7bd1ba7d97ba17279.1695077303.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
If CONFIG_DEBUG_FS is not set:
regulator: Failed to create debugfs directory
...
regulator-dummy: Failed to create debugfs directory
As per the comments for debugfs_create_dir(), errors returned by this
function should be expected, and ignored:
* If debugfs is not enabled in the kernel, the value -%ENODEV will be
* returned.
*
* NOTE: it's expected that most callers should _ignore_ the errors returned
* by this function. Other debugfs functions handle the fact that the "dentry"
* passed to them could be an error and they don't crash in that case.
* Drivers should generally work fine even if debugfs fails to init anyway.
Adhere to the debugfs spirit, and streamline all operations by:
1. Demoting the importance of the printed error messages to debug
level, like is already done in create_regulator(),
2. Further ignoring any returned errors, as by design, all debugfs
functions are no-ops when passed an error pointer.
Fixes: 2bf1c45be3 ("regulator: Fix error checking for debugfs_create_dir")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/2f8bb6e113359ddfab7b59e4d4274bd4c06d6d0a.1685013051.git.geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
In case of failure, debugfs_create_dir() does not return NULL, but an
error pointer. Most incorrect error checks were fixed, but the one in
create_regulator() was forgotten.
Fix the remaining error check.
Fixes: 2bf1c45be3 ("regulator: Fix error checking for debugfs_create_dir")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/ee980a108b5854dd8ce3630f8f673e784e057d17.1685013051.git.geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch fixes the error checking in core.c in debugfs_create_dir.
The correct way to check if an error occurred is 'IS_ERR' inline function.
Signed-off-by: Osama Muhammad <osmtendev@gmail.com
Suggested-by: Ivan Orlov <ivan.orlov0322@gmail.com
Link: https://lore.kernel.org/r/20230515172938.13338-1-osmtendev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org
An automated bot told me that there was a potential lockdep problem
with regulators. This was on the chromeos-5.15 kernel, but I see
nothing that would be different downstream compared to upstream. The
bot said:
============================================
WARNING: possible recursive locking detected
5.15.104-lockdep-17461-gc1e499ed6604 #1 Not tainted
--------------------------------------------
kworker/u16:4/115 is trying to acquire lock:
ffffff8083110170 (regulator_ww_class_mutex){+.+.}-{3:3}, at: create_regulator+0x398/0x7ec
but task is already holding lock:
ffffff808378e170 (regulator_ww_class_mutex){+.+.}-{3:3}, at: ww_mutex_trylock+0x3c/0x7b8
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(regulator_ww_class_mutex);
lock(regulator_ww_class_mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by kworker/u16:4/115:
#0: ffffff808006a948 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x520/0x1348
#1: ffffffc00e0a7cc0 ((work_completion)(&entry->work)){+.+.}-{0:0}, at: process_one_work+0x55c/0x1348
#2: ffffff80828a2260 (&dev->mutex){....}-{3:3}, at: __device_attach_async_helper+0xd0/0x2a4
#3: ffffff808378e170 (regulator_ww_class_mutex){+.+.}-{3:3}, at: ww_mutex_trylock+0x3c/0x7b8
stack backtrace:
CPU: 2 PID: 115 Comm: kworker/u16:4 Not tainted 5.15.104-lockdep-17461-gc1e499ed6604 #1 9292e52fa83c0e23762b2b3aa1bacf5787a4d5da
Hardware name: Google Quackingstick (rev0+) (DT)
Workqueue: events_unbound async_run_entry_fn
Call trace:
dump_backtrace+0x0/0x4ec
show_stack+0x34/0x50
dump_stack_lvl+0xdc/0x11c
dump_stack+0x1c/0x48
__lock_acquire+0x16d4/0x6c74
lock_acquire+0x208/0x750
__mutex_lock_common+0x11c/0x11f8
ww_mutex_lock+0xc0/0x440
create_regulator+0x398/0x7ec
regulator_resolve_supply+0x654/0x7c4
regulator_register_resolve_supply+0x30/0x120
class_for_each_device+0x1b8/0x230
regulator_register+0x17a4/0x1f40
devm_regulator_register+0x60/0xd0
reg_fixed_voltage_probe+0x728/0xaec
platform_probe+0x150/0x1c8
really_probe+0x274/0xa20
__driver_probe_device+0x1dc/0x3f4
driver_probe_device+0x78/0x1c0
__device_attach_driver+0x1ac/0x2c8
bus_for_each_drv+0x11c/0x190
__device_attach_async_helper+0x1e4/0x2a4
async_run_entry_fn+0xa0/0x3ac
process_one_work+0x638/0x1348
worker_thread+0x4a8/0x9c4
kthread+0x2e4/0x3a0
ret_from_fork+0x10/0x20
The problem was first reported soon after we made many of the
regulators probe asynchronously, though nothing I've seen implies that
the problems couldn't have also happened even without that.
I haven't personally been able to reproduce the lockdep issue, but the
issue does look somewhat legitimate. Specifically, it looks like in
regulator_resolve_supply() we are holding a "rdev" lock while calling
set_supply() -> create_regulator() which grabs the lock of a
_different_ "rdev" (the one for our supply). This is not necessarily
safe from a lockdep perspective since there is no documented ordering
between these two locks.
In reality, we should always be locking a regulator before the
supplying regulator, so I don't expect there to be any real deadlocks
in practice. However, the regulator framework in general doesn't
express this to lockdep.
Let's fix the issue by simply grabbing the two locks involved in the
same way we grab multiple locks elsewhere in the regulator framework:
using the "wound/wait" mechanisms.
Fixes: eaa7995c52 ("regulator: core: avoid regulator_resolve_supply() race condition")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20230329143317.RFC.v2.2.I30d8e1ca10cfbe5403884cdd192253a2e063eb9e@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
When a codepath locks a rdev using ww_mutex_lock_slow() directly then
that codepath is responsible for incrementing the "ref_cnt" and also
setting the "mutex_owner" to "current".
The regulator core consistently got that right for "ref_cnt" but
didn't always get it right for "mutex_owner". Let's fix this.
It's unlikely that this truly matters because the "mutex_owner" is
only needed if we're going to do subsequent locking of the same
rdev. However, even though it's not truly needed it seems less
surprising if we consistently set "mutex_owner" properly.
Fixes: f8702f9e4a ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20230329143317.RFC.v2.1.I4e9d433ea26360c06dd1381d091c82bb1a4ce843@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
This is very close to a straight revert of commit 218320fec2
("regulator: core: Fix off-on-delay-us for always-on/boot-on
regulators"). We've identified that patch as causing a boot speed
regression on sc7180-trogdor boards. While boot speed certainly isn't
more important than making sure that power sequencing is correct,
looking closely at the original change it doesn't seem to have been
fully justified. It mentions "cycling issues" without describing
exactly what the issues were. That means it's possible that the
cycling issues were really a problem that should be fixed in a
different way.
Let's take a careful look at how we should handle regulators that have
an off-on-delay and that are boot-on or always-on. Linux currently
doesn't have any way to identify whether a GPIO regulator was already
on when the kernel booted. That means that when the kernel boots we
probe a regulator, see that it wants boot-on / always-on we, and then
turn the regulator on. We could be in one of two cases when we do
this:
a) The regulator might have been left on by the bootloader and we're
ensuring that it stays on.
b) The regulator might have been left off by the bootloader and we're
just now turning it on.
For case a) we definitely don't need any sort of delay. For case b) we
_might_ need some delay in case the bootloader turned the regulator
off _right_ before booting the kernel. To get the proper delay for
case b) then we can just assume a `last_off` of 0, which is what it
gets initialized to by default.
As per above, we can't tell whether we're in case a) or case b) so
we'll assume the longer delay (case b). This basically puts the code
to how it was before commit 218320fec2 ("regulator: core: Fix
off-on-delay-us for always-on/boot-on regulators"). However, we add
one important change: we make sure that the delay is actually honored
if `last_off` is 0. Though the original "cycling issues" cited were
vague, I'm hopeful that this important extra change will be enough to
fix the issues that the initial commit mentioned.
With this fix, I've confined that on a sc7180-trogdor board the delay
at boot goes down from 500 ms to ~250 ms. That's not as good as the 0
ms that we had prior to commit 218320fec2 ("regulator: core: Fix
off-on-delay-us for always-on/boot-on regulators"), but it's probably
safer because we don't know if the bootloader turned the regulator off
right before booting.
One note is that it's possible that we could be in a state that's not
a) or b) if there are other issues in the kernel. The only one I can
think of is related to pinctrl. If the pinctrl driver being used on a
board isn't careful about avoiding glitches when setting up a pin then
it's possible that setting up a pin could cause the regulator to "turn
off" briefly immediately before the regulator probes. If this is
indeed causing problems then the pinctrl driver should be fixed,
perhaps in a similar way to what was done in commit d21f4b7ffc
("pinctrl: qcom: Avoid glitching lines when we first mux to output")
Fixes: 218320fec2 ("regulator: core: Fix off-on-delay-us for always-on/boot-on regulators")
Cc: Christian Kohlschütter <christian@kohlschutter.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20230313111806.1.I2eaad872be0932a805c239a7c7a102233fb0b03b@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
For regulators with 'off-on-delay-us' the regulator framework currently
uses ktime_get() to determine how long the regulator has been off
before re-enabling it (after a delay if needed). A problem with using
ktime_get() is that it doesn't account for the time the system is
suspended. As a result a regulator with a longer 'off-on-delay' (e.g.
500ms) that was switched off during suspend might still incurr in a
delay on resume before it is re-enabled, even though the regulator
might have been off for hours. ktime_get_boottime() accounts for
suspend time, use it instead of ktime_get().
Fixes: a8ce7bd896 ("regulator: core: Fix off_on_delay handling")
Cc: stable@vger.kernel.org # 5.13+
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20230223003301.v2.1.I9719661b8eb0a73b8c416f9c26cf5bd8c0563f99@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
Two core fixes here, one for a long standing race which some Qualcomm
systems have started triggering with their UFS driver and another fixing
a problem with supply lookup introduced by the fixes for devm related
use after free issues that were introduced in this merge window.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmOmHd4ACgkQJNaLcl1U
h9A8hQf/fTezN966/Rp9tvP9YJOPmluqoqDxp/kbyfs3wXlhGR51rytXk/h0DDUD
U8VYIzIyJ7RyqNRtbSqoaNKTCq73Z2/eWl3O/Tsw/mVbpsPHbgDFG4qmM3wE88Rm
u6tOFHouTMQPSJ1yDWJrnR627uRQsnjmJbElSkSWXGWVtJnBqbj+QPGal+hXR/lv
0Fo3nvKvLG5W7GkRh7rRTBu+reJAM4piFQzWxWStiyQwgRLZzpPbgXmpPfto7J5L
WeRMEJkprUVdps+DuylnsHHPD1EA0sBwvs5FQ7yKFuWoejZLC/loW51uColwiIOw
uhQlLzm8WwLePjYQPatHDegxu056fg==
=YhNZ
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"Two core fixes here, one for a long standing race which some Qualcomm
systems have started triggering with their UFS driver and another
fixing a problem with supply lookup introduced by the fixes for devm
related use after free issues that were introduced in this merge
window"
* tag 'regulator-fix-v6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: core: fix deadlock on regulator enable
regulator: core: Fix resolve supply lookup issue
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>
From Marek's log, the previous change modify the parent of rdev.
https://lore.kernel.org/all/58b92e75-f373-dae7-7031-8abd465bb874@samsung.com/
In 'regulator_resolve_supply', it uses the parent DT node of rdev as the
DT-lookup starting node. But the parent DT node may not exist. This will
cause the NULL supply issue.
This patch modify the parent of rdev back to the device that provides
from 'regulator_config' in 'regulator_register'.
Fixes: 8f3cbcd6b4 ("regulator: core: Use different devices for resource allocation and DT lookup")
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1670981831-12583-1-git-send-email-u0084500@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Quite a quiet release for regulator, the diffstat is dominated by the
I2C migration to probe_new() and the newly added MT6357 driver. We've
just one framework addition and the rest is all new device support,
fixes and cleanups.
The framework addition is an API for requesting all regulators defined
in DT, this isn't great practice but has reasonable applications when
there is generic code handling devices on buses where the bus
specification doesn't include power. The immediate application is MDIO
but I believe there's others, it's another API that'll need an eye
keeping on it for undesirable usage.
- An API for requesting all regulators defined in DT.
- Conversion of lots of drivers to the I2C probe_new() API.
- Support for Mediatek MT6357, Qualcomm PM8550, PMR735a and
Richtek RT6190.
There's a cross tree merge with the I2C tree in order to use the new
i2c_client_get_device_id() helper in the conversions to probe_new().
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmOXIIcACgkQJNaLcl1U
h9DW8Af/SkLjUIhuMYrln1QBKvJfMOzAIOo8LeCRCU6E8IxsDu/zccEva6dqr/M/
DFkq5VBCH7cX7VIvaHLjED/VdM0n+JG35tzwv83TVuAohLW/qsRdO6RE9IRBJcUd
7wUj2gjUBjjnCwbpI0hTygqQHvIxO0deQVYoQsxF8VwJTQ+ufpA3TJ3tmxqeWvbd
N/qkLohCk9NoFgiMjzBxBonacaZEvHkjUtqRthHm/nx8Mdu9NhBb6ai6KIpN7EJD
CaY+nUOx/cW8YJWBaZ32bcnvRgtanJGWn+p49/JmUCu0lIEOX2r7jds/kBo/hWWl
akGDUTcmvZY0CfrJfbx+FJxcA1A7Jg==
=Dmpg
-----END PGP SIGNATURE-----
Merge tag 'regulator-v6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates from Mark Brown:
"Quite a quiet release for regulator, the diffstat is dominated by the
I2C migration to probe_new() and the newly added MT6357 driver. We've
just one framework addition and the rest is all new device support,
fixes and cleanups.
The framework addition is an API for requesting all regulators defined
in DT, this isn't great practice but has reasonable applications when
there is generic code handling devices on buses where the bus
specification doesn't include power. The immediate application is MDIO
but I believe there's others, it's another API that'll need an eye
keeping on it for undesirable usage.
Summary:
- An API for requesting all regulators defined in DT
- Conversion of lots of drivers to the I2C probe_new() API
- Support for Mediatek MT6357, Qualcomm PM8550, PMR735a and Richtek
RT6190"
* tag 'regulator-v6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (56 commits)
regulator: core: Use different devices for resource allocation and DT lookup
dt-bindings: Add missing 'unevaluatedProperties' to regulator nodes
regulator: qcom-labibb: Fix missing of_node_put() in qcom_labibb_regulator_probe()
regulator: add mt6357 regulator
regulator: dt-bindings: Add binding schema for mt6357 regulators
regulator: core: fix resource leak in regulator_register()
regulator: core: fix module refcount leak in set_supply()
regulator: core: fix use_count leakage when handling boot-on
regulator: rk808: Use dev_err_probe
regulator: rk808: reduce 'struct rk808' usage
regulator: Drop obsolete dependencies on COMPILE_TEST
regulator: pv88080-regulator: Convert to i2c's .probe_new()
regulator: pfuze100-regulator: Convert to i2c's .probe_new()
regulator: isl6271a-regulator: Convert to i2c's .probe_new()
regulator: fan53555: Convert to i2c's .probe_new()
regulator: act8865-regulator: Convert to i2c's .probe_new()
regulator: qcom-rpmh: Add support for PM8550 regulators
regulator: dt-bindings: qcom,rpmh: Add compatible for PM8550
regulator: tps65023-regulator: Convert to i2c's .probe_new()
regulator: tps62360-regulator: Convert to i2c's .probe_new()
...
Following by the below discussion, there's the potential UAF issue
between regulator and mfd.
https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/
From the analysis of Yingliang
CPU A |CPU B
mt6370_probe() |
devm_mfd_add_devices() |
|mt6370_regulator_probe()
| regulator_register()
| //allocate init_data and add it to devres
| regulator_of_get_init_data()
i2c_unregister_device() |
device_del() |
devres_release_all() |
// init_data is freed |
release_nodes() |
| // using init_data causes UAF
| regulator_register()
It's common to use mfd core to create child device for the regulator.
In order to do the DT lookup for init data, the child that registered
the regulator would pass its parent as the parameter. And this causes
init data resource allocated to its parent, not itself. The issue happen
when parent device is going to release and regulator core is still doing
some operation of init data constraint for the regulator of child device.
To fix it, this patch expand 'regulator_register' API to use the
different devices for init data allocation and DT lookup.
Reported-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1670311341-32664-1-git-send-email-u0084500@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If create_regulator() fails in set_supply(), the module refcount
needs be put to keep refcount balanced.
Fixes: e2c09ae7a7 ("regulator: core: Increase refcount for regulator supply's module")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221201122706.4055992-2-yangyingliang@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
This is more changes than I'd like this late although the diffstat is
still fairly small, I kept on holding off as new fixes came in to give
things time to soak in -next but should probably have tagged and sent an
additional pull request earlier.
There's some relatively large fixes to the twl6030 driver to fix issues
with the TWL6032 variant which resulted from some work on the core
TWL6030 driver, a couple of fixes for error handling paths (mostly in
the core), and a nice stability fix for the sgl51000 driver that's been
pulled out of a BSP.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmOBOHkACgkQJNaLcl1U
h9DSNwf+KFunln/2mpx6UrLa5kl5QQGDtBruEcEBkKnUAx/YZlZ2nFT08bV4V1D0
/STa4PZdThem89VBRClQvxdyPE4qKIUvWsLmTUXF9P48m11bI+PMGCBMoKgjs4ZL
jMTZi/JD+4oZcJcOG5Qu3rihdBxotrsvlk2QUMs+PaPx2JPyr1CpBXAseMkVcqrD
QzyRWUgCjS2bfnc9Xd7gll1MXeSIcN2oD14ec//5Wv0KItGs2i0cOCUY+U4Dffus
b+75g7sU4znCD6bcycKdTJEqcqrotrZycGnq3K36ycrAGulQrH4SwohEc2PUlnUa
ZrKBjC6iFkSutk0dYlSz4k7AfRzjrw==
=kf38
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v6.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"This is more changes than I'd like this late although the diffstat is
still fairly small, I kept on holding off as new fixes came in to give
things time to soak in -next but should probably have tagged and sent
an additional pull request earlier.
There's some relatively large fixes to the twl6030 driver to fix
issues with the TWL6032 variant which resulted from some work on the
core TWL6030 driver, a couple of fixes for error handling paths
(mostly in the core), and a nice stability fix for the sgl51000 driver
that's been pulled out of a BSP"
* tag 'regulator-fix-v6.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: twl6030: fix get status of twl6032 regulators
regulator: twl6030: re-add TWL6032_SUBCLASS
regulator: slg51000: Wait after asserting CS pin
regulator: core: fix UAF in destroy_regulator()
regulator: rt5759: fix OOB in validate_desc()
regulator: core: fix kobject release warning and memory leak in regulator_register()
Use kfree_const() to free supply_name conditionally in create_regulator()
as supply_name may be allocated from kmalloc() or directly from .rodata
section.
Fixes: 87fe29b61f ("regulator: push allocations in create_regulator() outside of lock")
Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
Link: https://lore.kernel.org/r/20221123034616.3609537-1-bobo.shaobowang@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
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>
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>
We had an exclusive variant of the devm_regulator_get() API, but no
corresponding variant for the bulk API; let's add one now. We add a
generalized version of the existing regulator_bulk_get() function that
additionally takes a get_type parameter and redefine
regulator_bulk_get() in terms of it, then do similarly with
devm_regulator_bulk_get(), and finally add the new
devm_regulator_bulk_get_exclusive().
Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Link: https://lore.kernel.org/r/20221031233704.22575-2-zev@bewilderbeest.net
Signed-off-by: Mark Brown <broonie@kernel.org>
The core work this time around has mostly been around the code to manage
regulator modes, simplifying the interface for configuring modes to not
take account of the voltage and as a side effect resolving a
bootstrapping issue on systems where we can't read the voltage from the
regulator. Otherwise it's been quite a quiet release with some new
drivers and a devm helper:
- Make the load handling in the Qualcomm RPMH regulators much more
idiomatic and general cleanups to the handling of load configuration.
- devm helper for a combined get and enable operation.
- Support for MediaTek MT6331, Qualcomm PM660, 660L and PM6125, Texas
Instruments TPS65219.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmM61ZQACgkQJNaLcl1U
h9BGggf+MraXhaTOSrLCzKYjcsjIZ2OCzySoKPdh9PdvnKc2PX+vIi6SYjq6zeAe
OlwDvKzW+bR6VRTStSskK5wRXrLn/9eo25GhZyl4BpAR+vjGBtzlNagk3gGTBKMj
ua/kb16FV+15Zg5L1qO35ka9BuCzs2Bfz9OoZKy4vtuqVqazmrU3PS8nr/kAlW9R
fi7a50Ybc+W7xBYUNuaKqdFQWlblLh/UKqImV9dANokXZDD9deJ8BeWq/FttNY6T
lyTJGDuKYhcvb7wx8QdzcSCoLsdVPRi0cmIlbjiusWogyvJBQVhto338Y8+b7vIJ
29tlD54gmWXSxwf0e8CpHKh/BxwbAw==
=YFsi
-----END PGP SIGNATURE-----
Merge tag 'regulator-v6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates from Mark Brown:
"The core work this time around has mostly been around the code to
manage regulator modes, simplifying the interface for configuring
modes to not take account of the voltage and as a side effect
resolving a bootstrapping issue on systems where we can't read the
voltage from the regulator.
Otherwise it's been quite a quiet release with some new drivers and a
devm helper:
- Make the load handling in the Qualcomm RPMH regulators much more
idiomatic and general cleanups to the handling of load
configuration
- devm helper for a combined get and enable operation
- Support for MediaTek MT6331, Qualcomm PM660, 660L and PM6125, Texas
Instruments TPS65219"
* tag 'regulator-v6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (45 commits)
dt-bindings: gpio-regulator: add vin-supply property support
regulator: gpio: Add input_supply support in gpio_regulator_config
regulator: tps65219: Fix is_enabled checking in tps65219_set_bypass
regulator: qcom,rpmh: add pm660 and pm660l pmics
regulator: qcom-rpmh: add pm660 and pm660l pmics
regulator: of: Fix kernel-doc
regulator: of: Fix kernel-doc
regulator: Add driver for MT6332 PMIC regulators
regulator: Add bindings for MT6332 regulator
regulator: Add driver for MT6331 PMIC regulators
regulator: Add bindings for MT6331 regulator
regulator: tps65219: Fix .bypass_val_on setting
regulator: qcom_rpm: Fix circular deferral regression
regulator: core: Prevent integer underflow
regulator: dt-bindings: qcom,rpmh: Indicate regulator-allow-set-load dependencies
regulator: bd9576: switch to using devm_fwnode_gpiod_get()
regulator: bd71815: switch to using devm_fwnode_gpiod_get()
regulator: core: Fix regulator supply registration with sysfs
regulator: tps65219: change tps65219_regulator_irq_types to static
regulator: core: Don't err if allow-set-load but no allowed-modes
...
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>
One core fix here improving the error handling on enable failure, plus
smaller fixes for the pfuze100 drive and the SPMI DT bindings.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmMZ3IUACgkQJNaLcl1U
h9CwbQf6AzcfEH0QTrQrkJV5m0lWfpxSdmxWg2NSmKDsCUTEg4KKV86+iGbOax1y
StciVjWKBQ7nTwX7d2tWYL67ogziN4ePFdroKzIHMkj50+qWfy1KsopsWgm6joYj
YCfWro3f2LHD7CC70qsd1yoVV4mO+yzdwkc0qtxQe4l9rvsdfA8VH80MjGyWaxUO
dz8BjLAk3ivCsCTCGFkL3k51HLm7ORbX8ruCqFnW3a6neblliIP/z+MkNhLgZC7q
+P3GGbBYYs1d9Ay5IIM04FszhJEOfG7RSeqMosi6gCl2r8Vw3UNJ7rUyH/cGTwyV
eZFTgd89kiVg1I97FxbI4Wb1SjPg0A==
=97j3
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v6.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"One core fix here improving the error handling on enable failure, plus
smaller fixes for the pfuze100 drive and the SPMI DT bindings"
* tag 'regulator-fix-v6.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: Fix qcom,spmi-regulator schema
regulator: pfuze100: Fix the global-out-of-bounds access in pfuze100_regulator_probe()
regulator: core: Clean up on enable failure
In "regulator: core: Resolve supply name earlier to prevent
double-init", we introduced a bug that prevented the regulator names
from registering properly with sysfs.
Reorder regulator_register such that supply names are properly resolved
and registered.
Fixes: 8a866d527a ("regulator: core: Resolve supply name earlier to prevent double-init")
Link: https://lore.kernel.org/all/58b92e75-f373-dae7-7031-8abd465bb874@samsung.com/
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20220829165543.24856-1-christian@kohlschutter.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Apparently the device trees of some boards have the property
"regulator-allow-set-load" for some of their regulators but then they
don't specify anything for "regulator-allowed-modes". That's not
really legit, but...
...before commit efb0cb50c4 ("regulator: qcom-rpmh: Implement
get_optimum_mode(), not set_load()") they used to get away with it, at
least on boards using RPMH regulators. That's because when a regulator
driver implements set_load() then the core doesn't look at
"regulator-allowed-modes" when trying to automatically adjust things
in response to the regulator's load. The core doesn't know what mode
we'll end up in, so how could it validate it?
Said another way: before commit efb0cb50c4 ("regulator: qcom-rpmh:
Implement get_optimum_mode(), not set_load()") some boards _were_
having the regulator mode adjusted despite listing no allowed
modes. After commit efb0cb50c4 ("regulator: qcom-rpmh: Implement
get_optimum_mode(), not set_load()") these same boards were now
getting an error returned when trying to use their regulators, since
simply enabling a regulator tries to update its load and that was
failing.
We don't really want to go back to the behavior from before commit
efb0cb50c4 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not
set_load()"). Boards shouldn't have been changing modes if no allowed
modes were listed. However, the behavior after commit efb0cb50c4
("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()")
isn't the best because now boards can't even turn their regulators on.
Let's choose to detect this case and return "no error" from
drms_uA_update(). The net-result will be _different_ behavior than we
had before commit efb0cb50c4 ("regulator: qcom-rpmh: Implement
get_optimum_mode(), not set_load()"), but this new behavior seems more
correct. If a board truly needed the mode switched then its device
tree should be updated to list the allowed modes.
Reported-by: Andrew Halaney <ahalaney@redhat.com>
Fixes: efb0cb50c4 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Andrew Halaney <ahalaney@redhat.com>
Link: https://lore.kernel.org/r/20220824142229.RFT.v2.2.I6f77860e5cd98bf5c67208fa9edda4a08847c304@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
The get_optimum_mode() for regulator drivers is passed the input
voltage and output voltage as well as the current. This is because, in
theory, the optimum mode can depend on all three things.
It turns out that for all regulator drivers in mainline only the
current is looked at when implementing get_optimum_mode(). None of the
drivers take the input or output voltage into account. Despite the
fact that none of the drivers take the input or output voltage into
account, though, the regulator framework will error out before calling
into get_optimum_mode() if it doesn't know the input or output
voltage.
The above behavior turned out to be a probelm for some boards when we
landed commit efb0cb50c4 ("regulator: qcom-rpmh: Implement
get_optimum_mode(), not set_load()"). Before that change we'd have no
problems running drms_uA_update() for RPMH regulators even if a
regulator's input or output voltage was unknown. After that change
drms_uA_update() started to fail. This is because typically boards
using RPMH regulators don't model the input supplies of RPMH
regulators. Input supplies for RPMH regulators nearly always come from
the output of other RPMH regulators (or always-on regulators) and RPMH
firmware is initialized with this knowledge and handles enabling (and
adjusting the voltage of) input supplies. While we could model the
parent/child relationship of the regulators in Linux, many boards
don't bother since it adds extra overhead.
Let's change the regulator core to make things work again. Now if we
fail to get the input or output voltage we'll still call into
get_optimum_mode() and we'll just pass error codes in for input_uV
and/or output_uV parameters.
Since no existing regulator drivers even look at input_uV and
output_uV we don't need to add this error handling anywhere right
now. We'll add some comments in the core so that it's obvious that (if
regulator drivers care) it's up to them to add the checks.
Reported-by: Andrew Halaney <ahalaney@redhat.com>
Fixes: efb0cb50c4 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Andrew Halaney <ahalaney@redhat.com>
Link: https://lore.kernel.org/r/20220824142229.RFT.v2.1.I137e6bef4f6d517be7b081be926059321102fd3d@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
Previously, an unresolved regulator supply reference upon calling
regulator_register on an always-on or boot-on regulator caused
set_machine_constraints to be called twice.
This in turn may initialize the regulator twice, leading to voltage
glitches that are timing-dependent. A simple, unrelated configuration
change may be enough to hide this problem, only to be surfaced by
chance.
One such example is the SD-Card voltage regulator in a NanoPI R4S that
would not initialize reliably unless the registration flow was just
complex enough to allow the regulator to properly reset between calls.
Fix this by re-arranging regulator_register, trying resolve the
regulator's supply early enough that set_machine_constraints does not
need to be called twice.
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
Link: https://lore.kernel.org/r/20220818124646.6005-1-christian@kohlschutter.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In commit 6eabfc018e ("regulator: core: Allow specifying an initial
load w/ the bulk API") I changed the error handling but had a subtle
that caused us to always return no error even if there was an
error. Fix it.
Fixes: 6eabfc018e ("regulator: core: Allow specifying an initial load w/ the bulk API")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20220809142738.1.I91625242f137c707bb345c51c80c5ecee02eeff3@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Douglas Anderson <dianders@chromium.org>:
The main goal of this series is to make a small dent in cleaning up
the way we deal with regulator loads. The idea is to add some extra
functionality to the regulator "bulk" API so that consumers can
specify the load using that.
There are a number of drivers that follow a pattern that looks like
this:
1. Use the regulator bulk API to get a bunch of regulators.
2. Set the load on each of the regulators to use whenever the
regulators are enabled.
Let's make this easier by just allowing the drivers to pass the load
in.
As part of this change we need to move the error printing in
regulator_bulk_get() around; let's switch to the new dev_err_probe()
to simplify it.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20220726103631.v2.4.Ie85f68215ada39f502a96dcb8a1f3ad977e3f68a@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
Regulators marked with "regulator-always-on" or "regulator-boot-on"
as well as an "off-on-delay-us", may run into cycling issues that are
hard to detect.
This is caused by the "last_off" state not being initialized in this
case.
Fix the "last_off" initialization by setting it to the current kernel
time upon initialization, regardless of always_on/boot_on state.
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
Link: https://lore.kernel.org/r/FAFD5B39-E9C4-47C7-ACF1-2A04CD59758D@kohlschutter.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
If a regulator provides a get_error_flags() operation, its sysfs
attributes will now include an entry for each defined
REGULATOR_ERROR_* flag.
Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Link: https://lore.kernel.org/r/20220504065252.6955-3-zev@bewilderbeest.net
Signed-off-by: Mark Brown <broonie@kernel.org>
These delays can be relatively large (e.g., hundreds of microseconds to
several milliseconds on RK3399 Gru systems). Per
Documentation/timers/timers-howto.rst, that should usually use a
sleeping delay. Let's use the existing regulator delay helper to handle
both large and small delays appropriately. This avoids burning a bunch
of CPU time and hurting scheduling latencies when hitting regulators a
lot (e.g., during cpufreq).
The sleep vs. delay issue choice has been made differently over time --
early versions of RK3399 Gru PWM-regulator support used usleep_range()
in pwm-regulator.c. More of this got moved into the regulator core,
in commits like:
73e705bf81 regulator: core: Add set_voltage_time op
At the same time, the sleep turned into a delay.
It's OK to sleep in _regulator_do_set_voltage(), as we aren't in an
atomic context. (All our callers grab various mutexes already.)
I avoid using fsleep() because it uses a usleep_range() of [N to N*2],
and usleep_range() very commonly biases to the high end of the range. We
don't want to double the expected delay, especially for long delays.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Link: https://lore.kernel.org/r/20220420141511.v2.2.If0fc61a894f537b052ca41572aff098cf8e7e673@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
While we currently assume that regulators with no control available are
just uncontionally enabled this isn't always as clearly displayed to
users as is desirable, for example the code for disabling unused
regulators will log that it is about to disable them. Clean this up a
bit by setting always_on during constraint evaluation if we have no
available mechanism for controlling the regualtor so things that check
the constraint will do the right thing.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220325144637.1543496-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
