kernel/linux.git/drivers/regulator/fixed.c, branch v6.12.80

regulator: fixed: Rely on the core freeing the enable GPIO

2025-12-18T12:55:19+00:00

[ Upstream commit 79a45ddcdbba330f5139c7c7ff7042d69cf147b2 ] In order to simplify ownership rules for enable GPIOs supplied by drivers regulator_register() always takes ownership of them, even if it ends up failing for some other reason. We therefore should not free the GPIO if registration fails but just let the core worry about things. Fixes: 636f4618b1cd (regulator: fixed: fix GPIO descriptor leak on register failure) Reported-by: Diederik de Haas Closes: https://lore.kernel.org/r/DEPEYUF5BRGY.UKFBWRRE8HNP@cknow-tech.com Tested-by: Diederik de Haas Signed-off-by: Mark Brown Link: https://patch.msgid.link/20251204-regulator-fixed-fix-gpiod-leak-v1-1-48efea5b82c2@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: fixed: fix GPIO descriptor leak on register failure

2025-11-24T09:35:53+00:00

[ Upstream commit 636f4618b1cd96f6b5a2b8c7c4f665c8533ecf13 ] In the commit referenced by the Fixes tag, devm_gpiod_get_optional() was replaced by manual GPIO management, relying on the regulator core to release the GPIO descriptor. However, this approach does not account for the error path: when regulator registration fails, the core never takes over the GPIO, resulting in a resource leak. Add gpiod_put() before returning on regulator registration failure. Fixes: 5e6f3ae5c13b ("regulator: fixed: Let core handle GPIO descriptor") Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20251028172828.625-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: Unify "negative error number" terminology in comments

2024-08-29T13:20:30+00:00

Previous commits cleaning up kerneldoc used the term "negative error number" to refer to error condition return values. Update remaining instances of other terminology such as "error code" or "errno" as well so the whole regulator subsystem is unified. Signed-off-by: Chen-Yu Tsai Reported-by: Andy Shevchenko Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20240829085131.1361701-11-wenst@chromium.org Signed-off-by: Mark Brown

regulator: fixed: Fix incorrectly formatted kerneldoc "Return" section

2024-08-29T13:20:27+00:00

kernel-doc complains about missing "Return" section for kerneldoc of of_get_fixed_voltage_config(). The kerneldoc has a description about the return values, just not in the format kernel-doc wants. Convert it to use the proper "Return:" section header. The existing description have been reworded and moved around to fit the grammar and formatting. Signed-off-by: Chen-Yu Tsai Reported-by: Andy Shevchenko Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20240829085131.1361701-7-wenst@chromium.org Signed-off-by: Mark Brown

regulator: fixed: add support for under-voltage IRQ

2023-10-25T12:44:30+00:00

Add interrupt support for under-voltage notification. This functionality can be used on systems capable to detect under-voltage state and having enough capacity to let the SoC do some emergency preparation. This change enforce default policy to shutdown system as soon as interrupt is triggered. Signed-off-by: Oleksij Rempel Link: https://lore.kernel.org/r/20231025084614.3092295-6-o.rempel@pengutronix.de Signed-off-by: Mark Brown

regulator: Explicitly include correct DT includes

2023-07-14T19:52:54+00:00

The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20230714174930.4063320-1-robh@kernel.org Signed-off-by: Mark Brown

Add support for Rockchip RK860X regulators

2023-04-11T15:11:32+00:00

Merge series from Cristian Ciocaltea : This patch series introduces support for the Rockchip RK860X regulators, while also providing a few fixes and improvements to the existing fan53555 driver. RK8600/RK8601 are quite similar to the FAN53555 regulators. RK8602/RK8603 are a bit different, having a wider output voltage selection range, from 0.5 V to 1.5 V in 6.25 mV steps. They are used in the Rock 5B board to power the ARM Cortex-A76 cores and the NPU.

regulator: Handle deferred clk

2023-03-27T00:42:01+00:00

devm_clk_get() can return -EPROBE_DEFER. So it is better to return the error code from devm_clk_get(), instead of a hard coded -ENOENT. This gives more opportunities to successfully probe the driver. Fixes: 8959e5324485 ("regulator: fixed: add possibility to enable by clock") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/18459fae3d017a66313699c7c8456b28158b2dd0.1679819354.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown

regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14

2023-03-20T13:11:25+00:00

Probing of regulators can be a slow operation and can contribute to slower boot times. This is especially true if a regulator is turned on at probe time (with regulator-boot-on or regulator-always-on) and the regulator requires delays (off-on-time, ramp time, etc). While the overall kernel is not ready to switch to async probe by default, as per the discussion on the mailing lists [1] it is believed that the regulator subsystem is in good shape and we can move regulator drivers over wholesale. There is no way to just magically opt in all regulators (regulators are just normal drivers like platform_driver), so we set PROBE_PREFER_ASYNCHRONOUS for all regulators found in 'drivers/regulator' individually. Given the number of drivers touched and the impossibility to test this ahead of time, it wouldn't be shocking at all if this caused a regression for someone. If there is a regression caused by this patch, it's likely to be one of the cases talked about in [1]. As a "quick fix", drivers involved in the regression could be fixed by changing them to PROBE_FORCE_SYNCHRONOUS. That being said, the correct fix would be to directly fix the problem that caused the issue with async probe. The approach here follows a similar approach that was used for the mmc subsystem several years ago [2]. In fact, I ran nearly the same python script to auto-generate the changes. The only thing I changed was to search for "i2c_driver", "spmi_driver", and "spi_driver" in addition to "platform_driver". [1] https://lore.kernel.org/r/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk [2] https://lore.kernel.org/r/20200903232441.2694866-1-dianders@chromium.org/ Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20230316125351.1.I2a4677392a38db5758dee0788b2cea5872562a82@changeid Signed-off-by: Mark Brown

regulator: Use of_property_present() for testing DT property presence

2023-03-11T12:13:38+00:00

It is preferred to use typed property access functions (i.e. of_property_read_ functions) rather than low-level of_get_property/of_find_property functions for reading properties. As part of this, convert of_get_property/of_find_property calls to the recently added of_property_present() helper when we just want to test for presence of a property and nothing more. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20230310144721.1544756-1-robh@kernel.org Signed-off-by: Mark Brown