<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/regulator/core.c, branch v6.18.21</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.21</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.21'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-03-04T12:20:39+00:00</updated>
<entry>
<title>regulator: core: Remove regulator supply_name length limit</title>
<updated>2026-03-04T12:20:39+00:00</updated>
<author>
<name>Bjorn Andersson</name>
<email>bjorn.andersson@oss.qualcomm.com</email>
</author>
<published>2026-02-12T03:37:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=96c5ea9e7a8214be8fabf4690a878e1e936f9ae8'/>
<id>urn:sha1:96c5ea9e7a8214be8fabf4690a878e1e936f9ae8</id>
<content type='text'>
[ 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-&gt;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 &lt;bjorn.andersson@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20260211-regulator-supply-name-length-v1-1-3875541c1576@oss.qualcomm.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>regulator: core: move supply check earlier in set_machine_constraints()</title>
<updated>2026-02-26T22:59:12+00:00</updated>
<author>
<name>André Draszik</name>
<email>andre.draszik@linaro.org</email>
</author>
<published>2026-01-09T08:38:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b6a83ad13d253f9319920313a0fbad637fab9aef'/>
<id>urn:sha1:b6a83ad13d253f9319920313a0fbad637fab9aef</id>
<content type='text'>
[ 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 &lt;andre.draszik@linaro.org&gt;
Link: https://patch.msgid.link/20260109-regulators-defer-v2-3-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex</title>
<updated>2025-12-18T13:03:25+00:00</updated>
<author>
<name>sparkhuang</name>
<email>huangshaobo3@xiaomi.com</email>
</author>
<published>2025-11-27T02:57:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=64099b5c0aeb70bc7cd5556eb7f59c5b4a5010bf'/>
<id>urn:sha1:64099b5c0aeb70bc7cd5556eb7f59c5b4a5010bf</id>
<content type='text'>
[ Upstream commit 0cc15a10c3b4ab14cd71b779fd5c9ca0cb2bc30d ]

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 &lt;huangshaobo3@xiaomi.com&gt;
Reviewed-by: Charles Keepax &lt;ckeepax@opensource.cirrus.com&gt;
Link: https://patch.msgid.link/20251127025716.5440-1-huangshaobo3@xiaomi.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>regulator: core: disable supply if enabling main regulator fails</title>
<updated>2025-12-18T13:02:53+00:00</updated>
<author>
<name>Gabor Juhos</name>
<email>j4g8y7@gmail.com</email>
</author>
<published>2025-11-07T17:10:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=10be1301ae69df4db775b269cdf56dbb9d3d588b'/>
<id>urn:sha1:10be1301ae69df4db775b269cdf56dbb9d3d588b</id>
<content type='text'>
[ Upstream commit fb1ebb10468da414d57153ddebaab29c38ef1a78 ]

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 &lt;j4g8y7@gmail.com&gt;
Link: https://patch.msgid.link/20251107-regulator-disable-supply-v1-1-c95f0536f1b5@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>regulator: core: Remove redundant ternary operators</title>
<updated>2025-08-28T14:02:51+00:00</updated>
<author>
<name>Liao Yuanhong</name>
<email>liaoyuanhong@vivo.com</email>
</author>
<published>2025-08-28T12:27:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=899fb38dd76dd3ede425bbaf8a96d390180a5d1c'/>
<id>urn:sha1:899fb38dd76dd3ede425bbaf8a96d390180a5d1c</id>
<content type='text'>
For ternary operators in the form of "a ? true : false", if 'a' itself
returns a boolean result, the ternary operator can be omitted. Remove
redundant ternary operators to clean up the code.

Signed-off-by: Liao Yuanhong &lt;liaoyuanhong@vivo.com&gt;
Message-ID: &lt;20250828122737.43488-1-liaoyuanhong@vivo.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regulator: core: correct convergence check in regulator_set_voltage()</title>
<updated>2025-07-29T13:56:39+00:00</updated>
<author>
<name>Romain Gantois</name>
<email>romain.gantois@bootlin.com</email>
</author>
<published>2025-07-29T09:50:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=10dfd36f078423c51602a9a21ed85e8e6c947a00'/>
<id>urn:sha1:10dfd36f078423c51602a9a21ed85e8e6c947a00</id>
<content type='text'>
The logic in regulator_set_voltage() which checks for a non-convergence
condition on a stepped regulator is flawed.

regulator_set_voltage() checks if the error in target voltage has increased
or decreased, and returns -EWOULDBLOCK if the error has not decreased
enough. The correct non-convergence condition is:

new_delta - delta &gt; -rdev-&gt;constraints-&gt;max_uV_step

or equivalently:

delta - new_delta &lt; rdev-&gt;constraints-&gt;max_uV_step

But the currently used condition is:

new_delta - delta &gt; rdev-&gt;constraints-&gt;max_uV_step

Which may cause an infinite loop if the voltage error doesn't converge.

Fix this by correcting the convergence condition.

Suggested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Fixes: d511206dc7443 ("regulator: core: repeat voltage setting request for stepped regulators")
Signed-off-by: Romain Gantois &lt;romain.gantois@bootlin.com&gt;
Link: https://patch.msgid.link/20250729-b4-regulator-stepping-fix-v1-1-3f7b8c55d7d7@bootlin.com
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Reviewed-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regulator: core: repeat voltage setting request for stepped regulators</title>
<updated>2025-07-18T15:17:09+00:00</updated>
<author>
<name>Romain Gantois</name>
<email>romain.gantois@bootlin.com</email>
</author>
<published>2025-07-18T14:11:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d511206dc7443120637efd9cfa3ab06a26da33dd'/>
<id>urn:sha1:d511206dc7443120637efd9cfa3ab06a26da33dd</id>
<content type='text'>
The regulator_set_voltage() function may exhibit unexpected behavior if the
target regulator has a maximum voltage step constraint. With such a
constraint, the regulator core may clamp the requested voltage to a lesser
value, to ensure that the voltage delta stays under the specified limit.

This means that the resulting regulator voltage depends on the current
voltage, as well as the requested range, which invalidates the assumption
that a repeated request for a specific voltage range will amount to a noop.

Considering the case of a regulator with a maximum voltage step constraint
of 1V:

initial voltage: 2.5V

consumer requests 4V
expected result: 3.5V
resulting voltage: 3.5V

consumer requests 4V again
expected result: 4V
actual result: 3.5V

Correct this by repeating attempts to balance the regulator voltage until
the result converges.

Signed-off-by: Romain Gantois &lt;romain.gantois@bootlin.com&gt;
Link: https://patch.msgid.link/20250718-regulator-stepping-v2-1-e28c9ac5d54a@bootlin.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regulator: core: fix NULL dereference on unbind due to stale coupling data</title>
<updated>2025-06-29T21:10:41+00:00</updated>
<author>
<name>Alessandro Carminati</name>
<email>acarmina@redhat.com</email>
</author>
<published>2025-06-26T08:38:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ca46946a482238b0cdea459fb82fc837fb36260e'/>
<id>urn:sha1:ca46946a482238b0cdea459fb82fc837fb36260e</id>
<content type='text'>
Failing to reset coupling_desc.n_coupled after freeing coupled_rdevs can
lead to NULL pointer dereference when regulators are accessed post-unbind.

This can happen during runtime PM or other regulator operations that rely
on coupling metadata.

For example, on ridesx4, unbinding the 'reg-dummy' platform device triggers
a panic in regulator_lock_recursive() due to stale coupling state.

Ensure n_coupled is set to 0 to prevent access to invalid pointers.

Signed-off-by: Alessandro Carminati &lt;acarmina@redhat.com&gt;
Link: https://patch.msgid.link/20250626083809.314842-1-acarmina@redhat.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regulator: don't compare raw GPIO descriptor pointers</title>
<updated>2025-04-09T12:46:58+00:00</updated>
<author>
<name>Bartosz Golaszewski</name>
<email>bartosz.golaszewski@linaro.org</email>
</author>
<published>2025-04-07T07:08:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=aaf6223ea2a1ff9316a81bf851fd5a0e82635b60'/>
<id>urn:sha1:aaf6223ea2a1ff9316a81bf851fd5a0e82635b60</id>
<content type='text'>
There's no API contract saying that two GPIO descriptor pointers
obtained with a call to gpiod_get() (or one of the variants), that refer
to the same physical GPIO pin, always point to the same structure. Use
the dedicated comparator function.

Signed-off-by: Bartosz Golaszewski &lt;bartosz.golaszewski@linaro.org&gt;
Link: https://patch.msgid.link/20250407-gpiod-is-equal-v1-2-7d85f568ae6e@linaro.org
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'mm-nonmm-stable-2025-03-30-18-23' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm</title>
<updated>2025-04-01T17:06:52+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2025-04-01T17:06:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d6b02199cde4b9cb99b311eeab1cdbe23165082c'/>
<id>urn:sha1:d6b02199cde4b9cb99b311eeab1cdbe23165082c</id>
<content type='text'>
Pull non-MM updates from Andrew Morton:

 - The series "powerpc/crash: use generic crashkernel reservation" from
   Sourabh Jain changes powerpc's kexec code to use more of the generic
   layers.

 - The series "get_maintainer: report subsystem status separately" from
   Vlastimil Babka makes some long-requested improvements to the
   get_maintainer output.

 - The series "ucount: Simplify refcounting with rcuref_t" from
   Sebastian Siewior cleans up and optimizing the refcounting in the
   ucount code.

 - The series "reboot: support runtime configuration of emergency
   hw_protection action" from Ahmad Fatoum improves the ability for a
   driver to perform an emergency system shutdown or reboot.

 - The series "Converge on using secs_to_jiffies() part two" from Easwar
   Hariharan performs further migrations from msecs_to_jiffies() to
   secs_to_jiffies().

 - The series "lib/interval_tree: add some test cases and cleanup" from
   Wei Yang permits more userspace testing of kernel library code, adds
   some more tests and performs some cleanups.

 - The series "hung_task: Dump the blocking task stacktrace" from Masami
   Hiramatsu arranges for the hung_task detector to dump the stack of
   the blocking task and not just that of the blocked task.

 - The series "resource: Split and use DEFINE_RES*() macros" from Andy
   Shevchenko provides some cleanups to the resource definition macros.

 - Plus the usual shower of singleton patches - please see the
   individual changelogs for details.

* tag 'mm-nonmm-stable-2025-03-30-18-23' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (77 commits)
  mailmap: consolidate email addresses of Alexander Sverdlin
  fs/procfs: fix the comment above proc_pid_wchan()
  relay: use kasprintf() instead of fixed buffer formatting
  resource: replace open coded variant of DEFINE_RES()
  resource: replace open coded variants of DEFINE_RES_*_NAMED()
  resource: replace open coded variant of DEFINE_RES_NAMED_DESC()
  resource: split DEFINE_RES_NAMED_DESC() out of DEFINE_RES_NAMED()
  samples: add hung_task detector mutex blocking sample
  hung_task: show the blocker task if the task is hung on mutex
  kexec_core: accept unaccepted kexec segments' destination addresses
  watchdog/perf: optimize bytes copied and remove manual NUL-termination
  lib/interval_tree: fix the comment of interval_tree_span_iter_next_gap()
  lib/interval_tree: skip the check before go to the right subtree
  lib/interval_tree: add test case for span iteration
  lib/interval_tree: add test case for interval_tree_iter_xxx() helpers
  lib/rbtree: add random seed
  lib/rbtree: split tests
  lib/rbtree: enable userland test suite for rbtree related data structure
  checkpatch: describe --min-conf-desc-length
  scripts/gdb/symbols: determine KASLR offset on s390
  ...
</content>
</entry>
</feed>
