regulator: da9063: better fix null deref with partial DT

Two versions of the original patch were sent but V1 was merged instead
of V2 due to a mistake.

So update to V2.

The advantage of V2 is that

regulator: da9063: better fix null deref with partial DT

Two versions of the original patch were sent but V1 was merged instead
of V2 due to a mistake.

So update to V2.

The advantage of V2 is that it completely avoids dereferencing the pointer,
even just to take the address, which may fix problems with some compilers.
Both versions work on my gcc 9.4 but use the safer one.

Fixes: 98e2dd5f7a8b ("regulator: da9063: fix null pointer deref with partial DT config")
Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
Tested-by: Benjamin Bara <benjamin.bara@skidata.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230804083514.1887124-1-martin.fuzzey@flowbird.group
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

regulator: da9063: fix null pointer deref with partial DT config

When some of the da9063 regulators do not have corresponding DT nodes
a null pointer dereference occurs on boot because such regulato

regulator: da9063: fix null pointer deref with partial DT config

When some of the da9063 regulators do not have corresponding DT nodes
a null pointer dereference occurs on boot because such regulators have
no init_data causing the pointers calculated in
da9063_check_xvp_constraints() to be invalid.

Do not dereference them in this case.

Fixes: b8717a80e6ee ("regulator: da9063: implement setter for voltage monitoring")
Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
Link: https://lore.kernel.org/r/20230616143736.2946173-1-martin.fuzzey@flowbird.group
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

regulator: da9063: implement setter for voltage monitoring

Allow to en- and disable voltage monitoring from the device tree.
Consider that the da9063 only monitors under- *and* over-voltage
together

regulator: da9063: implement setter for voltage monitoring

Allow to en- and disable voltage monitoring from the device tree.
Consider that the da9063 only monitors under- *and* over-voltage
together, so both must be set to the same severity and value.

Reviewed-by: Adam Ward <DLG-Adam.Ward.opensource@dm.renesas.com>
Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>
Link: https://lore.kernel.org/r/20230403-da9063-disable-unused-v3-2-cc4dc698864c@skidata.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

regulator: da9063: add voltage monitoring registers

Add the definitions for the registers responsible for voltage
monitoring. Add a voltage monitor enable bitfield per regulator.

Reviewed-by: Matti

regulator: da9063: add voltage monitoring registers

Add the definitions for the registers responsible for voltage
monitoring. Add a voltage monitor enable bitfield per regulator.

Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Adam Ward <DLG-Adam.Ward.opensource@dm.renesas.com>
Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>
Link: https://lore.kernel.org/r/20230403-da9063-disable-unused-v3-1-cc4dc698864c@skidata.com
Signed-off-by: Mark Brown <broonie@kernel.org>

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/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk
[2] https://lore.kernel.org/r/20200903232441.2694866-1-dianders@chromium.org/

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20230316125351.1.I2a4677392a38db5758dee0788b2cea5872562a82@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

regulator: da9063: Add support for full-current mode.

In addition to the ability of merging some power outputs, this chip has
an overdrive mode.
BCORE1, BCORE2 and BPRO have this ability, in which c

regulator: da9063: Add support for full-current mode.

In addition to the ability of merging some power outputs, this chip has
an overdrive mode.
BCORE1, BCORE2 and BPRO have this ability, in which case the legal
current draw is increased from 2 amps to 2.5 amps (at the expense of
a quiescent current increase), and the configurable current limits
are doubled.
If a current higher than maximum half-current mode is requested, enable
overdrive, and scale the current limit down.
Symmetrically, scale the current limit up when querying a overdrive-enabled
regulator.

Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>
Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/824518e6391b783a12eba9ff0527f06607a34bfb.1626160826.git.plr.vincent@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

regulator: remove locking around regulator_notifier_call_chain()

regulator_notifier_call_chain() doesn't need rdev lock and rdev's
existence is assumed in the code anyway. Remove the locks from driv

regulator: remove locking around regulator_notifier_call_chain()

regulator_notifier_call_chain() doesn't need rdev lock and rdev's
existence is assumed in the code anyway. Remove the locks from drivers.

Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/42393f66dcc4d80dcd9797be45216b4035aa96cb.1597032945.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

regulator: da9063: fix LDO9 suspend and warning.

Commit 99f75ce66619 ("regulator: da9063: fix suspend") converted
the regulators to use a common (corrected) suspend bit setting but
one of regulators

regulator: da9063: fix LDO9 suspend and warning.

Commit 99f75ce66619 ("regulator: da9063: fix suspend") converted
the regulators to use a common (corrected) suspend bit setting but
one of regulators (LDO9) slipped through the crack.

This means that the original problem was not fixed for LDO9 and
also leads to a warning found by the test robot.
da9063-regulator.c:515:3: warning: initialized field overwritten

Fix this by converting that regulator too like the others.

Fixes: 99f75ce66619 ("regulator: da9063: fix suspend")
Reported-by: kernel test robot <lkp@intel.com>

Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
Link: https://lore.kernel.org/r/1591959073-16792-1-git-send-email-martin.fuzzey@flowbird.group
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

regulator: da9063: Fix get_mode() functions to read sleep field

get_mode() is used to retrieve the active mode state. Settings-A
config is used during active state, whilst Settings-B is for
suspend.

regulator: da9063: Fix get_mode() functions to read sleep field

get_mode() is used to retrieve the active mode state. Settings-A
config is used during active state, whilst Settings-B is for
suspend. This means we only need to check the sleep field of each
buck and LDO as that field solely relates to Settings-A config.

This change is a clone of the get_mode() update which was committed
as part of:
- regulator: da9062: fix suspend_enable/disable preparation
[a72865f057820ea9f57597915da4b651d65eb92f]

Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/20200324092516.60B5C3FB8D@swsrvapps-01.diasemi.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

regulator: da9063: fix suspend

The .set_suspend_enable() and .set_suspend_disable() methods are not
supposed to immediately change the regulator state but just indicated
if the regulator should be e

regulator: da9063: fix suspend

The .set_suspend_enable() and .set_suspend_disable() methods are not
supposed to immediately change the regulator state but just indicated
if the regulator should be enabled or disabled when standby mode is
entered (by a hardware signal).

However currently they set control the SEL bits in the DVC registers,
which causes the voltage to change to immediately between the "A"
(normal) and "B" (standby) values as programmed and does nothing for
the enable state...

This means that "regulator-on-in-suspend" does not work (the regulator
is switched off when the PMIC enters standby mode on the hardware
signal) and, potentially, depending on the A and B voltage
configurations the voltage could be incorrectly changed *before*
actually entering suspend.

The right bit to use for the functionality is the "CONF" bit in the
"CONT" register.
The detailed register description says "Sequencer target state"
for this bit which is not very clear but the functional description
is clearer.

>From 5.1.5 System Enable:

De-asserting SYS_EN (changing from active to passive state)
clears control SYSTEM_EN which triggers a power down sequence
into hibernate/standby mode
...
With the exception of supplies that have the xxxx_CONF control
bit asserted, all regulators in power domains POWER1, POWER, and
SYSTEM are sequentially disabled in reverse order.
Regulators with the <x>_CONF bit set remain on but change the
active voltage controlregisters from V<x>_A to V<x>_B
(if V<x>_B is notalready selected).

Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
Link: https://lore.kernel.org/r/1584461691-14344-1-git-send-email-martin.fuzzey@flowbird.group
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

regulator: da9063: Replace zero-length array with flexible-array member

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to

regulator: da9063: Replace zero-length array with flexible-array member

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
int stuff;
struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertenly introduced[3] to the codebase from now on.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Link: https://lore.kernel.org/r/20200211234710.GA29532@embeddedor
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

regulator: da9063: remove redundant return statement

The devm_request_threaded_irq() already returns 0 on success
and negative error code on failure. So return from this itself
can be used while pre

regulator: da9063: remove redundant return statement

The devm_request_threaded_irq() already returns 0 on success
and negative error code on failure. So return from this itself
can be used while preserving error log in case of failure.

Signed-off-by: Rishi Gupta <gupt21@gmail.com>
Link: https://lore.kernel.org/r/1580996996-28798-1-git-send-email-gupt21@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

regulator: da9063: fix code formatting warnings and errors

This commit fixes following errors & warnings in this driver
as reported by checkpatch.pl:

- WARNING: Prefer 'unsigned int' to bare use of

regulator: da9063: fix code formatting warnings and errors

This commit fixes following errors & warnings in this driver
as reported by checkpatch.pl:

- WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
- WARNING: line over 80 characters
- ERROR: space prohibited before that ',' (ctx:WxW)
- ERROR: code indent should use tabs where possible
- WARNING: Block comments use * on subsequent lines

Signed-off-by: Rishi Gupta <gupt21@gmail.com>
Link: https://lore.kernel.org/r/1580996917-28494-1-git-send-email-gupt21@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

regulator: da9063: Simplify da9063_buck_set_mode for BUCK_MODE_MANUAL case

The sleep flag bit decides the mode for BUCK_MODE_MANUAL case, simplify
the logic as the result is the same.

Signed-off-by

regulator: da9063: Simplify da9063_buck_set_mode for BUCK_MODE_MANUAL case

The sleep flag bit decides the mode for BUCK_MODE_MANUAL case, simplify
the logic as the result is the same.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/20190926055128.23434-2-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

regulator: Remove dev_err() usage after platform_get_irq()

We don't need dev_err() messages when platform_get_irq() fails now that
platform_get_irq() prints an error message itself when something go

regulator: Remove dev_err() usage after platform_get_irq()

We don't need dev_err() messages when platform_get_irq() fails now that
platform_get_irq() prints an error message itself when something goes
wrong. Let's remove these prints with a simple semantic patch.

// <smpl>
@@
expression ret;
struct platform_device *E;
@@

ret =
(
platform_get_irq(E, ...)
|
platform_get_irq_byname(E, ...)
);

if ( \( ret < 0 \| ret <= 0 \) )
{
(
-if (ret != -EPROBE_DEFER)
-{ ...
-dev_err(...);
-... }
|
...
-dev_err(...);
)
...
}
// </smpl>

While we're here, remove braces on if statements that only have one
statement (manually).

Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20190730181557.90391-38-swboyd@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

regulator: da9063: platform_data is gone, depend on OF

With OF being the only configuration possibility left, depend on it to
simplify some code.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engin

regulator: da9063: platform_data is gone, depend on OF

With OF being the only configuration possibility left, depend on it to
simplify some code.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Steve Twiss <stwiss.opensource@diasemi.com>
Tested-by: Steve Twiss <stwiss.opensource@diasemi.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

regulator: da9063: move definitions out of a header into the driver

Those definitions are only used within the driver meanwhile, so put them
there.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-eng

regulator: da9063: move definitions out of a header into the driver

Those definitions are only used within the driver meanwhile, so put them
there.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Steve Twiss <stwiss.opensource@diasemi.com>
Tested-by: Steve Twiss <stwiss.opensource@diasemi.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

regulator: da9063: remove platform_data support

There are no in-kernel users anymore, so remove this outdated interface.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by:

regulator: da9063: remove platform_data support

There are no in-kernel users anymore, so remove this outdated interface.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Steve Twiss <stwiss.opensource@diasemi.com>
Tested-by: Steve Twiss <stwiss.opensource@diasemi.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

regulator: da9063: convert header to SPDX

Covnert the header of the source file to SPDX.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: da9063: Convert to use regulator_set/get_current_limit_regmap

Use regulator_set/get_current_limit_regmap helpers to save some code.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by

regulator: da9063: Convert to use regulator_set/get_current_limit_regmap

Use regulator_set/get_current_limit_regmap helpers to save some code.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Steve Twiss <stwiss@opensource.diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

regulator: da9063: Fix notifier mutex lock warning

The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that funct

regulator: da9063: Fix notifier mutex lock warning

The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.

Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.

Fixes: 69ca3e58d178 ("regulator: da9063: Add Dialog DA9063 voltage regulators support.")
Suggested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

regulator: da9063: Use struct_size() in devm_kzalloc()

One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
w

regulator: da9063: Use struct_size() in devm_kzalloc()

One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:

struct foo {
int stuff;
struct boo entry[];
};

size = sizeof(struct foo) + count * sizeof(struct boo);
instance = alloc(size, GFP_KERNEL)

Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:

instance = alloc(struct_size(instance, entry, count), GFP_KERNEL)

Notice that, in this case, variable size is not necessary, hence it is
removed.

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

regulator: da9063: Select maximum current in specific range for set_current_limit

Selecting the minimal value is only true for voltage regulators.
For current regulators the maximum in the given ran

regulator: da9063: Select maximum current in specific range for set_current_limit

Selecting the minimal value is only true for voltage regulators.
For current regulators the maximum in the given range should be
selected instead.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

regulator: da9063: Check return value of devm_regmap_field_alloc calls

Since devm_regmap_field_alloc can fail, add error checking for it.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by

regulator: da9063: Check return value of devm_regmap_field_alloc calls

Since devm_regmap_field_alloc can fail, add error checking for it.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

regulator: da9063: Handle less LDOs on DA9063L

Move the LDOs present only on DA9063 at the end of the list, so that
the DA9063L can simply indicate less LDOs and still share the list of
regulators w

regulator: da9063: Handle less LDOs on DA9063L

Move the LDOs present only on DA9063 at the end of the list, so that
the DA9063L can simply indicate less LDOs and still share the list of
regulators with DA9063.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

show more ...