regulator: arizona-ldo1: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://msgid.link/r/76c7af01e2c8b3ab6585a04bc3f0d163fbb7fdf7.1701778038.git.u.kleine-koenig@pengutronix.de
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: arizona-ldo1: Use PROBE_FORCE_SYNCHRONOUS

Restore synchronous probing for Arizona regulators because otherwise
the main MFD driver will not find its core supplies.

As these regulators are built into the CODEC and typically have no DT
representation the regulator framework is unaware of their existence
until the driver probes. These means the probing of the driver needs to
be synchronous to ensure the regulators are not substitued for the dummy
later when the users request them.

Fixes: 259b93b21a9f ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230323132047.833737-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 4.19 and 5.4

This follows on the change ("regulator: Set PROBE_PREFER_ASYNCHRONOUS
for drivers that existed in 4.14") but changes regulators didn't exist
in Linux 4.19 but did exist in Linux 5.4.

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

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>

regulator: use linear_ranges helper

Change the regulator helpers to use common linear_ranges code.

Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/64f01d5e381b8631a271616b7790f9d5640974fb.1588944082.git.matti.vaittinen@fi.rohmeurope.com
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: arizona-ldo1: Add support for Cirrus Logic Madera codecs

This adds a new driver identity "madera-ldo1" and probe function
so that this driver can be used to control the LDO1 regulator on
some Cirrus Logic Madera codecs.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: arizona: Switch to SPDX identifier

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: arizona_ldo1: Simplify arizona_ldo1_hc_set/get_voltage_sel

Setup .vsel_reg and .vsel_mask then we can use the standard
set/get_voltage_sel_regmap helpers to simplify the code.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: arizona-ldo1: Convert to use regulator_linear_range for ldo1_hc

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: arizona-ldo1: Rely on core to handle GPIO descriptor

After making sure that the regulator core always take over
handling of the GPIO descriptors, the gpiod_put()
on the errorpath of the Arizona LDO1 driver becomes
redundant.

Reported-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: Fetch enable gpiods nonexclusive

Since the core regulator code is treating GPIO descriptors as
nonexclusive, i.e. it assumes that the enable GPIO line may be
shared with several regulators, let's add the flag introduced
for fixing this problem on fixed regulators to all drivers
fetching GPIO descriptors to avoid possible regressions.

Reported-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: arizona-ldo1: Use correct device to get enable GPIO

Currently the enable GPIO is being looked up on the regulator
device itself but that does not have its own DT node, this causes
the lookup to fail and the regulator not to get its GPIO. The DT
node is shared across the whole MFD and as such the lookup needs
to happen on that parent device. Moving the lookup to the parent
device also means devres can no longer be used as the life time
would attach to the wrong device.

Additionally, the enable GPIO is active high so we should be passing
GPIOD_OUT_LOW to ensure the regulator starts in its off state allowing
the driver to enable it when it is ready.

Fixes: e1739e86f0cb ("regulator: arizona-ldo1: Look up a descriptor and pass to the core")
Reported-by: Matthias Reichl <hias@horus.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: arizona-ldo1: Look up a descriptor and pass to the core

Instead of passing a global GPIO number, pass a descriptor looked
up with the standard devm_gpiod_get_optional() call.

We have augmented the GPIO core to look up the regulator special
GPIO "wlf,ldoena" in commit 6a537d48461d
"gpio: of: Support regulator nonstandard GPIO properties".

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: arizona-ldo1: Factor out generic initialization

In preparation for sharing this driver with Madera codecs, factor out
the parts of initialization that aren't dependent on struct arizona.

Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: arizona-ldo1: Make arizona_ldo1 independent of struct arizona

In preparation for supporting Madera codecs, remove the dependency on
struct arizona in the regulator callbacks and struct arizona_ldo1.

Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: arizona-ldo1: Move pdata into a separate structure

In preparation for sharing this driver with Madera, move the pdata
for the LDO1 regulator out of struct arizona_pdata into a dedicated
pdata struct for this driver. As a result the code in
arizona_ldo1_of_get_pdata() can be made independent of struct arizona.

This patch also updates the definition of struct arizona_pdata and
the use of this pdata in mach-crag6410-module.c

Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: arizona-ldo1: Avoid potential memory leak reading init_data

The device argument passed to of_get_regulator_init_data is used to
do some devres memory allocation. Currently the driver passes the MFD
device pointer to this function, this could result in the init_data
allocation being leaked if the regulator is unbound but the MFD isn't.

Correct this issue by correctly passing the local platform device.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: arizona-ldo1: constify regulator_ops structure

Declare regulator_ops structure as const as it is only stored in the ops
field of a regulator_desc structure. This field is of type const, so
regulator_ops structures having this property can be made const too.

File size before: drivers/regulator/arizona-ldo1.o
text data bss dec hex filename
1890 720 0 2610 a32 drivers/regulator/arizona-ldo1.o

File size after: drivers/regulator/arizona-ldo1.o
text data bss dec hex filename
2402 192 0 2594 a22 drivers/regulator/arizona-ldo1.o

Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: arizona-ldo1: Set appropriate value for ramp_delay

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: arizona-ldo1: Fix handling of GPIO 0

The LDO1 driver is using the arizona_of_get_named_gpio helper function
which will return 0 if an error was encountered whilst parsing the GPIO,
as under the pdata scheme 0 was not being treated as a valid GPIO.
However, since the regulator framework was expanded to allow the use of
GPIO 0 this causes us to attempt to register GPIO 0 when we encountered
an error parsing the device tree.

This patch uses of_get_named_gpio directly and sets the
ena_gpio_initialized flag based on the return value.

Fixes: 1de3821ace82 ("regulator: Set ena_gpio_initialized in regulator drivers")
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: arizona: add support for WM8998 and WM1814

Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: arizona-ldo1: Do not control DVFS clocking from regulator

Using the driver for the internal regulator to also enable/disable
the codec internal clock frequency controller is an unexpected
side-effect for a regulator, and also means that the core clocks
won't be changed as expected if an external regulator is used to
power the codec.

The DVFS is now handled by the codec driver so can be removed from
the LDO1 driver.

Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: arizona-ldo1: Add additional supported voltage

This patch adds support for the 1.175V mode on the LDO1 regulator on the
wm5110. This is need as part of the low power sleep mode operation.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: arizona-ldo1: Drop OF node reference on error path

We were not calling of_node_put if the regulator failed to register this
patch fixes this.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: of: Add regulator desc param to of_get_regulator_init_data()

The of_get_regulator_init_data() function is used to extract the regulator
init_data but information on how to extract certain data is defined in the
static regulator descriptor (e.g: how to map the hardware operating modes).

Add a const struct regulator_desc * parameter to the function signature so
the parsing logic could use the information in the struct regulator_desc.

of_get_regulator_init_data() relies on of_get_regulation_constraints() to
actually extract the init_data so it has to pass the struct regulator_desc
but that is modified on a later patch.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: Set ena_gpio_initialized in regulator drivers

This patch sets ena_gpio_initialized for all drivers which set a
ena_gpio from parsed DT properties. Drivers using pdata may get zero
initialized pdata and therefore copy a 0 into the regulator_config
ena_gpio field.

Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>

regulator: drop owner assignment from platform_drivers

A platform_driver does not need to set an owner, it will be populated by the
driver core.

Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

regulator: arizona-ldo1: remove bypass functionality

WM5110/8280 devices do not support bypass mode for LDO1 so remove
the bypass callbacks registered with regulator core.

Signed-off-by: Nikesh Oswal <nikesh@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org

regulator: arizona-ldo1: add missing #include

commit 2cce4be9e6b8 "regulator: arizona-ldo1: Add processing of init_data
from device tree" added a call to of_get_child_by_name() but
did not add an #include to the header file declaring that function.

I got a build error when doing randconfig testing on this, which
is fixed by this patch to include of.h.

drivers/regulator/arizona-ldo1.c:192:2: error: implicit declaration of function 'of_get_child_by_name' [-Werror=implicit-function-declaration]
drivers/regulator/arizona-ldo1.c:193:2: error: implicit declaration of function 'of_parse_phandle' [-Werror=implicit-function-declaration]
drivers/regulator/arizona-ldo1.c:213:2: error: implicit declaration of function 'of_node_put' [-Werror=implicit-function-declaration]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

regulator: arizona-ldo1: Add processing of init_data from device tree

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

regulator: arizona-ldo1: Move setup processing from arizona-core

It is more idiomatic to process things relating to the regulator in its
driver. This patch moves both processing of device tree relating to the
regulator and checking if the regulator is external from arizona-core
into the regulator driver.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>

regulator: arizona-ldo1: Correct default regulator init_data

Both 5102 and 8997 have the regulator capable of supplying 1.8V, and the
voltage step from the 5110 regulator is different from what is specified
in the default description. This patch updates the default regulator
description to match 5110 and selects the 1.8V capable description for
8997.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org

regulator: arizona-ldo1: Remove redundant error message

kzalloc prints its own OOM message upon failure.

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>

regulator: arizona-ldo1: Convert to devm_regulator_register()

Signed-off-by: Mark Brown <broonie@linaro.org>

regulator: arizona: Increase ramp delay for high current regulators

As per latest evaluation.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

regulator: arizona-ldo1: Support 1.8V mode

Some Arizona device support a 1.8V output mode. Enable this in the driver.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

regulator: arizona-ldo1: Add additional top voltage

The number of voltage slots supported by the LDO is 7, not 6.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

regulator: arizona-ldo1: Support DVFS in default constraints

Some Arizona devices such as the WM5102 can use DVFS on their digital core,
for these devices allow the voltage range to vary in the default setup.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

regulator: arizona-ldo1: Add enable time

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

regulator: remove use of __devexit

CONFIG_HOTPLUG is going away as an option so __devexit is no
longer needed.

Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

regulator: remove use of __devinit

CONFIG_HOTPLUG is going away as an option so __devinit is no longer
needed.

Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

regulator: remove use of __devexit_p

CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.

Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

regulator: arizona-ldo: Remove top voltage

The highest voltage step is not supported.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

regulator: arizona-ldo: Support get/set bypass

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

regulator: arizona-ldo1: Implement GPIO enable support

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

regulator: Add driver for Arizona LDO1

Arizona class devices feature an integrated LDO which is intended to
supply the digital core for the device. Provide a driver offering
minimal control of this regulator.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>