linux-stable.git/drivers/regulator/core.c, branch linux-6.9.y Linux kernel stable tree regulator: core: Fix modpost error "regulator_get_regmap" undefined 2024-06-27T11:52:24+00:00 Biju Das biju.das.jz@bp.renesas.com 2024-06-10T19:55:32+00:00 5f8fbf7c8f040b16920418fdd9c95dcd1d1e47a1 [ Upstream commit 3f60497c658d2072714d097a177612d34b34aa3d ] Fix the modpost error "regulator_get_regmap" undefined by adding export symbol. Fixes: 04eca28cde52 ("regulator: Add helpers for low-level register access") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202406110117.mk5UR3VZ-lkp@intel.com Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20240610195532.175942-1-biju.das.jz@bp.renesas.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 3f60497c658d2072714d097a177612d34b34aa3d ]

Fix the modpost error "regulator_get_regmap" undefined by adding export
symbol.

Fixes: 04eca28cde52 ("regulator: Add helpers for low-level register access")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202406110117.mk5UR3VZ-lkp@intel.com
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20240610195532.175942-1-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
regulator: core: fix debugfs creation regression 2024-05-09T15:43:57+00:00 Johan Hovold johan+linaro@kernel.org 2024-05-09T13:33:04+00:00 2a4b49bb58123bad6ec0e07b02845f74c23d5e04 regulator_get() may sometimes be called more than once for the same consumer device, something which before commit dbe954d8f163 ("regulator: core: Avoid debugfs: Directory ... already present! error") resulted in errors being logged. A couple of recent commits broke the handling of such cases so that attributes are now erroneously created in the debugfs root directory the second time a regulator is requested and the log is filled with errors like: debugfs: File 'uA_load' in directory '/' already present! debugfs: File 'min_uV' in directory '/' already present! debugfs: File 'max_uV' in directory '/' already present! debugfs: File 'constraint_flags' in directory '/' already present! on any further calls. Fixes: 2715bb11cfff ("regulator: core: Fix more error checking for debugfs_create_dir()") Fixes: 08880713ceec ("regulator: core: Streamline debugfs operations") Cc: stable@vger.kernel.org Cc: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240509133304.8883-1-johan+linaro@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> 
regulator_get() may sometimes be called more than once for the same
consumer device, something which before commit dbe954d8f163 ("regulator:
core: Avoid debugfs: Directory ...  already present! error") resulted in
errors being logged.

A couple of recent commits broke the handling of such cases so that
attributes are now erroneously created in the debugfs root directory the
second time a regulator is requested and the log is filled with errors
like:

	debugfs: File 'uA_load' in directory '/' already present!
	debugfs: File 'min_uV' in directory '/' already present!
	debugfs: File 'max_uV' in directory '/' already present!
	debugfs: File 'constraint_flags' in directory '/' already present!

on any further calls.

Fixes: 2715bb11cfff ("regulator: core: Fix more error checking for debugfs_create_dir()")
Fixes: 08880713ceec ("regulator: core: Streamline debugfs operations")
Cc: stable@vger.kernel.org
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20240509133304.8883-1-johan+linaro@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: core: Propagate the regulator state in case of exclusive get 2024-03-12T13:55:57+00:00 Kory Maincent kory.maincent@bootlin.com 2024-03-12T09:16:38+00:00 e4ead3cdfd798092288f3a06b405cf98ded6fa10 Previously, performing an exclusive get on an already-enabled regulator resulted in inconsistent state initialization between child and parent regulators. While the child's counts were updated, its parent's counters remained unaffected. Consequently, attempting to disable an already-enabled exclusive regulator triggered unbalanced disables warnings from its parent regulator. This commit addresses the issue by propagating the enable state to the parent regulator using a regulator_enable call. This ensures consistent state management across the regulator hierarchy, preventing warnings! Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> Link: https://msgid.link/r/20240312091638.1266167-1-kory.maincent@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org> 
Previously, performing an exclusive get on an already-enabled regulator
resulted in inconsistent state initialization between child and parent
regulators. While the child's counts were updated, its parent's counters
remained unaffected.

Consequently, attempting to disable an already-enabled exclusive regulator
triggered unbalanced disables warnings from its parent regulator.

This commit addresses the issue by propagating the enable state to the
parent regulator using a regulator_enable call. This ensures consistent
state management across the regulator hierarchy, preventing warnings!

Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Link: https://msgid.link/r/20240312091638.1266167-1-kory.maincent@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: core: make regulator_class constant 2024-03-05T19:20:21+00:00 Ricardo B. Marliere ricardo@marliere.net 2024-03-05T19:00:45+00:00 4fe6207508d6525e87149348daeafde152ba672c Since commit 43a7206b0963 ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the regulator_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Link: https://msgid.link/r/20240305-class_cleanup-regulator-v1-1-4950345d6d8f@marliere.net Signed-off-by: Mark Brown <broonie@kernel.org> 
Since commit 43a7206b0963 ("driver core: class: make class_register() take
a const *"), the driver core allows for struct class to be in read-only
memory, so move the regulator_class structure to be declared at build time
placing it into read-only memory, instead of having to be dynamically
allocated at boot time.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net>
Link: https://msgid.link/r/20240305-class_cleanup-regulator-v1-1-4950345d6d8f@marliere.net
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: core: Remove redundant assignment to variable possible_uV 2024-02-19T16:59:35+00:00 Colin Ian King colin.i.king@gmail.com 2024-02-16T13:49:18+00:00 055100d1a3b27ce154b3e3041d3cef24778821b3 The variable possible_uV being assigned a value that is never read, the control flow via the following goto statement takes a path where the variable is not accessed. The assignment is redundant and can be removed. Cleans up clang scan build warning: drivers/regulator/core.c:3935:3: warning: Value stored to 'possible_uV' is never read [deadcode.DeadStores] Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://msgid.link/r/20240216134918.2108262-1-colin.i.king@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> 
The variable possible_uV being assigned a value that is never read, the
control flow via the following goto statement takes a path where the
variable is not accessed. The assignment is redundant and can be removed.

Cleans up clang scan build warning:
drivers/regulator/core.c:3935:3: warning: Value stored to 'possible_uV'
is never read [deadcode.DeadStores]

Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://msgid.link/r/20240216134918.2108262-1-colin.i.king@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: event: Add regulator netlink event support 2023-12-06T13:14:54+00:00 Naresh Solanki naresh.solanki@9elements.com 2023-12-05T10:52:04+00:00 16e5ac127d8d18adf85fe5ba847d77b58d1ed418 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 <naresh.solanki@9elements.com> Link: https://lore.kernel.org/r/20231205105207.1262928-1-naresh.solanki@9elements.com Signed-off-by: Mark Brown <broonie@kernel.org> 
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 <naresh.solanki@9elements.com>
Link: https://lore.kernel.org/r/20231205105207.1262928-1-naresh.solanki@9elements.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: add under-voltage support (part 2) 2023-11-13T18:15:05+00:00 Mark Brown broonie@kernel.org 2023-11-13T18:15:05+00:00 753e4d5c433da57da75dd4c3e1aececc8e874a62 Merge series from Oleksij Rempel <o.rempel@pengutronix.de>: This series add under-voltage and emergency shutdown for system critical regulators 
Merge series from Oleksij Rempel <o.rempel@pengutronix.de>:

This series add under-voltage and emergency shutdown for system critical
regulators
regulator: core: Only increment use_count when enable_count changes 2023-11-13T01:26:30+00:00 Rui Zhang zr.zhang@vivo.com 2023-11-03T07:42:31+00:00 7993d3a9c34f609c02171e115fd12c10e2105ff4 The use_count of a regulator should only be incremented when the enable_count changes from 0 to 1. Similarly, the use_count should only be decremented when the enable_count changes from 1 to 0. In the previous implementation, use_count was sometimes decremented to 0 when some consumer called unbalanced disable, leading to unexpected disable even the regulator is enabled by other consumers. With this change, the use_count accurately reflects the number of users which the regulator is enabled. This should make things more robust in the case where a consumer does leak references. Signed-off-by: Rui Zhang <zr.zhang@vivo.com> Link: https://lore.kernel.org/r/20231103074231.8031-1-zr.zhang@vivo.com Signed-off-by: Mark Brown <broonie@kernel.org> 
The use_count of a regulator should only be incremented when the
enable_count changes from 0 to 1. Similarly, the use_count should
only be decremented when the enable_count changes from 1 to 0.

In the previous implementation, use_count was sometimes decremented
to 0 when some consumer called unbalanced disable,
leading to unexpected disable even the regulator is enabled by
other consumers. With this change, the use_count accurately reflects
the number of users which the regulator is enabled.

This should make things more robust in the case where a consumer does
leak references.

Signed-off-by: Rui Zhang <zr.zhang@vivo.com>
Link: https://lore.kernel.org/r/20231103074231.8031-1-zr.zhang@vivo.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: core: Add option to prevent disabling unused regulators 2023-11-13T01:26:29+00:00 Javier Martinez Canillas javierm@redhat.com 2023-11-07T19:09:18+00:00 c986968fe92f20f2db26fa6bce27795b2e9ebe22 This may be useful for debugging and develompent purposes, when there are drivers that depend on regulators to be enabled but do not request them. It is inspired from the clk_ignore_unused and pd_ignore_unused parameters, that are used to keep firmware-enabled clocks and power domains on even if these are not used by drivers. The parameter is not expected to be used in normal cases and should not be needed on a platform with proper driver support. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Brian Masney <bmasney@redhat.com> Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20231107190926.1185326-1-javierm@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org> 
This may be useful for debugging and develompent purposes, when there are
drivers that depend on regulators to be enabled but do not request them.

It is inspired from the clk_ignore_unused and pd_ignore_unused parameters,
that are used to keep firmware-enabled clocks and power domains on even if
these are not used by drivers.

The parameter is not expected to be used in normal cases and should not be
needed on a platform with proper driver support.

Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20231107190926.1185326-1-javierm@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: Implement uv_survival_time for handling under-voltage events 2023-11-13T01:26:28+00:00 Oleksij Rempel o.rempel@pengutronix.de 2023-10-26T14:48:24+00:00 1e22152aa59d793743fc53051dd7a042f362aecb 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 <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20231026144824.4065145-6-o.rempel@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org> 
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 <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20231026144824.4065145-6-o.rempel@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>