kernel/linux.git/drivers/regulator/core.c, branch v6.19.11

regulator: core: Remove regulator supply_name length limit

2026-03-04T12:20:46+00:00

[ Upstream commit e243cdd87b911ce9968b62e4ab2b680dfadc4341 ] When creating the regulator object, associated with a consumer device, the supply_name is string formatted into a statically sized buffer on the stack, then strdup()'ed onto the heap. Not only is the dance on the stack unnecessary, but when the device's name is long we might not fit the constructed supply_name in the fixed 64 byte buffer on the stack. One such case can be seen on the Qualcomm Rb3Gen2 board, where we find a PCIe controller, with a PCIe switch, with a USB controller, with a USB hub, consuming a regulator. In this example the dev->kobj.name itself is 62 characters long. Drop the temporary buffer on the stack and kasprintf() the string directly on the heap, both to simplify the code, and to remove the length limitation. Signed-off-by: Bjorn Andersson Link: https://patch.msgid.link/20260211-regulator-supply-name-length-v1-1-3875541c1576@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: core: don't ignore errors from event forwarding setup

2026-02-26T23:00:59+00:00

[ Upstream commit e23c0a59dabae9166bbea26fc05d08e7d9e900b7 ] Receiving and forwarding critical supply events seems like they're important information and we shouldn't ignore errors occurring during registration for such events. With this change the supply is unset on event registration failure, allowing us to potentially retry another time. Fixes: 433e294c3c5b ("regulator: core: forward undervoltage events downstream by default") Signed-off-by: André Draszik Link: https://patch.msgid.link/20260109-regulators-defer-v2-6-1a25dc968e60@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: core: move supply check earlier in set_machine_constraints()

2026-02-26T23:00:59+00:00

[ Upstream commit 86a8eeb0e913f4b6a55dabba5122098d4e805e55 ] Since commit 98e48cd9283d ("regulator: core: resolve supply for boot-on/always-on regulators"), set_machine_constraints() can return -EPROBE_DEFER very late, after it has done a lot of work and configuration of the regulator. This means that configuration will happen multiple times for no benefit in that case. Furthermore, this can lead to timing-dependent voltage glitches as mentioned e.g. in commit 8a866d527ac0 ("regulator: core: Resolve supply name earlier to prevent double-init"). We can know that it's going to fail very early, in particular before going through the complete regulator configuration by moving some code around a little. Do so to avoid re-configuring the regulator multiple times, also avoiding the voltage glitches if we can. Fixes: 98e48cd9283d ("regulator: core: resolve supply for boot-on/always-on regulators") Signed-off-by: André Draszik Link: https://patch.msgid.link/20260109-regulators-defer-v2-3-1a25dc968e60@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: core: fix locking in regulator_resolve_supply() error path

2026-02-26T23:00:59+00:00

[ Upstream commit 497330b203d2c59c5ff3fa4c34d14494d7203bc3 ] If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference. Fixes: 36a1f1b6ddc6 ("regulator: core: Fix memory leak in regulator_resolve_supply()") Fixes: 8e5356a73604 ("regulator: core: Clear the supply pointer if enabling fails") Signed-off-by: André Draszik Link: https://patch.msgid.link/20260109-regulators-defer-v2-2-1a25dc968e60@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: check the return value of gpiod_set_value_cansleep()

2025-12-03T12:38:21+00:00

gpiod_set_value_cansleep() now returns an integer and can indicate failures in the GPIO layer. Propagate any potential errors to regulator core. Signed-off-by: Bartosz Golaszewski Link: https://patch.msgid.link/20251203084737.15891-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Mark Brown

regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex

2025-11-27T18:58:26+00:00

regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex. Fixes: a06ccd9c3785f ("regulator: core: Add ability to create a lookup alias for supply") Signed-off-by: sparkhuang Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20251127025716.5440-1-huangshaobo3@xiaomi.com Signed-off-by: Mark Brown

gpio: improve support for shared GPIOs

2025-11-20T09:23:08+00:00

Merge series from Bartosz Golaszewski : Problem statement: GPIOs are implemented as a strictly exclusive resource in the kernel but there are lots of platforms on which single pin is shared by multiple devices which don't communicate so need some way of properly sharing access to a GPIO. What we have now is the GPIOD_FLAGS_BIT_NONEXCLUSIVE flag which was introduced as a hack and doesn't do any locking or arbitration of access - it literally just hand the same GPIO descriptor to all interested users. The proposed solution is composed of three major parts: the high-level, shared GPIO proxy driver that arbitrates access to the shared pin and exposes a regular GPIO chip interface to consumers, a low-level shared GPIOLIB module that scans firmware nodes and creates auxiliary devices that attach to the proxy driver and finally a set of core GPIOLIB changes that plug the former into the GPIO lookup path. The changes are implemented in a way that allows to seamlessly compile out any code related to sharing GPIOs for systems that don't need it. The practical use-case for this are the powerdown GPIOs shared by speakers on Qualcomm db845c platform, however I have also extensively tested it using gpio-virtuser on arm64 qemu with various DT configurations.

regulator: make the subsystem aware of shared GPIOs

2025-11-19T11:52:04+00:00

GPIOLIB is now aware of shared GPIOs and - for platforms where access to such pins is managed internally - we don't need to keep track of the enable count. Once all users in the kernel switch to using the new mechanism, we'll be able to drop the internal counting of users from the regulator code. Acked-by: Mark Brown Acked-by: Linus Walleij Signed-off-by: Bartosz Golaszewski Link: https://patch.msgid.link/20251112-gpio-shared-v4-10-b51f97b1abd8@linaro.org Signed-off-by: Mark Brown

regulator: core: disable supply if enabling main regulator fails

2025-11-07T17:37:47+00:00

For 'always-on' and 'boot-on' regulators, the set_machine_constraints() may enable supply before enabling the main regulator, however if the latter fails, the function returns with an error but the supply remains enabled. When this happens, the regulator_register() function continues on the error path where it puts the supply regulator. Since enabling the supply is not balanced with a disable call, a warning similar to the following gets issued from _regulator_put(): [ 1.603889] WARNING: CPU: 2 PID: 44 at _regulator_put+0x8c/0xa0 [ 1.603908] Modules linked in: [ 1.603926] CPU: 2 UID: 0 PID: 44 Comm: kworker/u16:3 Not tainted 6.18.0-rc4 #0 NONE [ 1.603938] Hardware name: Qualcomm Technologies, Inc. IPQ9574/AP-AL02-C7 (DT) [ 1.603945] Workqueue: async async_run_entry_fn [ 1.603958] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.603967] pc : _regulator_put+0x8c/0xa0 [ 1.603976] lr : _regulator_put+0x7c/0xa0 ... [ 1.604140] Call trace: [ 1.604145] _regulator_put+0x8c/0xa0 (P) [ 1.604156] regulator_register+0x2ec/0xbf0 [ 1.604166] devm_regulator_register+0x60/0xb0 [ 1.604178] rpm_reg_probe+0x120/0x208 [ 1.604187] platform_probe+0x64/0xa8 ... In order to avoid this, change the set_machine_constraints() function to disable the supply if enabling the main regulator fails. Fixes: 05f224ca6693 ("regulator: core: Clean enabling always-on regulators + their supplies") Signed-off-by: Gabor Juhos Link: https://patch.msgid.link/20251107-regulator-disable-supply-v1-1-c95f0536f1b5@gmail.com Signed-off-by: Mark Brown

regulator: core: forward undervoltage events downstream by default

2025-10-15T09:48:58+00:00

Forward critical supply events downstream so consumers can react in time. An under-voltage event on an upstream rail may otherwise never reach end devices (e.g. eMMC). Register a notifier on a regulator's supply when the supply is resolved, and forward only REGULATOR_EVENT_UNDER_VOLTAGE to the consumer's notifier chain. Event handling is deferred to process context via a workqueue; the consumer rdev is lifetime-pinned and the rdev lock is held while calling the notifier chain. The notifier is unregistered on regulator teardown. No DT/UAPI changes. Behavior applies to all regulators with a supply. Signed-off-by: Oleksij Rempel Link: https://patch.msgid.link/20251001105650.2391477-1-o.rempel@pengutronix.de Signed-off-by: Mark Brown