]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
regulator: core: reresolve unresolved supplies when available
authorAndré Draszik <andre.draszik@linaro.org>
Fri, 9 Jan 2026 08:38:43 +0000 (08:38 +0000)
committerMark Brown <broonie@kernel.org>
Fri, 9 Jan 2026 13:38:00 +0000 (13:38 +0000)
commit304f5784e97281f18ef4bed574cbe5fcf6ce2f2e
treef0558f5d191561f42c78bc3fd859dc178b1190de
parente23c0a59dabae9166bbea26fc05d08e7d9e900b7
regulator: core: reresolve unresolved supplies when available

When a regulator A and its supply B are provided by different devices,
the driver implementing B might be last to probe (with A still
pending resolution of its supply B). While we try to resolve all
pending supplies for all regulators (including A) during
regulator_register() of B via regulator_register_resolve_supply(),
supply resolution will still not work for A as the driver for B hasn't
finished binding to the PMIC device corresponding to B at that stage
yet. The regulator core explicitly only allows supplies from other
devices to be used once the relevant driver has fully bound, mainly to
avoid having to deal with cases where B itself might -EPROBE_DEFER.

In this case, A's supply will only be resolved as part of the core's
regulator_init_complete_work_function(), which currently is scheduled
to run after 30s. This was added as a work-around in
commit 3827b64dba27 ("regulator: core: Resolve supplies before
disabling unused regulators") to cover this situation.

There are two problems with that approach:
* it potentially runs long after all our consumers have probed
* an upcoming change will allow regulator_register() to complete
  successfully even when required supplies (e.g. due to always-on or
  boot-on) are missing at register time, deferring full configuration
  of the regulator (and usability by consumers, i.e. usually consumer
  probe) until the supply becomes available.
  Resolving supplies in the late work func can therefore make it
  impossible for consumers to probe at all, as the driver core will not
  know to reprobe consumers when supplies have resolved.

We could schedule an earlier work to try to resolve supplies sooner,
but that'd be racy as consumers of A might try to probe before A's
supply gets fully resolved via this extra work.

Instead, add a very simple regulator bus and add a dummy device with a
corresponding driver to it for each regulator that is missing its
supply during regulator_register(). This way, the driver core will call
our bus' probe whenever a new (regulator) device was successfully
bound, allowing us to retry resolving the supply during (our bus) probe
and to bind this dummy device if successful. In turn this means the
driver core will see a newly bound device and retry probing of all
pending consumers, if any.

With that in place, we can avoid walking the full list of all known
regulators to try resolve missing supplies during regulator_register(),
as the driver core will invoke the bus probe for regulators that are
still pending their supplies. We can also drop the code trying to
resolve supplies one last time before unused regulators get disabled,
as all supplies should have resolved at that point in time, and if they
haven't then there's no point in trying again, as the outcome won't
change.

Note: We can not reuse the existing struct device created for each
rail, as a device can not be part of a class and a bus simultaneously.

Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-7-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
drivers/regulator/core.c
include/linux/regulator/driver.h