linux-rng/include/linux/regulator, branch master

regulator: lp872x: Fold driver header into driver file

2026-10-13T19:17:40Z

Remove need in header file in preparation for pdata probing removal. Signed-off-by: Svyatoslav Ryhel Link: https://patch.msgid.link/20261013181417.492252-4-clamor95@gmail.com Signed-off-by: Mark Brown

regulator: fix typos and repeated words in comments

2026-09-04T22:30:49Z

Hemanth Selam says: This corrects 2 misspellings and repeated words in comments. Each is a separate patch so that any one of them can be dropped without touching the rest. Nothing outside comments changes. Every touched C file was checked by dropping its comments, replacing each string literal with a placeholder and collapsing whitespace; what remained was identical before and after, so the compiled code cannot differ. The mistakes were found with scripts/checkpatch.pl against the list in scripts/spelling.txt. The scanning, the edits and the changelogs were produced with Cursor running the claude-opus-5 model, from a request to find and fix spelling mistakes across the tree, and every correction was then re-checked by the comparison described above. Words that name an identifier were left alone deliberately, even when they read as typos, because correcting the prose would make the comment disagree with the code it describes. Tested by building x86_64 defconfig at v7.3-rc1-269-gbc35965f6940, which is clean. Nothing else was built, so any patch touching code that x86_64 defconfig does not compile has been read but not compiled. Link: https://patch.msgid.link/20260904110203.10113-1-hemanth.selam@gmail.com

regulator: fix typos in comments

2026-09-04T22:30:47Z

Fix typos in comments, reported by scripts/checkpatch.pl using the misspelling list in scripts/spelling.txt. Only touches comments, no code changes. Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam Link: https://patch.msgid.link/20260904110203.10113-2-hemanth.selam@gmail.com Signed-off-by: Mark Brown

regulator: pca9450: Support regulator-off-in-suspend

2026-08-30T22:36:40Z

The PCA9450 uses each regulator's ENMODE field to control whether the regulator remains enabled when the PMIC transitions from RUN to STANDBY mode. The driver does not currently implement set_suspend_disable(), so a regulator configured with regulator-off-in-suspend remains enabled during system suspend. Implement set_suspend_disable() for the buck regulators and LDO3-LDO5. The suspend and runtime controls share ENMODE, so first read the field and leave it unchanged when it is 00b. This preserves the state of a regulator that was already disabled at runtime. For an enabled regulator, program 10b to keep it on in RUN and turn it off while PMIC_STBY_REQ is asserted. Most buck descriptors set enable_val to 01b, while BUCK2 uses 10b. When enable_val is nonzero, regulator_is_enabled_regmap() checks for an exact match. It would therefore report most bucks as disabled after their ENMODE is changed from 01b to 10b, even though all valid nonzero ENMODE values enable the regulator in RUN. Use a custom is_enabled() helper for the buck operation tables that considers a nonzero ENMODE enabled. The LDO descriptors leave enable_val at zero, for which the generic helper already performs this nonzero check, so keep using it for the LDOs. Runtime enable and disable operations remain unchanged: disable writes 00b and enable writes the regulator's default mode. The suspend callback reapplies 10b on each suspend after any intervening runtime operation. Keep LDO1 and LDO2 on regulator operations without set_suspend_disable(), because these regulators supply the SNVS domain and must remain enabled in STANDBY mode. Measured on a custom i.MX8MP board, turning off NVCC_SD2 (LDO5) during system suspend reduced power consumption by approximately 64 mW. Signed-off-by: Fabio Estevam Link: https://patch.msgid.link/20260818014059.351152-2-festevam@gmail.com Signed-off-by: Mark Brown

regulator: pca9450: Use LDO5 low-control enable mask

2026-08-30T22:36:39Z

LDO5 has voltage-selection fields in both LDO5CTRL_L and LDO5CTRL_H, selected by the SD_VSEL pin. Its ENMODE field, however, is only in LDO5CTRL_L. The regulator descriptors correctly use LDO5CTRL_L as enable_reg, but use the misleading LDO5H_EN_MASK name for enable_mask. Both mask definitions have the same value, so this causes no functional problem. Use LDO5L_EN_MASK in all LDO5 descriptors and remove the unused LDO5H_EN_MASK definition. Signed-off-by: Fabio Estevam Link: https://patch.msgid.link/20260818014059.351152-1-festevam@gmail.com Signed-off-by: Mark Brown

regulator: mt6359: Add proper ldo_vcn33_[12] regulators

2026-05-20T16:17:04Z

The ldo_vcn33_[12]_wifi and ldo_vcn33_[12]_bt are just two regulator outputs instead of four. The wifi and bt parts refer to separate enable bits that are OR-ed together to affect the actual regulator output. The separate bits allow the wifi and bt stacks to enable their power without coordination between them. These have been deprecated in favor of proper nodes matching the output. Add proper ldo_vcn33_[12] regulators to replace the existing ones. The enable status is synced to just one of the two enable bits, and the other is forced off. This makes the handling in other bits simpler. The existing *_(bt|wifi) regulators are converted to no-op regulators that are fed from their new respective ldo_vcn33_[12] regulator. This allows existing device trees to continue to work. Signed-off-by: Chen-Yu Tsai Link: https://patch.msgid.link/20260514091520.2718987-7-wenst@chromium.org Signed-off-by: Mark Brown

Samsung S2MPG10 regulator and S2MPG11 PMIC drivers

2026-02-05T00:07:58Z

Merge series from André Draszik : 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:32Z

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 Link: https://patch.msgid.link/20260122-s2mpg1x-regulators-v7-10-3b1f9831fffd@linaro.org Signed-off-by: Mark Brown

regulator: core: don't fail regulator_register() with missing required supply

2026-01-09T13:38:01Z

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 Link: https://patch.msgid.link/20260109-regulators-defer-v2-8-1a25dc968e60@linaro.org Signed-off-by: Mark Brown

regulator: core: reresolve unresolved supplies when available

2026-01-09T13:38:00Z

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 Link: https://patch.msgid.link/20260109-regulators-defer-v2-7-1a25dc968e60@linaro.org Signed-off-by: Mark Brown