[ Upstream commit 1a5caec7f8 ]
When adding devm_regulator_bulk_get_const() I missed adding a stub for
when CONFIG_REGULATOR is not enabled. Under certain conditions (like
randconfig testing) this can cause the compiler to reports errors
like:
error: implicit declaration of function 'devm_regulator_bulk_get_const';
did you mean 'devm_regulator_bulk_get_enable'?
Add the stub.
Fixes: 1de452a0ed ("regulator: core: Allow drivers to define their init data as const")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202408301813.TesFuSbh-lkp@intel.com/
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patch.msgid.link/20240830073511.1.Ib733229a8a19fad8179213c05e1af01b51e42328@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmZu0U0ACgkQONu9yGCS
aT4c2Q//SGn9+yEUml1/7nQUTND434ly4JPMdrR1jjJSKwxAsgzOYKCoUpzpXim8
7mdKz7q1cXx/l+tfJgEDdJ8JzVS6ipJWAwF4vE+18zWZjEax/M3dgluZUUswXKYg
Da76wSaNkfGiIewu8HV90LKAKaQoCR4ypyWG8CqDZkCnGJORUJA09GNDrKFhOodT
f0TzjIvPw8E3rU2+HZfPmxUI0XQEzfVPWb5DK+0F7hcHw4ETcij7y0AInBkQ5bNt
tFRCc462nT23e3jXJECWMbSXdRF57LlT8G9626Om0iS+TY7YD6PPNa7/bdqVHzcw
hDmKE+xONslwvuzkYn2R9u+nc/dw/hJ8QI5j9QohbJCcXjcv8N3QeXoiLPjiDxxv
1JVVi6emyKvKx26kjY/m0ZTZ/QWWwQlj/+R8Or/yIMMYZvPwyBUX3I8cZIQhyAg4
n/fc2tFqmax0K6e9YOXj3sa+OlXx02DAC8oVToNrSS7HT5uhtoKT4vU1d+et2alo
dFJAhklt27k+eV+Ayxo+RUaxUVggM0MAB67S7XUR0kylP2BeL2l9wMKVzZz2V5T4
O9PHY1RpD8OGk7aZvlbZYIis7LBqVTXcaEB4l5QtSYM4RMON4BYb5QLEc0jYywzV
U7GMNiKhhuwEHjiPD0cIXyeWeQzTlH9os5lhW8moVY9mtthGlr0=
=zdH0
-----END PGP SIGNATURE-----
Merge tag 'v6.6.34' into lf-6.6.y
This is the 6.6.34 stable release
* tag 'v6.6.34': (2530 commits)
Linux 6.6.34
smp: Provide 'setup_max_cpus' definition on UP too
selftests: net: more strict check in net_helper
...
Signed-off-by: Jason Liu <jason.hui.liu@nxp.com>
Conflicts:
arch/arm64/boot/dts/freescale/imx8-ss-conn.dtsi
drivers/net/ethernet/freescale/fec_ptp.c
drivers/pmdomain/imx/imx8mp-blk-ctrl.c
drivers/usb/dwc3/host.c
tools/perf/util/pmu.c
[ Upstream commit f4f4276f98 ]
Some PMICs treat the vsel_reg same as apply-bit. Eg, when voltage range
is changed, the new voltage setting is not taking effect until the vsel
register is written.
Add a flag 'range_applied_by_vsel' to the regulator desc to indicate this
behaviour and to force the vsel value to be written to hardware if range
was changed, even if the old selector was same as the new one.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://msgid.link/r/ZktCpcGZdgHWuN_L@fedora
Signed-off-by: Mark Brown <broonie@kernel.org>
Stable-dep-of: 1ace99d7c7 ("regulator: tps6287x: Force writing VSEL bit")
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit ff33132605 ]
The devm_regulator_get_enable_optional() should be a 'call and forget'
API, meaning, when it is used to enable the regulators, the API does not
provide a handle to do any further control of the regulators. It gives
no real benefit to return an error from the stub if CONFIG_REGULATOR is
not set.
On the contrary, returning an error is causing problems to drivers when
hardware is such it works out just fine with no regulator control.
Returning an error forces drivers to specifically handle the case where
CONFIG_REGULATOR is not set, making the mere existence of the stub
questionalble.
Change the stub implementation for the
devm_regulator_get_enable_optional() to return Ok so drivers do not
separately handle the case where the CONFIG_REGULATOR is not set.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Fixes: da279e6965 ("regulator: Add devm helpers for get and enable")
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/ZiedtOE00Zozd3XO@fedora
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 96e20adc43 ]
The devm_regulator_get_enable() should be a 'call and forget' API,
meaning, when it is used to enable the regulators, the API does not
provide a handle to do any further control of the regulators. It gives
no real benefit to return an error from the stub if CONFIG_REGULATOR is
not set.
On the contrary, returning and error is causing problems to drivers when
hardware is such it works out just fine with no regulator control.
Returning an error forces drivers to specifically handle the case where
CONFIG_REGULATOR is not set, making the mere existence of the stub
questionalble. Furthermore, the stub of the regulator_enable() seems to
be returning Ok.
Change the stub implementation for the devm_regulator_get_enable() to
return Ok so drivers do not separately handle the case where the
CONFIG_REGULATOR is not set.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reported-by: Aleksander Mazur <deweloper@wp.pl>
Suggested-by: Guenter Roeck <linux@roeck-us.net>
Fixes: da279e6965 ("regulator: Add devm helpers for get and enable")
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/ZiYF6d1V1vSPcsJS@drtxq0yyyyyyyyyyyyyby-3.rev.dnainternet.fi
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
The new pmic trimed BUCK1. So need to modify the range.
The default value of Toff_Deb is used to distinguish the old and new pmic.
Reviewed-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Right now the regulator helpers expect raw register values for the range
selectors. This is different from the voltage selectors, which are
normalized as bitfield values. This leads to a bit of confusion. Also,
raw values are harder to copy from datasheets or match up with them,
as datasheets will typically have bitfield values.
Make the helpers expect bitfield values, and convert existing users. The
field in regulator_desc is renamed to |linear_range_selectors_bitfield|.
This is intended to cause drivers added in the same merge window and
out-of-tree drivers using the incorrect variable and values to break,
preventing incorrect values being used on actual hardware and potentially
producing magic smoke.
Also include bitops.h explicitly for ffs(), and reorder the header include
statements. While at it, also replace module.h with export.h, since the
only use is EXPORT_SYMBOL_GPL.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230714081408.274567-1-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This release is almost all drivers, there's some small improvements in
the core but otherwise everything is updates to drivers, mostly the
addition of new ones.
There's also a bunch of changes pulled in from the MFD subsystem as
dependencies, Rockchip and TI core MFD code that the regulator drivers
depend on.
I've also yet again managed to put a SPI commit in the regulator tree, I
don't know what it is about those two trees (this for spi-geni-qcom).
- Support for Renesas RAA215300, Rockchip RK808, Texas Instruments
TPS6594 and TPS6287x, and X-Powers AXP15060 and AXP313a
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmSZkRUACgkQJNaLcl1U
h9A0bAf+IM6F/vTF7R/2NTlR3M/Z7HGinxK1oit6LuZfKnveaRRCEWvBVoZzZpjs
CzdWTPBWA2jyETzEqmX7gxYnxf2aaLieLEpKRZSh3uQd5OKmrizQDs5/OdaVUViK
/ytmqd/IFgFfwaI+az38CQlTf+dDyuJDB0OwlkEkoaxWjeiAh6INBh6xO9aKczoW
lFd0tOVQt1EcBKdB4tBJLTFIWWsG66xy9NZ018FrcA+bCmQVBvkbqcahayI5Q6Kw
m5H7cZuFbKV51AlyYMF/C4Lwhy1mOT166eRmSrgxBXCsqhpFeHYkJQkmumNd3gkQ
oSQPTZHqSblJA7Utw09mlT6r/xqL0Q==
=/f85
-----END PGP SIGNATURE-----
Merge tag 'regulator-v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates from Mark Brown:
"This release is almost all drivers, there's some small improvements in
the core but otherwise everything is updates to drivers, mostly the
addition of new ones.
There's also a bunch of changes pulled in from the MFD subsystem as
dependencies, Rockchip and TI core MFD code that the regulator drivers
depend on.
I've also yet again managed to put a SPI commit in the regulator tree,
I don't know what it is about those two trees (this for
spi-geni-qcom).
Summary:
- Support for Renesas RAA215300, Rockchip RK808, Texas Instruments
TPS6594 and TPS6287x, and X-Powers AXP15060 and AXP313a"
* tag 'regulator-v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (43 commits)
regulator: Add Renesas PMIC RAA215300 driver
regulator: dt-bindings: Add Renesas RAA215300 PMIC bindings
regulator: ltc3676: Use maple tree register cache
regulator: ltc3589: Use maple tree register cache
regulator: helper: Document ramp_delay parameter of regulator_set_ramp_delay_regmap()
regulator: mt6358: Use linear voltage helpers for single range regulators
regulator: mt6358: Const-ify mt6358_regulator_info data structures
regulator: mt6358: Drop *_SSHUB regulators
regulator: mt6358: Merge VCN33_* regulators
regulator: dt-bindings: mt6358: Drop *_sshub regulators
regulator: dt-bindings: mt6358: Merge ldo_vcn33_* regulators
regulator: dt-bindings: pwm-regulator: Add missing type for "pwm-dutycycle-unit"
regulator: Switch two more i2c drivers back to use .probe()
spi: spi-geni-qcom: Do not do DMA map/unmap inside driver, use framework instead
soc: qcom: geni-se: Add interfaces geni_se_tx_init_dma() and geni_se_rx_init_dma()
regulator: tps6594-regulator: Add driver for TI TPS6594 regulators
regulator: axp20x: Add AXP15060 support
regulator: axp20x: Add support for AXP313a variant
dt-bindings: pfuze100.yaml: Add an entry for interrupts
regulator: stm32-pwr: Fix regulator disabling
...
L3_OUT and L4_OUT Bit fields range from Bit 0:4 and thus the
mask should be 0x1F instead of 0x0F.
Fixes: 0935ff5f1f ("regulator: pca9450: add pca9450 pmic driver")
Signed-off-by: Teresa Remmet <t.remmet@phytec.de>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Link: https://lore.kernel.org/r/20230614125240.3946519-1-t.remmet@phytec.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The *_SSHUB regulators are actually alternate configuration interfaces
for their non *_SSHUB counterparts. They are not separate regulator
outputs. These registers are intended for the companion processor to
use to configure the power rails while the main processor is sleeping.
They are not intended for the main operating system to use.
Since they are not real outputs they shouldn't be modeled separately.
Remove them. Luckily no device tree actually uses them.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Link: https://lore.kernel.org/r/20230609083009.2822259-5-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The VCN33_BT and VCN33_WIFI regulators are actually the same regulator,
having the same voltage setting and output pin. There are simply two
enable bits that are ORed together to enable the regulator.
Having two regulators representing the same output pin is misleading
from a design matching standpoint, and also error-prone in driver
implementations. If consumers try to set different voltages on either
regulator, the one set later would override the one set before. There
are ways around this, such as chaining them together and having the
downstream one act as a switch. But given there's only one output pin,
such a workaround doesn't match reality.
Remove the VCN33_WIFI regulator. During the probe phase, have the driver
sync the enable status of VCN33_WIFI to VCN33_BT. Also drop the suffix
so that the regulator name matches the pin name in the datasheet.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230609083009.2822259-4-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Expose and document the table lookup logic used by
regulator_set_ramp_delay_regmap, so that it can be
reused for devices that cannot be configured via
regulator_set_ramp_delay_regmap.
Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock64, Quartz64 Model A + B
Tested-by: Vincent Legoll <vincent.legoll@gmail.com> # Pine64 QuartzPro64
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20230504173618.142075-11-sebastian.reichel@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Following by the below discussion, there's the potential UAF issue
between regulator and mfd.
https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/
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 <yangyingliang@huawei.com>
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1670311341-32664-1-git-send-email-u0084500@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add regulator driver for the MT6357 PMIC.
Signed-off-by: Fabien Parent <fparent@baylibre.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
Link: https://lore.kernel.org/r/20221005-mt6357-support-v7-7-477e60126749@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Corentin Labbe <clabbe@baylibre.com>:
This adds a new regulator_bulk_get_all() which grab all supplies
properties in a DT node, for use in implementing generic handling
for things like MDIO PHYs where the physical standardisation of
the bus does not extend to power supplies.
It work exactly like regulator_bulk_get() but instead of working on a
provided list of names, it seek all consumers properties matching
xxx-supply.
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Link: https://lore.kernel.org/r/20221115073603.3425396-2-clabbe@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In addition to adding some fairly simple OF support code, we make some
slight adjustments to the userspace-consumer driver to properly
support use with regulator-output hardware:
- We now do an exclusive get of the supply regulators so as to
prevent regulator_init_complete_work from automatically disabling
them.
- Instead of assuming that the supply is initially disabled, we now
query its state to determine the initial value of drvdata->enabled.
Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Link: https://lore.kernel.org/r/20221031233704.22575-4-zev@bewilderbeest.net
Signed-off-by: Mark Brown <broonie@kernel.org>
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 <zev@bewilderbeest.net>
Link: https://lore.kernel.org/r/20221031233704.22575-2-zev@bewilderbeest.net
Signed-off-by: Mark Brown <broonie@kernel.org>
This is simillar as fixed-regulator.
Used to extract regulator parent from the device tree.
Without that property used, the parent regulator can be shut down (if not an always on).
Thus leading to inappropriate behavior:
On am62-SP-SK this fix is required to avoid tps65219 ldo1 (SDMMC rail) to be shut down after boot completion.
Signed-off-by: Jerome Neanne <jneanne@baylibre.com>
Link: https://lore.kernel.org/r/20220929132526.29427-2-jneanne@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>:
In an effort to give some love to the apparently forgotten MT6795 SoC,
I am upstreaming more components that are necessary to support platforms
powered by this one apart from a simple boot to serial console.
This series adds support for the regulators found in MT6331 and MT6332
main/companion PMICs.
Adding support to each driver in each subsystem is done in different
patch series as to avoid spamming uninteresting patches to maintainers.
Tested on a MT6795 Sony Xperia M5 (codename "Holly") smartphone.
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 <mazziesaccount@gmail.com>
Link: https://lore.kernel.org/r/ed7b8841193bb9749d426f3cb3b199c9460794cd.1660292316.git.mazziesaccount@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Douglas Anderson <dianders@chromium.org>:
The main goal of this series is to make a small dent in cleaning up
the way we deal with regulator loads. The idea is to add some extra
functionality to the regulator "bulk" API so that consumers can
specify the load using that.
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 <dianders@chromium.org>
Link: https://lore.kernel.org/r/20220726103631.v2.6.I38fc508a73135a5c1b873851f3553ff2a3a625f5@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
There are a number of drivers that follow a pattern that looks like
this:
1. Use the regulator bulk API to get a bunch of regulators.
2. Set the load on each of the regulators to use whenever the
regulators are enabled.
Let's make this easier by just allowing the drivers to pass the load
in.
As part of this change we need to move the error printing in
regulator_bulk_get() around; let's switch to the new dev_err_probe()
to simplify it.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20220726103631.v2.4.Ie85f68215ada39f502a96dcb8a1f3ad977e3f68a@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
document n_ramp_values field at struct regulator_desc, in order
to solve this warning:
include/linux/regulator/driver.h:434: warning: Function parameter or member 'n_ramp_values' not described in 'regulator_desc'
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Link: https://lore.kernel.org/r/15efc16e878aa327aa2769023bcdf959a795f41d.1656409369.git.mchehab@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Make the I2C Level Translator included in PCA9450 configurable from
devicetree. The reset state is off. By setting nxp,i2c-lt-enable, the
I2C Level Translator will be enabled while in STANDBY or RUN state.
Signed-off-by: Per-Daniel Olsson <perdo@axis.com>
Signed-off-by: Rickard x Andersson <rickaran@axis.com>
Link: https://lore.kernel.org/r/20220429072211.24957-2-rickaran@axis.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The MT6366 is a regulator found on boards based on MediaTek MT8186 and
probably other SoCs. It is a so called pmic and connects as a slave to
SoC using SPI, wrapped inside the pmic-wrapper.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Johnson Wang <johnson.wang@mediatek.com>
Link: https://lore.kernel.org/r/20220401080212.27383-2-johnson.wang@mediatek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This has been a fairly quiet release for the regulator API, the main
thing has been the addition of helpers for interrupt handling from Matti
Vaittinen. We do also have support for quite a few new devices and
included in here is a platform/x86 patch series for Intel INT3472 ACPI
devices which this is a dependency for the TPS68470 driver.
- Helpers for trivial interrupt notifications, making it easier for
drivers to handle error interrupts.
- Support for Dialog DA914x, Maxim MAX2008x, Qualcomm PM8826, PMG1100,
and PM8450 and TI TPS68470
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmHcLP8ACgkQJNaLcl1U
h9CFYAf9FwoHGtNWL8zxcAXs9egQVDKY36KXJkjXOkI5dlWVVpkCPoX4JWqfocGx
lINFI1gLGPiwHx69EY45IQEIElltJYlaA53oBXEPxvNF98yAGqaHmlMxa32SeyVH
yTMQfoo0sEjF6l5ELlKyPy51Syda4vTMjVxPkPx0P7XS9EgyXIOXzDfosTTwr9RH
rEUGYuvDyITGEFMY3jyYnpAlvoGWMPnN4AwCb/alD1ZRpJXzGCMqGoRR7jgoi8KC
0IIuTOMGQY7V0LRe9zabHzZbDglVX52rmwGhZlDxbjMrdR4HCdv6homPEb/gJd7f
icqaxLnW+3hoT3501QuD5JVNO2U7Ag==
=htGo
-----END PGP SIGNATURE-----
Merge tag 'regulator-v5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates from Mark Brown:
"This has been a fairly quiet release for the regulator API, the main
thing has been the addition of helpers for interrupt handling from
Matti Vaittinen.
We do also have support for quite a few new devices.
Summary:
- Helpers for trivial interrupt notifications, making it easier for
drivers to handle error interrupts.
- Support for Dialog DA914x, Maxim MAX2008x, Qualcomm PM8826,
PMG1100, and PM8450 and TI TPS68470"
* tag 'regulator-v5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (30 commits)
regulator: Add MAX20086-MAX20089 driver
dt-bindings: regulators: Add bindings for Maxim MAX20086-MAX20089
regulator: qcom_smd: Align probe function with rpmh-regulator
regulator: remove redundant ret variable
regulator: qcom-labibb: OCP interrupts are not a failure while disabled
regulator: dt-bindings: samsung,s5m8767: Move fixed string BUCK9 to 'properties'
regulator: Introduce tps68470-regulator driver
drivers/regulator: remove redundant ret variable
regulator: fix bullet lists of regulator_ops comment
regulator: Fix type of regulator-coupled-max-spread property
regulator: maxim,max8973: Document interrupts property
regulator: qcom-rpmh: Add support for PM8450 regulators
regulator: qcom,rpmh: Add compatible for PM8450
regulator: da9121: Add DA914x binding info
regulator: da9121: Remove erroneous compatible from binding
regulator: da9121: Add DA914x support
regulator: da9121: Prevent current limit change when enabled
regulator: qcom-rpmh: Add PMG1110 regulators
dt-bindings: regulator: Add compatible for pmg1110
regulator: qcom_spmi: Add pm8226 regulators
...
Since 89a6a5e56c82("regulator: add property parsing and callbacks to set protection limits")
which introduced a warning:
Documentation/driver-api/regulator:166: ./include/linux/regulator/driver.h:96: WARNING: Unexpected indentation.
Documentation/driver-api/regulator:166: ./include/linux/regulator/driver.h:98: WARNING: Block quote ends without a blank line; unexpected unindent.
Let's fix them.
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
Link: https://lore.kernel.org/r/20211207123230.2262047-1-siyanteng@loongson.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Provide a generic map_event helper for regulators which have a notification
IRQ with single, well defined purpose. Eg, IRQ always indicates exactly one
event for exactly one regulator device. For such IRQs the mapping is
trivial.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/603b7ed1938013a00371c1e7ccc63dfb16982b87.1637736436.git.matti.vaittinen@fi.rohmeurope.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Help drivers avoid storing both supported notification and supported error
flags by supporting conversion from regulator error to notification.
This may help saving some bytes.
Add helper for finding the regulator notification corresponding to a
regulator error.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/eb1755ac0569ff07ffa466cf8912c6fd50e7c7c6.1637736436.git.matti.vaittinen@fi.rohmeurope.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The documentation of IRQ notification helper had still references to
first RFC implementation which called BUG() while trying to protect the
hardware. Behaviour was improved as calling the BUG() was not a proper
solution. Current implementation attempts to call poweroff if handling
of potentially damaging error notification fails. Update the
documentation to reflect the actual behaviour.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/0c9cc4bcf20c3da66fd5a85c97ee4288e5727538.1637233864.git.matti.vaittinen@fi.rohmeurope.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Removing all linux/gpio.h and linux/of_gpio.h dependencies and replacing
them with the gpiod interface.
Signed-off-by: Maíra Canal <maira.canal@usp.br>
Link: https://lore.kernel.org/r/YWxmL2baF5AdzyHv@fedora
Signed-off-by: Mark Brown <broonie@kernel.org>
After this driver was converted to gpiod, clang started warning:
vers/regulator/lp872x.c:689:57: error: implicit conversion from
enumeration type 'enum lp872x_dvs_state' to different enumeration type
'enum gpiod_flags' [-Werror,-Wenum-conversion]
dvs->gpio = devm_gpiod_get_optional(lp->dev, "ti,dvs", pinstate);
~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~~~
1 error generated.
lp872x_dvs_state was updated to have values from gpiod_flags but this is
not enough to avoid an implicit conversion warning from either GCC or
clang (although GCC enables this warning under -Wextra instead of -Wall
like clang so it is not seen under normal builds).
Eliminate lp872x_dvs_state in favor of using gpiod_flags everywhere so
that there is no more warning about an implicit conversion.
Fixes: 72bf80cf09 ("regulator: lp872x: replacing legacy gpio interface for gpiod")
Link: https://github.com/ClangBuiltLinux/linux/issues/1481
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20211019004335.193492-1-nathan@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Removing all linux/gpio.h and linux/of_gpio.h dependencies and replacing
them with the gpiod interface
Signed-off-by: Maíra Canal <maira.canal@usp.br>
Message-Id: <YWma2yTyuwS5XwhY@fedora>
Signed-off-by: Mark Brown <broonie@kernel.org>
The helper to send IRQ notification for regulator errors had still
old description mentioning calling BUG() as a last resort when
error status reading has kept failing for more times than a given
threshold.
The impementation calling BUG() did never end-up in-tree but was
replaced by hopefully more sophisticated handler trying to power-off
the system.
Fix the documentation to reflect actual behaviour.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/20210823075651.GA3717293@localhost.localdomain
Signed-off-by: Mark Brown <broonie@kernel.org>
These APIs aren't used anywhere and most-likely exist 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 these discourages any weird logic that could be created with
such an API functions.
Alexandru Ardelean (4):
regulator: devres: remove devm_regulator_unregister_notifier()
function
regulator: devres: remove devm_regulator_unregister() function
regulator: devres: remove
devm_regulator_bulk_unregister_supply_alias()
regulator: devres: unexport devm_regulator_unregister_supply_alias()
drivers/regulator/devres.c | 105 +----------------------------
include/linux/regulator/consumer.h | 23 -------
include/linux/regulator/driver.h | 1 -
3 files changed, 2 insertions(+), 127 deletions(-)
--
2.31.1
