regulator: devres: use devm_kmemdup_array()

Convert to use devm_kmemdup_array() which is more robust.

Signed-off-by: Raag Jadav <[email protected]>
Link: https://patch.msgid.link/20250228072057.

regulator: devres: use devm_kmemdup_array()

Convert to use devm_kmemdup_array() which is more robust.

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

show more ...

regulator: Add (devm_)of_regulator_get()

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

regulator: Add (devm_)of_regulator_get()

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 <[email protected]>
Signed-off-by: Sebastian Reichel <[email protected]>
Link: https://patch.msgid.link/20250220-rk3588-gpu-pwr-domain-regulator-v6-1-a4f9c24e5b81@kernel.org
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: Add devres version of of_regulator_get_optional()

There are existing uses for a devres version of of_regulator_get_optional()
in power domain drivers. On MediaTek platforms, power domains

regulator: Add devres version of of_regulator_get_optional()

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

The devm_regulator_get_enable_read_voltage() function is supposed to
return the voltage that the regulator is currently set to.

regulator: devres: fix devm_regulator_get_enable_read_voltage() return

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 <[email protected]>
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 <[email protected]>

show more ...

regulator: devres: add API for reference voltage supplies

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,
en

regulator: devres: add API for reference voltage supplies

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 <[email protected]>
Link: https://lore.kernel.org/r/20240429-regulator-get-enable-get-votlage-v2-1-b1f11ab766c1@baylibre.com
Signed-off-by: Mark Brown <[email protected]>

show more ...

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

Following by the below discussion, there's the potential UAF issue
between regulator and mfd.
https://lore.kernel.org/all

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

Following by the below discussion, there's the potential UAF issue
between regulator and mfd.
https://lore.kernel.org/all/[email protected]/

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 <[email protected]>
Signed-off-by: ChiYuan Huang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: devres: Add devm_regulator_bulk_get_exclusive()

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
ge

regulator: devres: Add devm_regulator_bulk_get_exclusive()

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

show more ...

regulator: Add devm helpers for get and enable

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

regulator: Add devm helpers for get and enable

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 <[email protected]>
Link: https://lore.kernel.org/r/ed7b8841193bb9749d426f3cb3b199c9460794cd.1660292316.git.mazziesaccount@gmail.com
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: core: Allow drivers to define their init data as const

Drivers tend to want to define the names of their regulators somewhere
in their source file as "static const". This means, inevitabl

regulator: core: Allow drivers to define their init data as const

Drivers tend to want to define the names of their regulators somewhere
in their source file as "static const". This means, inevitable, that
every driver out there open codes something like this:

static const char * const supply_names[] = {
"vcc", "vccl",
};

static int get_regulators(struct my_data *data)
{
int i;

data->supplies = devm_kzalloc(...)
if (!data->supplies)
return -ENOMEM;

for (i = 0; i < ARRAY_SIZE(supply_names); i++)
data->supplies[i].supply = supply_names[i];

return devm_regulator_bulk_get(data->dev,
ARRAY_SIZE(supply_names),
data->supplies);
}

Let's make this more convenient by doing providing a helper that does
the copy.

I have chosen to have the "const" input structure here be the exact
same structure as the normal one passed to
devm_regulator_bulk_get(). This is slightly inefficent since the input
data can't possibly have anything useful for "ret" or consumer and
thus we waste 8 bytes per structure. This seems an OK tradeoff for not
introducing an extra structure.

Signed-off-by: Douglas Anderson <[email protected]>
Link: https://lore.kernel.org/r/20220726103631.v2.6.I38fc508a73135a5c1b873851f3553ff2a3a625f5@changeid
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: devres: unexport devm_regulator_unregister_supply_alias()

This API hook isn't used anywhere outside of the regulator devres code.
This function is needed for the devm_regulator_bulk_regis

regulator: devres: unexport devm_regulator_unregister_supply_alias()

This API hook isn't used anywhere outside of the regulator devres code.
This function is needed for the devm_regulator_bulk_register_supply_alias()
function on the error path, to cleanup any previously registered supply
aliases.

This change makes the devm_regulator_unregister_supply_alias() local to the
regulator core framework, to avoid it being used in any weird logic.
It's also removing the doc-string for
devm_regulator_unregister_supply_alias(), since it doesn't need to be
documented anymore, as no other external consumer should use it.

Signed-off-by: Alexandru Ardelean <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: devres: remove devm_regulator_bulk_unregister_supply_alias()

This API hook isn't used anywhere and most-likely exists because of the
general principle of C APIs, where if an API function

regulator: devres: remove devm_regulator_bulk_unregister_supply_alias()

This API hook isn't used anywhere and most-likely exists because of the
general principle of C APIs, where if an API function does an
allocation/registration, it must also have an equivalent
deallocation/deregistration counterpart.

For devm_ functions this isn't all that true (for all cases), as the idea
of these function is to provide an auto-cleanup logic on drivers/system
de-init.

Removing this also discourages any weird logic that could be created with
such an API function.

Signed-off-by: Alexandru Ardelean <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: devres: remove devm_regulator_unregister() function

This API hook isn't used anywhere and most-likely exists because of the
general principle of C APIs, where if an API function does an
a

regulator: devres: remove devm_regulator_unregister() function

This API hook isn't used anywhere and most-likely exists because of the
general principle of C APIs, where if an API function does an
allocation/registration, it must also have an equivalent
deallocation/deregistration counterpart.

For devm_ functions this isn't all that true (for all cases), as the idea
of these function is to provide an auto-cleanup logic on drivers/system
de-init.

Removing this also discourages any weird logic that could be created with
such an API function.

Signed-off-by: Alexandru Ardelean <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: IRQ based event/error notification helpers

Provide helper function for IC's implementing regulator notifications
when an IRQ fires. The helper also works for IRQs which can not be acked.

regulator: IRQ based event/error notification helpers

Provide helper function for IC's implementing regulator notifications
when an IRQ fires. The helper also works for IRQs which can not be acked.
Helper can be set to disable the IRQ at handler and then re-enabling it
on delayed work later. The helper also adds regulator_get_error_flags()
errors in cache for the duration of IRQ disabling.

Signed-off-by: Matti Vaittinen <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/ebdf86d8c22b924667ec2385330e30fcbfac0119.1622628334.git.matti.vaittinen@fi.rohmeurope.com
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: devres: Standardise on function documentation headers

Line up descriptions, start description with a lower-case character and
omit old definitions such as quoting the old argument "consum

regulator: devres: Standardise on function documentation headers

Line up descriptions, start description with a lower-case character and
omit old definitions such as quoting the old argument "consumer".

Signed-off-by: Lee Jones <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: devres: Fix issues with kerneldoc headers

Provide descriptions for some missing function args and
rename others to match the names used.

Fixes the following W=1 warning(s):

drivers/reg

regulator: devres: Fix issues with kerneldoc headers

Provide descriptions for some missing function args and
rename others to match the names used.

Fixes the following W=1 warning(s):

drivers/regulator/devres.c:187: warning: Function parameter or member 'dev' not described in 'devm_regulator_register'
drivers/regulator/devres.c:226: warning: Function parameter or member 'dev' not described in 'devm_regulator_unregister'
drivers/regulator/devres.c:226: warning: Function parameter or member 'rdev' not described in 'devm_regulator_unregister'
drivers/regulator/devres.c:226: warning: Excess function parameter 'regulator' description in 'devm_regulator_unregister'

Signed-off-by: Lee Jones <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152

Based on 1 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of th

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152

Based on 1 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 3029 file(s).

Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Allison Randal <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

regulator: core: optimize devm_regulator_bulk_get()

When performing this bulk operation, there is no need to track every supply
individually. It is more efficient to treat entire group as a single
m

regulator: core: optimize devm_regulator_bulk_get()

When performing this bulk operation, there is no need to track every supply
individually. It is more efficient to treat entire group as a single
managed resource.

Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: core: have _regulator_get() accept get_type argument

Instead of separate "exclusive" and "allow_dummy" arguments, that formed 3
valid combinations (normal, exclusive and optional) and an

regulator: core: have _regulator_get() accept get_type argument

Instead of separate "exclusive" and "allow_dummy" arguments, that formed 3
valid combinations (normal, exclusive and optional) and an invalid one,
let's accept explicit "get_type", like we did in devm-managed code.

Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: Remove support for optional supplies in the bulk API

The patch was based on my missinterpretation of the API and only
accidentally worked for me. Let's clean it out to not confuse others.

regulator: Remove support for optional supplies in the bulk API

The patch was based on my missinterpretation of the API and only
accidentally worked for me. Let's clean it out to not confuse others.

This reverts commit 3ff3f518a135fa4592fe2817e9ac2cce1fa23dc2.

Signed-off-by: Bjorn Andersson <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: Make bulk API support optional supplies

Make it possible to use the bulk API with optional supplies, by allowing
the consumer to marking supplies as optional in the regulator_bulk_data.

regulator: Make bulk API support optional supplies

Make it possible to use the bulk API with optional supplies, by allowing
the consumer to marking supplies as optional in the regulator_bulk_data.

Signed-off-by: Bjorn Andersson <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: core: Add devres versions of notifier registration

Add devm_regulator_register_notifier, this adds the resource against the
device for the consumer supply we are registering the notifier

regulator: core: Add devres versions of notifier registration

Add devm_regulator_register_notifier, this adds the resource against the
device for the consumer supply we are registering the notifier for. There
seem to be few use-cases where this wouldn't be the users intention and
this ensures the notifiers will always be removed at the correct time.

Signed-off-by: Charles Keepax <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: Constify the pointer to alias name array

Toughen-up checks for read-only regulator names.

Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

regulator: core: Add ability to create a lookup alias for supply

These patches add the ability to create an alternative device on which
a lookup for a certain supply should be conducted.

A common u

regulator: core: Add ability to create a lookup alias for supply

These patches add the ability to create an alternative device on which
a lookup for a certain supply should be conducted.

A common use-case for this would be devices that are logically
represented as a collection of drivers within Linux but are are
presented as a single device from device tree. It this case it is
necessary for each sub device to locate their supply data on the main
device.

Signed-off-by: Charles Keepax <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: core: Split devres code out into a separate file

Cut down on the size of core.c a bit more and ensure that the devres
versions of things don't do too much peering inside the internals of

regulator: core: Split devres code out into a separate file

Cut down on the size of core.c a bit more and ensure that the devres
versions of things don't do too much peering inside the internals of
the APIs they wrap.

Signed-off-by: Mark Brown <[email protected]>

show more ...