regulator: allow user configuration of hardware protection action

When the core detects permanent regulator hardware failure or imminent
power failure of a critical supply, it will call hw_protectio

regulator: allow user configuration of hardware protection action

When the core detects permanent regulator hardware failure or imminent
power failure of a critical supply, it will call hw_protection_shutdown in
an attempt to do a limited orderly shutdown followed by powering off the
system.

This doesn't work out well for many unattended embedded systems that don't
have support for shutdown and that power on automatically when power is
supplied:

- A brief power cycle gets detected by the driver
- The kernel powers down the system and SoC goes into shutdown mode
- Power is restored
- The system remains oblivious to the restored power
- System needs to be manually power cycled for a duration long enough
to drain the capacitors

Allow users to fix this by calling the newly introduced
hw_protection_trigger() instead: This way the hw_protection commandline or
sysfs parameter is used to dictate the policy of dealing with the
regulator fault.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Ahmad Fatoum <[email protected]>
Reviewed-by: Tzung-Bi Shih <[email protected]>
Reviewed-by: Matti Vaittinen <[email protected]>
Cc: Benson Leung <[email protected]>
Cc: Daniel Lezcano <[email protected]>
Cc: Fabio Estevam <[email protected]>
Cc: Guenter Roeck <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Liam Girdwood <[email protected]>
Cc: Lukasz Luba <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Matteo Croce <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Rob Herring (Arm) <[email protected]>
Cc: Rui Zhang <[email protected]>
Cc: Sascha Hauer <[email protected]>
Cc: "Serge E. Hallyn" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

regulator: check that dummy regulator has been probed before using it

Due to asynchronous driver probing there is a chance that the dummy
regulator hasn't already been probed when first accessing it

regulator: check that dummy regulator has been probed before using it

Due to asynchronous driver probing there is a chance that the dummy
regulator hasn't already been probed when first accessing it.

Cc: [email protected]
Signed-off-by: Christian Eggers <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: core: Fix deadlock in create_regulator()

Currently, we are unnecessarily holding a regulator_ww_class_mutex lock
when creating debugfs entries for a newly created regulator. This was
brou

regulator: core: Fix deadlock in create_regulator()

Currently, we are unnecessarily holding a regulator_ww_class_mutex lock
when creating debugfs entries for a newly created regulator. This was
brought up as a concern in the discussion in commit cba6cfdc7c3f
("regulator: core: Avoid lockdep reports when resolving supplies").

This causes the following lockdep splat after executing
`ls /sys/kernel/debug` on my platform:

======================================================
WARNING: possible circular locking dependency detected
5.15.167-axis9-devel #1 Tainted: G O
------------------------------------------------------
ls/2146 is trying to acquire lock:
ffffff803a562918 (&mm->mmap_lock){++++}-{3:3}, at: __might_fault+0x40/0x88

but task is already holding lock:
ffffff80014497f8 (&sb->s_type->i_mutex_key#3){++++}-{3:3}, at: iterate_dir+0x50/0x1f4

which lock already depends on the new lock.

[...]

Chain exists of:
&mm->mmap_lock --> regulator_ww_class_mutex --> &sb->s_type->i_mutex_key#3

Possible unsafe locking scenario:

CPU0 CPU1
---- ----
lock(&sb->s_type->i_mutex_key#3);
lock(regulator_ww_class_mutex);
lock(&sb->s_type->i_mutex_key#3);
lock(&mm->mmap_lock);

*** DEADLOCK ***

This lock dependency still exists on the latest kernel and using a newer
non-tainted kernel would still cause this problem.

Fix by moving sysfs symlinking and creation of debugfs entries to after
the release of the regulator lock.

Fixes: cba6cfdc7c3f ("regulator: core: Avoid lockdep reports when resolving supplies")
Fixes: eaa7995c529b ("regulator: core: avoid regulator_resolve_supply() race condition")
Signed-off-by: Ludvig Pärsson <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: core: let dt properties override driver init_data

This reverts commit cd7a38c40b231350a3cd0fd774f4e6bb68c4b411.

When submitting the change above, it was thought that the origin of the
in

regulator: core: let dt properties override driver init_data

This reverts commit cd7a38c40b231350a3cd0fd774f4e6bb68c4b411.

When submitting the change above, it was thought that the origin of the
init_data should be a clear choice, from the driver or from DT but not
both.

It turns out some devices, such as qcom-msm8974-lge-nexus5-hammerhead,
relied on the old behaviour to override the init_data provided by the
driver, making it some kind of default if none is provided by the platform.

Using the init_data provided by the driver when it is present broke these
devices so revert the change to fixup the situation and add a comment
to make things a bit more clear

Reported-by: Luca Weiss <[email protected]>
Closes: https://lore.kernel.org/lkml/[email protected]
Fixes: cd7a38c40b23 ("regulator: core: do not silently ignore provided init_data")
Signed-off-by: Jerome Brunet <[email protected]>
Link: https://patch.msgid.link/20250211-regulator-init-data-fixup-v1-1-5ce1c6cff990@baylibre.com
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: core: Add missing newline character

dev_err_probe() error messages need newline character.

Fixes: 6eabfc018e8d ("regulator: core: Allow specifying an initial load w/ the bulk API")
Signe

regulator: core: Add missing newline character

dev_err_probe() error messages need newline character.

Fixes: 6eabfc018e8d ("regulator: core: Allow specifying an initial load w/ the bulk API")
Signed-off-by: Alexander Stein <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: Add support for power budget

Introduce power budget management for the regulator device. Enable tracking
of available power capacity by providing helpers to request and release
power budg

regulator: Add support for power budget

Introduce power budget management for the regulator device. Enable tracking
of available power capacity by providing helpers to request and release
power budget allocations.

Signed-off-by: Kory Maincent <[email protected]>
Link: https://patch.msgid.link/20250115-feature_regulator_pw_budget-v2-1-0a44b949e6bc@bootlin.com
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: core: Resolve supply using of_node from regulator_config

Previously, the regulator core resolved its supply only from the parent
device or its children, ignoring the of_node specified in

regulator: core: Resolve supply using of_node from regulator_config

Previously, the regulator core resolved its supply only from the parent
device or its children, ignoring the of_node specified in the
regulator_config structure.
This behavior causes issues in scenarios where multiple regulator devices
are registered for components described as children of a controller, each
with their own specific regulator supply.

For instance, in a PSE controller with multiple PIs (Power Interfaces),
each PI may have a distinct regulator supply. However, the regulator core
would incorrectly use the PSE controller node or its first child to look up
the regulator supply, rather than the node specified by the
regulator_config->of_node for the PI.

This update modifies the behavior to prioritize the of_node in
regulator_config for resolving the supply. This ensures correct resolution
of the power supply for each device. If no supply is found in the provided
of_node, the core falls back to searching within the parent device as
before.

Reviewed-by: Oleksij Rempel <[email protected]>
Signed-off-by: Kory Maincent <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: core: Ignore unset max_uA constraints in current limit check

We should only consider max_uA constraints if they are explicitly defined.
In cases where it is not set, we should assume the

regulator: core: Ignore unset max_uA constraints in current limit check

We should only consider max_uA constraints if they are explicitly defined.
In cases where it is not set, we should assume the regulator has no current
limit.

Signed-off-by: Kory Maincent <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: core: Use fsleep() to get best sleep mechanism

_regulator_delay_helper() implements the recommondation of the outdated
documentation which sleep mechanism should be used. There is already

regulator: core: Use fsleep() to get best sleep mechanism

_regulator_delay_helper() implements the recommondation of the outdated
documentation which sleep mechanism should be used. There is already a
function in place which does everything and also maps to reality called
fsleep().

Use fsleep() directly.

Cc: Liam Girdwood <[email protected]>
Cc: Mark Brown <[email protected]>
Signed-off-by: Anna-Maria Behnsen <[email protected]>
Reviewed-by: Frederic Weisbecker <[email protected]>
Link: https://patch.msgid.link/20241014-devel-anna-maria-b4-timers-flseep-v3-11-dc8b907cb62f@linutronix.de
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: core: remove machine init callback from config

The machine specific regulator_init() appears to be unused.
It does not allow a lot of interaction with the regulator framework,
since nothi

regulator: core: remove machine init callback from config

The machine specific regulator_init() appears to be unused.
It does not allow a lot of interaction with the regulator framework,
since nothing from the framework is passed along (desc, config,
etc ...)

Machine specific init may also be done with the added init_cb() in
the regulator description, so remove regulator_init().

Signed-off-by: Jerome Brunet <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: core: add callback to perform runtime init

Provide an initialisation callback to handle runtime parameters.
The idea is similar to the regulator_init() callback, but it provides
regulator

regulator: core: add callback to perform runtime init

Provide an initialisation callback to handle runtime parameters.
The idea is similar to the regulator_init() callback, but it provides
regulator specific structures, instead of just the driver specific data.

As an example, this allows the driver to amend the regulator constraints
based on runtime parameters if necessary.

Signed-off-by: Jerome Brunet <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: core: do not silently ignore provided init_data

On DT platforms, if a regulator init_data is provided in config, it is
silently ignored in favor of the DT parsing done by the framework, i

regulator: core: do not silently ignore provided init_data

On DT platforms, if a regulator init_data is provided in config, it is
silently ignored in favor of the DT parsing done by the framework, if
of_match is set.

of_match is an indication that init_data is expected to be set based on DT
and the parsing should be done by the regulator framework.

If the regulator provider passed init_data it must be because it is useful
somehow, in such case of_match should be clear.

If the driver expects the framework to initialize this data on its
own, it should leave init_data clear.

Warn if both init_data and of_match are set, then default to the provided
init_data.

Signed-off-by: Jerome Brunet <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: Add of_regulator_get_optional() for pure DT regulator lookup

The to-be-introduced I2C component prober needs to enable regulator
supplies (and toggle GPIO pins) for the various components

regulator: Add of_regulator_get_optional() for pure DT regulator lookup

The to-be-introduced I2C component prober needs to enable regulator
supplies (and toggle GPIO pins) for the various components it intends
to probe. To support this, a new "pure DT lookup" method for getting
regulator supplies is needed, since the device normally requesting
the supply won't get created until after the component is probed to
be available.

Add a new of_regulator_get_optional() function for this. This mirrors
the existing regulator_get_optional() function, but is OF-specific.
The underlying code that supports the existing regulator_get*()
functions has been reworked in previous patches to support this
specific case.

Also convert an existing usage of "dev && dev->of_node" to
"dev_of_node(dev)".

Link: https://lore.kernel.org/all/[email protected]/ [1]
Signed-off-by: Chen-Yu Tsai <[email protected]>
Link: https://patch.msgid.link/[email protected]
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: Split up _regulator_get()

_regulator_get() contains a lot of common code doing checks prior to the
regulator lookup and housekeeping work after the lookup. Almost all the
code could be sh

regulator: Split up _regulator_get()

_regulator_get() contains a lot of common code doing checks prior to the
regulator lookup and housekeeping work after the lookup. Almost all the
code could be shared with a OF-specific variant of _regulator_get().

Split out the common parts so that they can be reused. The OF-specific
version of _regulator_get() will be added in a subsequent patch.
No functional changes were made.

Signed-off-by: Chen-Yu Tsai <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: core: fix the broken behavior of regulator_dev_lookup()

The behavior of regulator_dev_lookup() for non-DT way has been broken
since the commit b8c325545714 ("regulator: Move OF-specific r

regulator: core: fix the broken behavior of regulator_dev_lookup()

The behavior of regulator_dev_lookup() for non-DT way has been broken
since the commit b8c325545714 ("regulator: Move OF-specific regulator
lookup code to of_regulator.c").

Before the commit, of_get_regulator() was used to get the regulator,
which returns NULL if the regulator is not found. So the regulator
will be looked up through regulator_lookup_by_name() if no matching
regulator is found in regulator_map_list.

However, currently, of_regulator_dev_lookup() is used to instead of
of_get_regulator(), but the variable 'r' is set to ERR_PTR(-ENODEV)
instead of NULL if the regulator is not found. In this case, if no
regulator is found in regulator_map_list, the variable 'r' is still
ERR_PTR(-ENODEV), So regulator_dev_lookup() returns the value of 'r'
directly instead of continuing to look up the regulator through
regulator_lookup_by_name().

Fixes: b8c325545714 ("regulator: Move OF-specific regulator lookup code to of_regulator.c")
Signed-off-by: Wei Fang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: Move OF-specific regulator lookup code to of_regulator.c

There's still a bit of OF-specific code in the regulator device lookup
function.

Move those bits of code over to of_regulator.c,

regulator: Move OF-specific regulator lookup code to of_regulator.c

There's still a bit of OF-specific code in the regulator device lookup
function.

Move those bits of code over to of_regulator.c, and create a new
function of_regulator_dev_lookup() to encapsulate the code moved out of
regulator_dev_lookup().

Also mark of_find_regulator_by_node() as static, since there are no
other users in other compile units.

There are no functional changes. A line alignment was also fixed.

Signed-off-by: Chen-Yu Tsai <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: Unify "negative error number" terminology in comments

Previous commits cleaning up kerneldoc used the term "negative error
number" to refer to error condition return values. Update remain

regulator: Unify "negative error number" terminology in comments

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 <[email protected]>
Reported-by: Andy Shevchenko <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: core: Add missing kerneldoc "Return" sections

kernel-doc complains about missing "Return" section for many documented
functions in the regulator core. Some with free-form return value
des

regulator: core: Add missing kerneldoc "Return" sections

kernel-doc complains about missing "Return" section for many documented
functions in the regulator core. Some with free-form return value
descriptions have been fixed in the previous patch. The remaining are
completely missing any mention of return values.

Add "Return" sections to these kerneldoc blocks with basic descriptions.
In a few cases where the functions don't call even more functions and
the error numbers are known, those are documented in detail.

Signed-off-by: Chen-Yu Tsai <[email protected]>
Reported-by: Andy Shevchenko <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: core: Fix incorrectly formatted kerneldoc "Return" sections

kernel-doc complains about missing "Return" section for many documented
functions in the regulator core. Many of them actually

regulator: core: Fix incorrectly formatted kerneldoc "Return" sections

kernel-doc complains about missing "Return" section for many documented
functions in the regulator core. Many of them actually have descriptions
about the return values, just not in the format kernel-doc wants.

Convert these to use the proper "Return:" section header. The existing
descriptions have been reworded and moved around to fit the grammar and
formatting.

In a few cases where the functions don't call even more functions
and the error numbers are known, those are documented in detail.

Signed-off-by: Chen-Yu Tsai <[email protected]>
Reported-by: Andy Shevchenko <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: core: Fix regulator_is_supported_voltage() kerneldoc return value

The kerneldoc for regulator_is_supported_voltage() states that the
return value is a boolean. That is not correct, as it

regulator: core: Fix regulator_is_supported_voltage() kerneldoc return value

The kerneldoc for regulator_is_supported_voltage() states that the
return value is a boolean. That is not correct, as it could return an
error number if the check failed.

Fix the description by expanding it to cover the valid return values and
error conditions. The description is also converted to a proper "Return"
section.

Fixes: c5f3939b8fe0 ("regulator: core: Support fixed voltages in regulator_is_supported_voltage()")
Signed-off-by: Chen-Yu Tsai <[email protected]>
Reported-by: Andy Shevchenko <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: core: Fix short description for _regulator_check_status_enabled()

kernel-doc complains that _regulator_check_status_enabled() is missing a
short description.

Since the current descriptio

regulator: core: Fix short description for _regulator_check_status_enabled()

kernel-doc complains that _regulator_check_status_enabled() is missing a
short description.

Since the current description is already quite short, just trim it a bit
more and use it as the short description.

Fixes: f7d7ad42a9dc ("regulator: Allow regulators to verify enabled during enable()")
Signed-off-by: Chen-Yu Tsai <[email protected]>
Reported-by: Andy Shevchenko <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: Clarify error message for "id == NULL" in _regulator_get()

The original error message simply said "get() with no identifier"
without any context as to what was requested or what device th

regulator: Clarify error message for "id == NULL" in _regulator_get()

The original error message simply said "get() with no identifier"
without any context as to what was requested or what device the
request was related to. The only thing the user or developer could
do was grep for the message in the full source tree.

Amend the error message to be more specific, and also use dev_*
to associate the error message with a device.

Signed-off-by: Chen-Yu Tsai <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: core: Add helper for allow HW access to enable/disable regulator

Add a helper function that allow regulator consumers to allow low-level
HW access, in order to enable/disable regulator in

regulator: core: Add helper for allow HW access to enable/disable regulator

Add a helper function that allow regulator consumers to allow low-level
HW access, in order to enable/disable regulator in atomic context.

The use-case for RZ/G2L SoC is to enable VBUS selection register based
on vbus detection that happens in interrupt context.

Signed-off-by: Biju Das <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: core: Fix modpost error "regulator_get_regmap" undefined

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

Fixes: 04eca28cde52 ("regulator: Add helpers for

regulator: core: Fix modpost error "regulator_get_regmap" undefined

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 <[email protected]>
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]
Signed-off-by: Biju Das <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: core: fix debugfs creation regression

regulator_get() may sometimes be called more than once for the same
consumer device, something which before commit dbe954d8f163 ("regulator:
core: Av

regulator: core: fix debugfs creation regression

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: [email protected]
Cc: Geert Uytterhoeven <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...