linux.git/include/linux/regulator, branch master Linux kernel source tree Samsung S2MPG10 regulator and S2MPG11 PMIC drivers 2026-02-05T00:07:58+00:00 Mark Brown broonie@kernel.org 2026-02-05T00:07:58+00:00 914809c666d6c96d130da4755daa5bb0a57f0e12 Merge series from André Draszik <andre.draszik@linaro.org>: This series extends the existing S2MPG10 PMIC driver to add support for the regulators, and adds new S2MPG11 core and regulator drivers. The patches are kept together in one series, due to S2MPG11 and its regulators being very similar to S2MPG10. The Samsung S2MPG11 PMIC is a Power Management IC for mobile applications with buck converters, various LDOs, power meters, and additional GPIO interfaces. It typically complements an S2MPG10 PMIC in a main/sub configuration as the sub-PMIC and both are used on the Google Pixel 6 and 6 Pro (oriole / raven). A DT update for Oriole / Raven to enable these is required which I will send out separately. 
Merge series from André Draszik <andre.draszik@linaro.org>:

This series extends the existing S2MPG10 PMIC driver to add support for
the regulators, and adds new S2MPG11 core and regulator drivers.

The patches are kept together in one series, due to S2MPG11 and its
regulators being very similar to S2MPG10.

The Samsung S2MPG11 PMIC is a Power Management IC for mobile
applications with buck converters, various LDOs, power meters, and
additional GPIO interfaces. It typically complements an S2MPG10 PMIC in
a main/sub configuration as the sub-PMIC and both are used on the
Google Pixel 6 and 6 Pro (oriole / raven).

A DT update for Oriole / Raven to enable these is required which I will
send out separately.
regulator: add REGULATOR_LINEAR_VRANGE macro 2026-02-04T13:35:32+00:00 André Draszik andre.draszik@linaro.org 2026-01-22T15:43:37+00:00 7d33c0a4c6a3356db2b2f599820baf75d3753d44 REGULATOR_LINEAR_VRANGE is similar to REGULATOR_LINEAR_RANGE, but allows a more natural declaration of a voltage range for a regulator, in that it expects the minimum and maximum values as voltages rather than as selectors. Using voltages arguably makes this macro easier to use by drivers and code using it can become easier to read compared to REGULATOR_LINEAR_RANGE. Signed-off-by: André Draszik <andre.draszik@linaro.org> Link: https://patch.msgid.link/20260122-s2mpg1x-regulators-v7-10-3b1f9831fffd@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> 
REGULATOR_LINEAR_VRANGE is similar to REGULATOR_LINEAR_RANGE, but
allows a more natural declaration of a voltage range for a regulator,
in that it expects the minimum and maximum values as voltages rather
than as selectors.

Using voltages arguably makes this macro easier to use by drivers and
code using it can become easier to read compared to
REGULATOR_LINEAR_RANGE.

Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260122-s2mpg1x-regulators-v7-10-3b1f9831fffd@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: core: don't fail regulator_register() with missing required supply 2026-01-09T13:38:01+00:00 André Draszik andre.draszik@linaro.org 2026-01-09T08:38:44+00:00 8d38423d9dea7353a8a54a3ab2e0d0aa04ed34d0 Since commit 98e48cd9283d ("regulator: core: resolve supply for boot-on/always-on regulators"), the regulator core returns -EPROBE_DEFER if a supply can not be resolved at regulator_register() time due to set_machine_constraints() requiring that supply (e.g. because of always-on or boot-on). In some hardware designs, multiple PMICs are used where individual rails of each act as supplies for rails of the other, and vice-versa. In such a design no PMIC driver can probe when registering one top- level regulator device (as is common practice for almost all regulator drivers in Linux) since that commit. Supplies are only considered when their driver has fully bound, but because in a design like the above two drivers / devices depend on each other, neither will have fully bound while the other probes. The Google Pixel 6 and 6 Pro (oriole and raven) are examples of such a design. One way to make this work would be to register each rail as an individual device, rather than just one top-level regulator device. Then, fw-devlink and Linux' driver core could do their usual handling of deferred device probe as each rail would be probed individually. This approach was dismissed in [1] as each regulator driver would have to take care of this itself. Alternatively, we can change the regulator core to not fail regulator_register() if a rail's required supply can not be resolved while keeping the intended change from above mentioned commit, and instead retry whenever a new rail is registered. This commit implements such an approach: If set_machine_constraints() requests probe deferral, regulator_register() still succeeds and we retry setting constraints as part of regulator_resolve_supply(). We still do not enable the regulator or allow consumers to use it until constraints have been set (including resolution of the supply) to prevent enabling of a regulator before its supply. With this change, we keep track of regulators with missing required supplies and can therefore try to resolve them again and try to set the constraints again once more regulators become available. Care has to be taken to not allow consumers to use regulators that haven't had their constraints set yet. regulator_get() ensures that and now returns -EPROBE_DEFER in that case. The implementation is straight-forward, thanks to our newly introduced regulator-bus. Locking in regulator_resolve_supply() has to be done carefully, as a combination of regulator_(un)lock_two() and regulator_(un)lock_dependent() is needed. The reason is that set_machine_constraints() might call regulator_enable() which needs rdev and all its dependents locked, but everything else requires to only have rdev and its supply locked. Link: https://lore.kernel.org/all/aRn_-o-vie_QoDXD@sirena.co.uk/ [1] Signed-off-by: André Draszik <andre.draszik@linaro.org> Link: https://patch.msgid.link/20260109-regulators-defer-v2-8-1a25dc968e60@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> 
Since commit 98e48cd9283d ("regulator: core: resolve supply for
boot-on/always-on regulators"), the regulator core returns
-EPROBE_DEFER if a supply can not be resolved at regulator_register()
time due to set_machine_constraints() requiring that supply (e.g.
because of always-on or boot-on).

In some hardware designs, multiple PMICs are used where individual
rails of each act as supplies for rails of the other, and vice-versa.
In such a design no PMIC driver can probe when registering one top-
level regulator device (as is common practice for almost all regulator
drivers in Linux) since that commit. Supplies are only considered when
their driver has fully bound, but because in a design like the above
two drivers / devices depend on each other, neither will have fully
bound while the other probes. The Google Pixel 6 and 6 Pro (oriole and
raven) are examples of such a design.

One way to make this work would be to register each rail as an
individual device, rather than just one top-level regulator device.
Then, fw-devlink and Linux' driver core could do their usual handling
of deferred device probe as each rail would be probed individually.
This approach was dismissed in [1] as each regulator driver would have
to take care of this itself.

Alternatively, we can change the regulator core to not fail
regulator_register() if a rail's required supply can not be resolved
while keeping the intended change from above mentioned commit, and
instead retry whenever a new rail is registered. This commit implements
such an approach:

    If set_machine_constraints() requests probe deferral,
    regulator_register() still succeeds and we retry setting
    constraints as part of regulator_resolve_supply().
    We still do not enable the regulator or allow consumers to use it
    until constraints have been set (including resolution of the
    supply) to prevent enabling of a regulator before its supply.

With this change, we keep track of regulators with missing required
supplies and can therefore try to resolve them again and try to set
the constraints again once more regulators become available.

Care has to be taken to not allow consumers to use regulators that
haven't had their constraints set yet. regulator_get() ensures that
and now returns -EPROBE_DEFER in that case.

The implementation is straight-forward, thanks to our newly introduced
regulator-bus. Locking in regulator_resolve_supply() has to be done
carefully, as a combination of regulator_(un)lock_two() and
regulator_(un)lock_dependent() is needed. The reason is that
set_machine_constraints() might call regulator_enable() which needs
rdev and all its dependents locked, but everything else requires to
only have rdev and its supply locked.

Link: https://lore.kernel.org/all/aRn_-o-vie_QoDXD@sirena.co.uk/ [1]
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-8-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: core: reresolve unresolved supplies when available 2026-01-09T13:38:00+00:00 André Draszik andre.draszik@linaro.org 2026-01-09T08:38:43+00:00 304f5784e97281f18ef4bed574cbe5fcf6ce2f2e 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> 
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>
regulator: pca9450: Add support for setting debounce settings 2025-11-18T18:55:22+00:00 Martijn de Gouw martijn.de.gouw@prodrive-technologies.com 2025-11-17T20:22:14+00:00 d9d0be59be2580f2c5e4b7217aafb980e8c371cf Make the different debounce timers configurable from the devicetree. Depending on the board design, these have to be set different than the default register values. Signed-off-by: Martijn de Gouw <martijn.de.gouw@prodrive-technologies.com> Link: https://patch.msgid.link/20251117202215.1936139-2-martijn.de.gouw@prodrive-technologies.com Signed-off-by: Mark Brown <broonie@kernel.org> 
Make the different debounce timers configurable from the devicetree.
Depending on the board design, these have to be set different than the
default register values.

Signed-off-by: Martijn de Gouw <martijn.de.gouw@prodrive-technologies.com>
Link: https://patch.msgid.link/20251117202215.1936139-2-martijn.de.gouw@prodrive-technologies.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support MT6316/6363/MT6373 PMICs regulators 2025-11-06T11:34:53+00:00 Mark Brown broonie@kernel.org 2025-11-06T11:34:53+00:00 1044821176a64a8dc7f861e878506cde34c8b658 Merge series from AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>: This series adds support for three new MediaTek PMICs: MT6316, MT6363 and MT6373 and their variants - used in board designs featuring the MediaTek MT8196 Chromebook SoC, or the MT6991 Dimensity 9400 Smartphone SoC. In particular, MT6316 is a regulator, but the MT6363 and MT6373 PMICs are multi-function devices, as they have and expose multiple sub-devices; moreover, some of those also contain an interrupt controller, managing internal IPs interrupts: for those, a chained interrupt handler is registered, which parent is the SPMI controller itself. This series adds support for all of the MT6316 regulator variants and for MT6363, MT6373 SPMI PMICs and their interrupt controller. 
Merge series from AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>:

This series adds support for three new MediaTek PMICs: MT6316, MT6363
and MT6373 and their variants - used in board designs featuring the
MediaTek MT8196 Chromebook SoC, or the MT6991 Dimensity 9400 Smartphone
SoC.

In particular, MT6316 is a regulator, but the MT6363 and MT6373 PMICs
are multi-function devices, as they have and expose multiple sub-devices;
moreover, some of those also contain an interrupt controller, managing
internal IPs interrupts: for those, a chained interrupt handler is
registered, which parent is the SPMI controller itself.

This series adds support for all of the MT6316 regulator variants and
for MT6363, MT6373 SPMI PMICs and their interrupt controller.
regulator: Add support for MediaTek MT6363 SPMI PMIC Regulators 2025-11-05T13:28:46+00:00 AngeloGioacchino Del Regno angelogioacchino.delregno@collabora.com 2025-10-27T11:05:22+00:00 3c36965df80801344850388592e95033eceea05b Add a driver for the regulators found on the MT6363 PMIC, fully controlled by SPMI interface. This PMIC regulates voltage with an input range of 2.6-5.0V, and features 10 buck converters and 26 LDOs. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20251027110527.21002-5-angelogioacchino.delregno@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org> 
Add a driver for the regulators found on the MT6363 PMIC, fully
controlled by SPMI interface.
This PMIC regulates voltage with an input range of 2.6-5.0V, and
features 10 buck converters and 26 LDOs.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251027110527.21002-5-angelogioacchino.delregno@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: core: forward undervoltage events downstream by default 2025-10-15T09:48:58+00:00 Oleksij Rempel o.rempel@pengutronix.de 2025-10-01T10:56:49+00:00 433e294c3c5b5d2020085a0e36c1cb47b694690a 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 <o.rempel@pengutronix.de> Link: https://patch.msgid.link/20251001105650.2391477-1-o.rempel@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org> 
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 <o.rempel@pengutronix.de>
Link: https://patch.msgid.link/20251001105650.2391477-1-o.rempel@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: add s2dos05 regulator support 2025-08-11T13:08:53+00:00 Dzmitry Sankouski dsankouski@gmail.com 2025-08-05T19:40:56+00:00 bb2441402392ef1f49563be68e8f0dcb127ac965 S2DOS05 has 1 buck and 4 LDO regulators, used for powering panel/touchscreen. Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com> Link: https://patch.msgid.link/20250805-starqltechn_integration_upstream-v8-1-09d8a321fafe@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> 
S2DOS05 has 1 buck and 4 LDO regulators, used for powering
panel/touchscreen.

Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com>
Link: https://patch.msgid.link/20250805-starqltechn_integration_upstream-v8-1-09d8a321fafe@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: core: Don't use "proxy" headers 2025-06-26T23:29:07+00:00 Andy Shevchenko andriy.shevchenko@linux.intel.com 2025-06-26T15:23:07+00:00 ce57bc9771411d6d27f2ca7b40396cbd7d684ba9 Update header inclusions to follow IWYU (Include What You Use) principle. Note that kernel.h is discouraged to be included as it's written at the top of that file. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20250626152307.322627-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> 
Update header inclusions to follow IWYU (Include What You Use)
principle.

Note that kernel.h is discouraged to be included as it's written
at the top of that file.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20250626152307.322627-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>