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: fixed: Fix incorrectly formatted kerneldoc "Return" section

kernel-doc complains about missing "Return" section for kerneldoc of
of_get_fixed_voltage_config(). The kerneldoc has a descrip

regulator: fixed: Fix incorrectly formatted kerneldoc "Return" section

kernel-doc complains about missing "Return" section for kerneldoc of
of_get_fixed_voltage_config(). The kerneldoc has a description
about the return values, just not in the format kernel-doc wants.

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

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: fixed: add support for under-voltage IRQ

Add interrupt support for under-voltage notification. This functionality
can be used on systems capable to detect under-voltage state and having
e

regulator: fixed: add support for under-voltage IRQ

Add interrupt support for under-voltage notification. This functionality
can be used on systems capable to detect under-voltage state and having
enough capacity to let the SoC do some emergency preparation.

This change enforce default policy to shutdown system as soon as
interrupt is triggered.

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

show more ...

regulator: Explicitly include correct DT includes

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of th

regulator: Explicitly include correct DT includes

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

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

show more ...

regulator: Handle deferred clk

devm_clk_get() can return -EPROBE_DEFER. So it is better to return the
error code from devm_clk_get(), instead of a hard coded -ENOENT.

This gives more opportunities

regulator: Handle deferred clk

devm_clk_get() can return -EPROBE_DEFER. So it is better to return the
error code from devm_clk_get(), instead of a hard coded -ENOENT.

This gives more opportunities to successfully probe the driver.

Fixes: 8959e5324485 ("regulator: fixed: add possibility to enable by clock")
Signed-off-by: Christophe JAILLET <[email protected]>
Link: https://lore.kernel.org/r/18459fae3d017a66313699c7c8456b28158b2dd0.1679819354.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14

Probing of regulators can be a slow operation and can contribute to
slower boot times. This is especially true if a regulato

regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14

Probing of regulators can be a slow operation and can contribute to
slower boot times. This is especially true if a regulator is turned on
at probe time (with regulator-boot-on or regulator-always-on) and the
regulator requires delays (off-on-time, ramp time, etc).

While the overall kernel is not ready to switch to async probe by
default, as per the discussion on the mailing lists [1] it is believed
that the regulator subsystem is in good shape and we can move
regulator drivers over wholesale. There is no way to just magically
opt in all regulators (regulators are just normal drivers like
platform_driver), so we set PROBE_PREFER_ASYNCHRONOUS for all
regulators found in 'drivers/regulator' individually.

Given the number of drivers touched and the impossibility to test this
ahead of time, it wouldn't be shocking at all if this caused a
regression for someone. If there is a regression caused by this patch,
it's likely to be one of the cases talked about in [1]. As a "quick
fix", drivers involved in the regression could be fixed by changing
them to PROBE_FORCE_SYNCHRONOUS. That being said, the correct fix
would be to directly fix the problem that caused the issue with async
probe.

The approach here follows a similar approach that was used for the mmc
subsystem several years ago [2]. In fact, I ran nearly the same python
script to auto-generate the changes. The only thing I changed was to
search for "i2c_driver", "spmi_driver", and "spi_driver" in addition
to "platform_driver".

[1] https://lore.kernel.org/r/[email protected]
[2] https://lore.kernel.org/r/[email protected]/

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

show more ...

regulator: Use of_property_present() for testing DT property presence

It is preferred to use typed property access functions (i.e.
of_property_read_<type> functions) rather than low-level
of_get_pro

regulator: Use of_property_present() for testing DT property presence

It is preferred to use typed property access functions (i.e.
of_property_read_<type> functions) rather than low-level
of_get_property/of_find_property functions for reading properties. As
part of this, convert of_get_property/of_find_property calls to the
recently added of_property_present() helper when we just want to test
for presence of a property and nothing more.

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

show more ...

regulator: fixed: Remove print on allocation failure

OOMs are very verbose, we don't need to print an additional error message
when we fail to allocate.

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

regulator: fixed: Remove print on allocation failure

OOMs are very verbose, we don't need to print an additional error message
when we fail to allocate.

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

show more ...

regulator: fixed: use dev_err_probe for register

Instead of returning error directly, use dev_err_probe. This avoids
messages in the dmesg log for devices which will be probed again later.

Signed-o

regulator: fixed: use dev_err_probe for register

Instead of returning error directly, use dev_err_probe. This avoids
messages in the dmesg log for devices which will be probed again later.

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

show more ...

regulator: fixed: use dev_err_probe for gpio

Instead of returning the the PTR_ERR directly, use dev_err_probe which
will also correctly set the deferred probe reason in
/sys/kernel/debug/deferred_de

regulator: fixed: use dev_err_probe for gpio

Instead of returning the the PTR_ERR directly, use dev_err_probe which
will also correctly set the deferred probe reason in
/sys/kernel/debug/deferred_devices, making it easier to debug missing
devices on the system.

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

show more ...

regulator: fixed: Ensure enable_counter is correct if reg_domain_disable fails

dev_pm_genpd_set_performance_state() may fail, so had better to check it's
return value before decreasing priv->enable_

regulator: fixed: Ensure enable_counter is correct if reg_domain_disable fails

dev_pm_genpd_set_performance_state() may fail, so had better to check it's
return value before decreasing priv->enable_counter.

Fixes: bf3a28cf4241 ("regulator: fixed: support using power domain for enable/disable")
Signed-off-by: Axel Lin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: fixed: support using power domain for enable/disable

Adds possibility to choose the compatible "fixed-regulator-domain" for
regulators which use power domain for enabling/disabling corres

regulator: fixed: support using power domain for enable/disable

Adds possibility to choose the compatible "fixed-regulator-domain" for
regulators which use power domain for enabling/disabling corresponding
regulator.

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

show more ...

regulator: fixed: Constify static regulator_ops

The only usage of fixed_voltage_ops and fixed_voltage_clkenabled_ops is
to assign their address the ops field in the regulator_desc struct,
which is a

regulator: fixed: Constify static regulator_ops

The only usage of fixed_voltage_ops and fixed_voltage_clkenabled_ops is
to assign their address the ops field in the regulator_desc struct,
which is a const pointer. Make them const to allow the compiler to put
them in read-only memory.
make them const to allow the compiler to put them in read-only memory.

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

show more ...

regulator: fixed: Fix W=1 build warnings when CONFIG_OF=n

Fix below warnings when CONFIG_OF=n:

drivers/regulator/fixed.c:48:36: warning: ‘fixed_clkenable_data’ defined but not used [-Wunused-const-

regulator: fixed: Fix W=1 build warnings when CONFIG_OF=n

Fix below warnings when CONFIG_OF=n:

drivers/regulator/fixed.c:48:36: warning: ‘fixed_clkenable_data’ defined but not used [-Wunused-const-variable=]
48 | static const struct fixed_dev_type fixed_clkenable_data = {
| ^~~~~~~~~~~~~~~~~~~~
drivers/regulator/fixed.c:44:36: warning: ‘fixed_voltage_data’ defined but not used [-Wunused-const-variable=]
44 | static const struct fixed_dev_type fixed_voltage_data = {
| ^~~~~~~~~~~~~~~~~~

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

show more ...

regulator: fix spelling mistake "Cant" -> "Can't"

There is a spelling mistake in a dev_err message. Fix it.

Signed-off-by: Colin Ian King <[email protected]>
Link: https://lore.kernel.org/r/

regulator: fix spelling mistake "Cant" -> "Can't"

There is a spelling mistake in a dev_err message. Fix it.

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

show more ...

regulator: Fix trivial spelling

The word 'descriptor' is misspelled throughout the tree.

Fix it up accordingly:
decriptors -> descriptors

Signed-off-by: Kieran Bingham <kieran.bingham+renesas@

regulator: Fix trivial spelling

The word 'descriptor' is misspelled throughout the tree.

Fix it up accordingly:
decriptors -> descriptors

Signed-off-by: Kieran Bingham <[email protected]>
Link: https://lore.kernel.org/r/20200609124610.3445662-10-kieran.bingham+renesas@ideasonboard.com
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: fixed: add off-on-delay

Depends on board design, the gpio controlling regulator may
connects with a big capacitance. When need off, it takes some time
to let the regulator to be truly off

regulator: fixed: add off-on-delay

Depends on board design, the gpio controlling regulator may
connects with a big capacitance. When need off, it takes some time
to let the regulator to be truly off. If not add enough delay, the
regulator might have always been on, so introduce off-on-delay to
handle such case.

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

show more ...

regulator: fixed: Prevent NULL pointer dereference when !CONFIG_OF

Use of_device_get_match_data which has NULL test for match before
dereference match->data. Add NULL test for drvtype so it still wo

regulator: fixed: Prevent NULL pointer dereference when !CONFIG_OF

Use of_device_get_match_data which has NULL test for match before
dereference match->data. Add NULL test for drvtype so it still works
for fixed_voltage_ops when !CONFIG_OF.

Signed-off-by: Axel Lin <[email protected]>
Reviewed-by: Philippe Schenker <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: fixed: add possibility to enable by clock

This commit adds the possibility to choose the compatible
"regulator-fixed-clock" in devicetree.

This is a special regulator-fixed that has to h

regulator: fixed: add possibility to enable by clock

This commit adds the possibility to choose the compatible
"regulator-fixed-clock" in devicetree.

This is a special regulator-fixed that has to have a clock, from which
the regulator gets switched on and off.

Signed-off-by: Philippe Schenker <[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: fixed/gpio: Pull inversion/OD into gpiolib

This pushes the handling of inversion semantics and open drain
settings to the GPIO descriptor and gpiolib. All affected board
files are also au

regulator: fixed/gpio: Pull inversion/OD into gpiolib

This pushes the handling of inversion semantics and open drain
settings to the GPIO descriptor and gpiolib. All affected board
files are also augmented.

This is especially nice since we don't have to have any
confusing flags passed around to the left and right littering
the fixed and GPIO regulator drivers and the regulator core.
It is all just very straight-forward: the core asks the GPIO
line to be asserted or deasserted and gpiolib deals with the
rest depending on how the platform is configured: if the line
is active low, it deals with that, if the line is open drain,
it deals with that too.

Cc: Alexander Shiyan <[email protected]> # i.MX boards user
Cc: Haojian Zhuang <[email protected]> # MMP2 maintainer
Cc: Aaro Koskinen <[email protected]> # OMAP1 maintainer
Cc: Tony Lindgren <[email protected]> # OMAP1,2,3 maintainer
Cc: Mike Rapoport <[email protected]> # EM-X270 maintainer
Cc: Robert Jarzmik <[email protected]> # EZX maintainer
Cc: Philipp Zabel <[email protected]> # Magician maintainer
Cc: Petr Cvek <[email protected]> # Magician
Cc: Robert Jarzmik <[email protected]> # PXA
Cc: Paul Parsons <[email protected]> # hx4700
Cc: Daniel Mack <[email protected]> # Raumfeld maintainer
Cc: Marc Zyngier <[email protected]> # Zeus maintainer
Cc: Geert Uytterhoeven <[email protected]> # SuperH pinctrl/GPIO maintainer
Cc: Russell King <[email protected]> # SA1100
Tested-by: Marek Szyprowski <[email protected]>
Tested-by: Janusz Krzysztofik <[email protected]> #OMAP1 Amstrad Delta
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: fixed: Let core handle GPIO descriptor

Use the gpiod_get() rather than the devm_* version so that the
regulator core can handle the lifecycle of these descriptors.

Fixes: efdfeb079cc3 ("

regulator: fixed: Let core handle GPIO descriptor

Use the gpiod_get() rather than the devm_* version so that the
regulator core can handle the lifecycle of these descriptors.

Fixes: efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor only")
Signed-off-by: Linus Walleij <[email protected]>
Reviewed-by: Marek Szyprowski <[email protected]>
Tested-by: Marek Szyprowski <[email protected]>
Reviewed-by: Charles Keepax <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator/gpio: Allow nonexclusive GPIO access

This allows nonexclusive (simultaneous) access to a single
GPIO line for the fixed regulator enable line. This happens
when several regulators use the

regulator/gpio: Allow nonexclusive GPIO access

This allows nonexclusive (simultaneous) access to a single
GPIO line for the fixed regulator enable line. This happens
when several regulators use the same GPIO for enabling and
disabling a regulator, and all need a handle on their GPIO
descriptor.

This solution with a special flag is not entirely elegant
and should ideally be replaced by something more careful as
this makes it possible for several consumers to
enable/disable the same GPIO line to the left and right
without any consistency. The current use inside the regulator
core should however be fine as it takes special care to
handle this.

For the state of the GPIO backend, this is still the
lesser evil compared to going back to global GPIO
numbers.

Cc: Marek Szyprowski <[email protected]>
Cc: Jon Hunter <[email protected]>
Fixes: efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor only")
Reported-by: Marek Szyprowski <[email protected]>
Tested-by: Jon Hunter <[email protected]>
Tested-by: Marek Szyprowski <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: fixed: Default enable high on DT regulators

commit efdfeb079cc3
("regulator: fixed: Convert to use GPIO descriptor only")
switched to use gpiod_get() to look up the regulator from the
gpi

regulator: fixed: Default enable high on DT regulators

commit efdfeb079cc3
("regulator: fixed: Convert to use GPIO descriptor only")
switched to use gpiod_get() to look up the regulator from the
gpiolib core whether that is device tree or boardfile.

This meant that we activate the code in
a603a2b8d86e ("gpio: of: Add special quirk to parse regulator flags")
which means the descriptors coming from the device tree already
have the right inversion and open drain semantics set up from
the gpiolib core.

As the fixed regulator was inspected again we got the
inverted inversion and things broke.

Fix it by ignoring the config in the device tree for now: the
later patches in the series will push all inversion handling
over to the gpiolib core and set it up properly in the
boardfiles for legacy devices, but I did not finish that
for this kernel cycle.

Fixes: commit efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor only")
Reported-by: Leonard Crestez <[email protected]>
Reported-by: Fabio Estevam <[email protected]>
Reported-by: John Stultz <[email protected]>
Reported-by: Anders Roxell <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Tested-by: John Stultz <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...

regulator: fixed: Convert to use GPIO descriptor only

As we augmented the regulator core to accept a GPIO descriptor instead
of a GPIO number, we can augment the fixed GPIO regulator to look up
and

regulator: fixed: Convert to use GPIO descriptor only

As we augmented the regulator core to accept a GPIO descriptor instead
of a GPIO number, we can augment the fixed GPIO regulator to look up
and pass that descriptor directly from device tree or board GPIO
descriptor look up tables.

Some boards just auto-enumerate their fixed regulator platform devices
and I have assumed they get names like "fixed-regulator.0" but it's
pretty hard to guess this. I need some testing from board maintainers to
be sure. Other boards are straight forward, using just plain
"fixed-regulator" (ID -1) or "fixed-regulator.1" hammering down the
device ID.

It seems the da9055 and da9211 has never got around to actually passing
any enable gpio into its platform data (not the in-tree code anyway) so we
can just decide to simply pass a descriptor instead.

The fixed GPIO-controlled regulator in mach-pxa/ezx.c was confusingly named
"*_dummy_supply_device" while it is a very real device backed by a GPIO
line. There is nothing dummy about it at all, so I renamed it with the
infix *_regulator_* as part of this patch set.

Intel MID portions tested by Andy.

Tested-by: Andy Shevchenko <[email protected]> # Check the x86 BCM stuff
Acked-by: Tony Lindgren <[email protected]> # OMAP1,2,3 maintainer
Signed-off-by: Linus Walleij <[email protected]>
Reviewed-by: Janusz Krzysztofik <[email protected]>
Reviewed-by: Mike Rapoport <[email protected]>
Signed-off-by: Mark Brown <[email protected]>

show more ...