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

regulator: pickable ranges: don't always cache vsel

2024-06-12T09:39:39Z

[ Upstream commit f4f4276f985a5aac7b310a4ed040b47e275e7591 ] Some PMICs treat the vsel_reg same as apply-bit. Eg, when voltage range is changed, the new voltage setting is not taking effect until the vsel register is written. Add a flag 'range_applied_by_vsel' to the regulator desc to indicate this behaviour and to force the vsel value to be written to hardware if range was changed, even if the old selector was same as the new one. Signed-off-by: Matti Vaittinen Link: https://msgid.link/r/ZktCpcGZdgHWuN_L@fedora Signed-off-by: Mark Brown Stable-dep-of: 1ace99d7c7c4 ("regulator: tps6287x: Force writing VSEL bit") Signed-off-by: Sasha Levin

regulator: change devm_regulator_get_enable_optional() stub to return Ok

2024-04-24T01:13:30Z

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

regulator: change stubbed devm_regulator_get_enable to return Ok

2024-04-23T01:39:28Z

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

regulator: max8973: Finalize switch to GPIO descriptors

2024-02-26T13:46:33Z

The dvs gpio was still using a legacy number passed from the platform data. There are no in-tree users of the platform data so just switch it to a gpio descriptor and obtain it in probe(), the device tree users will work just as fine with this. Drop the entirely unused enable_gpio from the platform data as well. The device tree bindings mentions this but the driver does not look for it and makes no use of it: it should probably be implemented properly in a separate patch. Signed-off-by: Linus Walleij Link: https://msgid.link/r/20240220-descriptors-regulators-v1-1-097f608694be@linaro.org Acked-by: Lee Jones Signed-off-by: Mark Brown

regulator: Reuse LINEAR_RANGE() in REGULATOR_LINEAR_RANGE()

2023-12-19T16:15:14Z

REGULATOR_LINEAR_RANGE() repeats what LINEAR_RANGE() provides. Deduplicate the former by using the latter. No functional change intended. Signed-off-by: Andy Shevchenko Link: https://msgid.link/r/20231219154012.2478688-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown

regulator: event: Add regulator netlink event support

2023-12-06T13:14:54Z

This commit introduces netlink event support to the regulator subsystem. Changes: - Introduce event.c and regnl.h for netlink event handling. - Implement reg_generate_netlink_event to broadcast regulator events. - Update Makefile to include the new event.c file. Signed-off-by: Naresh Solanki Link: https://lore.kernel.org/r/20231205105207.1262928-1-naresh.solanki@9elements.com Signed-off-by: Mark Brown

regulator: Implement uv_survival_time for handling under-voltage events

2023-11-13T01:26:28Z

Add 'uv_survival_time' field to regulation_constraints for specifying survival time post critical under-voltage event. Update the regulator notifier call chain and Device Tree property parsing to use this new field, allowing a configurable timeout before emergency shutdown. Signed-off-by: Oleksij Rempel Link: https://lore.kernel.org/r/20231026144824.4065145-6-o.rempel@pengutronix.de Signed-off-by: Mark Brown

regulator: Introduce handling for system-critical under-voltage events

2023-11-13T01:26:25Z

Handle under-voltage events for crucial regulators to maintain system stability and avoid issues during power drops. Signed-off-by: Oleksij Rempel Link: https://lore.kernel.org/r/20231026144824.4065145-3-o.rempel@pengutronix.de Signed-off-by: Mark Brown

regulator: mt6358: Add missing regulators for MT6366

2023-10-02T18:43:49Z

When support for the MT6366 PMIC regulators was added, it was assumed that it had the same functionality as MT6358. In reality there are differences. A few regulators have different ranges, or were renamed and repurposed, or removed altogether. Add the 3 regulators that were missing from the original submission. These are added for completeness. VSRAM_CORE is not used in existing projects. VM18 and VMDDR feed DRAM related consumers, and are not used in-kernel. Signed-off-by: Chen-Yu Tsai Reviewed-by: AngeloGioacchino Del Regno Acked-by: Lee Jones Link: https://lore.kernel.org/r/20230928085537.3246669-11-wenst@chromium.org Signed-off-by: Mark Brown

regulator: db8500-prcmu: Remove unused declaration power_state_active_is_enabled()

2023-08-18T12:58:05Z

Commit 38e968380b27 ("regulators/db8500: split off shared dbx500 code") removed this but not its declaration. Signed-off-by: Yue Haibing Link: https://lore.kernel.org/r/20230818124227.15084-1-yuehaibing@huawei.com Signed-off-by: Mark Brown