diff options
| author | André Draszik <andre.draszik@linaro.org> | 2026-01-09 08:38:43 +0000 |
|---|---|---|
| committer | Mark Brown <broonie@kernel.org> | 2026-01-09 13:38:00 +0000 |
| commit | 304f5784e97281f18ef4bed574cbe5fcf6ce2f2e (patch) | |
| tree | f0558f5d191561f42c78bc3fd859dc178b1190de /include | |
| parent | e23c0a59dabae9166bbea26fc05d08e7d9e900b7 (diff) | |
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>
Diffstat (limited to 'include')
| -rw-r--r-- | include/linux/regulator/driver.h | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h index 978cf593b662..d38353f2b56f 100644 --- a/include/linux/regulator/driver.h +++ b/include/linux/regulator/driver.h @@ -635,6 +635,7 @@ struct regulator_dev { int ref_cnt; struct module *owner; struct device dev; + struct device bdev; struct regulation_constraints *constraints; struct regulator *supply; /* for tree */ const char *supply_name; |
