user/sven/linux.git/include/linux/regulator, branch v6.1.96

regulator: change devm_regulator_get_enable_optional() stub to return Ok

2024-05-17T09:55:56Z

[ Upstream commit ff33132605c1a0acea59e4c523cb7c6fabe856b2 ] The devm_regulator_get_enable_optional() should be a 'call and forget' API, meaning, when it is used to enable the regulators, the API does not provide a handle to do any further control of the regulators. It gives no real benefit to return an error from the stub if CONFIG_REGULATOR is not set. On the contrary, returning an error is causing problems to drivers when hardware is such it works out just fine with no regulator control. Returning an error forces drivers to specifically handle the case where CONFIG_REGULATOR is not set, making the mere existence of the stub questionalble. Change the stub implementation for the devm_regulator_get_enable_optional() to return Ok so drivers do not separately handle the case where the CONFIG_REGULATOR is not set. Signed-off-by: Matti Vaittinen Fixes: da279e6965b3 ("regulator: Add devm helpers for get and enable") Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/ZiedtOE00Zozd3XO@fedora Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: change stubbed devm_regulator_get_enable to return Ok

2024-05-17T09:55:55Z

[ Upstream commit 96e20adc43c4f81e9163a5188cee75a6dd393e09 ] The devm_regulator_get_enable() should be a 'call and forget' API, meaning, when it is used to enable the regulators, the API does not provide a handle to do any further control of the regulators. It gives no real benefit to return an error from the stub if CONFIG_REGULATOR is not set. On the contrary, returning and error is causing problems to drivers when hardware is such it works out just fine with no regulator control. Returning an error forces drivers to specifically handle the case where CONFIG_REGULATOR is not set, making the mere existence of the stub questionalble. Furthermore, the stub of the regulator_enable() seems to be returning Ok. Change the stub implementation for the devm_regulator_get_enable() to return Ok so drivers do not separately handle the case where the CONFIG_REGULATOR is not set. Signed-off-by: Matti Vaittinen Reported-by: Aleksander Mazur Suggested-by: Guenter Roeck Fixes: da279e6965b3 ("regulator: Add devm helpers for get and enable") Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/ZiYF6d1V1vSPcsJS@drtxq0yyyyyyyyyyyyyby-3.rev.dnainternet.fi Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: mt6358: Drop *_SSHUB regulators

2023-10-10T20:00:40Z

[ Upstream commit 04ba665248ed91576d326041108e5fc2ec2254eb ] The *_SSHUB regulators are actually alternate configuration interfaces for their non *_SSHUB counterparts. They are not separate regulator outputs. These registers are intended for the companion processor to use to configure the power rails while the main processor is sleeping. They are not intended for the main operating system to use. Since they are not real outputs they shouldn't be modeled separately. Remove them. Luckily no device tree actually uses them. Signed-off-by: Chen-Yu Tsai Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Matthias Brugger Link: https://lore.kernel.org/r/20230609083009.2822259-5-wenst@chromium.org Signed-off-by: Mark Brown Stable-dep-of: 7e37c851374e ("regulator: mt6358: split ops for buck and linear range LDO regulators") Signed-off-by: Sasha Levin

regulator: pca9450: Fix LDO3OUT and LDO4OUT MASK

2023-06-28T09:12:26Z

[ Upstream commit 7257d930aadcd62d1c7971ab14f3b1126356abdc ] L3_OUT and L4_OUT Bit fields range from Bit 0:4 and thus the mask should be 0x1F instead of 0x0F. Fixes: 0935ff5f1f0a ("regulator: pca9450: add pca9450 pmic driver") Signed-off-by: Teresa Remmet Reviewed-by: Frieder Schrempf Link: https://lore.kernel.org/r/20230614125240.3946519-1-t.remmet@phytec.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

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

2022-12-31T12:33:04Z

[ Upstream commit 8f3cbcd6b440032ebc7f7d48a1689dcc70a4eb98 ] 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 Signed-off-by: Sasha Levin

regulator: gpio: Add input_supply support in gpio_regulator_config

2022-09-29T14:20:14Z

This is simillar as fixed-regulator. Used to extract regulator parent from the device tree. Without that property used, the parent regulator can be shut down (if not an always on). Thus leading to inappropriate behavior: On am62-SP-SK this fix is required to avoid tps65219 ldo1 (SDMMC rail) to be shut down after boot completion. Signed-off-by: Jerome Neanne Link: https://lore.kernel.org/r/20220929132526.29427-2-jneanne@baylibre.com Signed-off-by: Mark Brown

MediaTek Helio X10 MT6795 - MT6331/6332 Regulators

2022-09-13T16:43:23Z

Merge series from AngeloGioacchino Del Regno : In an effort to give some love to the apparently forgotten MT6795 SoC, I am upstreaming more components that are necessary to support platforms powered by this one apart from a simple boot to serial console. This series adds support for the regulators found in MT6331 and MT6332 main/companion PMICs. Adding support to each driver in each subsystem is done in different patch series as to avoid spamming uninteresting patches to maintainers. Tested on a MT6795 Sony Xperia M5 (codename "Holly") smartphone.

regulator: Add driver for MT6332 PMIC regulators

2022-09-13T14:04:58Z

Add a driver for the regulators found in the MT6332 PMICs, including six buck and four LDO regulators. Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220913123456.384513-5-angelogioacchino.delregno@collabora.com Signed-off-by: Mark Brown

regulator: Add driver for MT6331 PMIC regulators

2022-09-13T14:04:56Z

Add a driver for the regulators found in the MT6331 PMIC. This PMIC features six buck and 21 Low DropOut (LDO) regulators. Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220913123456.384513-3-angelogioacchino.delregno@collabora.com Signed-off-by: Mark Brown

regulator: Add devm helpers for get and enable

2022-08-18T11:51:48Z

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