kernel/linux.git/drivers/regulator/devres.c, branch v6.19.11

Convert regulator drivers to use

2025-02-28T16:33:32+00:00

Merge series from Raag Jadav : This series converts regulator drivers to use the newly introduced[1] devm_kmemdup_array() helper. [1] https://lore.kernel.org/r/20250212062513.2254767-1-raag.jadav@intel.com

regulator: devres: use devm_kmemdup_array()

2025-02-28T14:01:06+00:00

Convert to use devm_kmemdup_array() which is more robust. Signed-off-by: Raag Jadav Link: https://patch.msgid.link/20250228072057.151436-2-raag.jadav@intel.com Signed-off-by: Mark Brown

regulator: Add (devm_)of_regulator_get()

2025-02-24T15:26:08+00:00

The Rockchip power-domain controller also plans to make use of per-domain regulators similar to the MediaTek power-domain controller. Since existing DTs are missing the regulator information, the kernel should fallback to the automatically created dummy regulator if necessary. Thus the version without the _optional suffix is needed. The Rockchip driver plans to use the managed version, but to be consistent with existing code the unmanaged version is added at the same time. Tested-by: Heiko Stuebner Signed-off-by: Sebastian Reichel Link: https://patch.msgid.link/20250220-rk3588-gpu-pwr-domain-regulator-v6-1-a4f9c24e5b81@kernel.org Signed-off-by: Mark Brown

regulator: Add devres version of of_regulator_get_optional()

2024-09-29T23:11:41+00:00

There are existing uses for a devres version of of_regulator_get_optional() in power domain drivers. On MediaTek platforms, power domains may have regulator supplies tied to them. The driver currently tries to use devm_regulator_get() to not have to manage the lifecycle, but ends up doing it in a very hacky way by replacing the device node of the power domain controller device to the device node of the power domain that is currently being registered, getting the supply, and reverting the device node. Provide a better API so that the hack can be replaced. Signed-off-by: Chen-Yu Tsai Link: https://patch.msgid.link/20240925093807.1026949-3-wenst@chromium.org Signed-off-by: Mark Brown

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: devres: fix devm_regulator_get_enable_read_voltage() return

2024-05-07T01:31:47+00:00

The devm_regulator_get_enable_read_voltage() function is supposed to return the voltage that the regulator is currently set to. However, it currently returns 0. Fixes: b250c20b6429 ("regulator: devres: add API for reference voltage supplies") Signed-off-by: David Lechner Link: https://lore.kernel.org/r/20240506-regulator-devm_regulator_get_enable_read_voltage-fixes-v1-1-356cdd152067@baylibre.com Signed-off-by: Mark Brown

regulator: devres: add API for reference voltage supplies

2024-05-03T02:08:12+00:00

A common use case for regulators is to supply a reference voltage to an analog input or output device. This adds a new devres API to get, enable, and get the voltage in a single call. This allows eliminating boilerplate code in drivers that use reference supplies in this way. Signed-off-by: David Lechner Link: https://lore.kernel.org/r/20240429-regulator-get-enable-get-votlage-v2-1-b1f11ab766c1@baylibre.com Signed-off-by: Mark Brown

regulator: core: Use different devices for resource allocation and DT lookup

2022-12-08T13:02:37+00:00

Following by the below discussion, there's the potential UAF issue between regulator and mfd. https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/ From the analysis of Yingliang CPU A |CPU B mt6370_probe() | devm_mfd_add_devices() | |mt6370_regulator_probe() | regulator_register() | //allocate init_data and add it to devres | regulator_of_get_init_data() i2c_unregister_device() | device_del() | devres_release_all() | // init_data is freed | release_nodes() | | // using init_data causes UAF | regulator_register() It's common to use mfd core to create child device for the regulator. In order to do the DT lookup for init data, the child that registered the regulator would pass its parent as the parameter. And this causes init data resource allocated to its parent, not itself. The issue happen when parent device is going to release and regulator core is still doing some operation of init data constraint for the regulator of child device. To fix it, this patch expand 'regulator_register' API to use the different devices for init data allocation and DT lookup. Reported-by: Yang Yingliang Signed-off-by: ChiYuan Huang Link: https://lore.kernel.org/r/1670311341-32664-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown

regulator: devres: Add devm_regulator_bulk_get_exclusive()

2022-11-03T13:34:53+00:00

We had an exclusive variant of the devm_regulator_get() API, but no corresponding variant for the bulk API; let's add one now. We add a generalized version of the existing regulator_bulk_get() function that additionally takes a get_type parameter and redefine regulator_bulk_get() in terms of it, then do similarly with devm_regulator_bulk_get(), and finally add the new devm_regulator_bulk_get_exclusive(). Signed-off-by: Zev Weiss Link: https://lore.kernel.org/r/20221031233704.22575-2-zev@bewilderbeest.net Signed-off-by: Mark Brown

regulator: Add devm helpers for get and enable

2022-08-18T11:51:48+00:00

A few regulator consumer drivers seem to be just getting a regulator, enabling it and registering a devm-action to disable the regulator at the driver detach and then forget about it. We can simplify this a bit by adding a devm-helper for this pattern. Add devm_regulator_get_enable() and devm_regulator_get_enable_optional() Signed-off-by: Matti Vaittinen Link: https://lore.kernel.org/r/ed7b8841193bb9749d426f3cb3b199c9460794cd.1660292316.git.mazziesaccount@gmail.com Signed-off-by: Mark Brown