Handle under-voltage events for crucial regulators to maintain system
stability and avoid issues during power drops.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20231026144824.4065145-3-o.rempel@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Utilize the integrated 10-bit ADC in Max5970/Max5978 to enable voltage
and current monitoring. This feature is seamlessly integrated through
the hwmon subsystem.
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20231027152830.1269895-1-naresh.solanki@9elements.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The type of the smps4 regulator from pm8550ve is actually FTSMPS525
medium voltage. So fix it accordingly.
Fixes: e6e3776d68 ("regulator: qcom-rpmh: Add support for PM8550 regulators")
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20231024134626.2364426-1-abel.vesa@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support from RPMH regulators found in PMC8380 for SC8380XP platform.
Signed-off-by: Rajendra Nayak <quic_rjendra@quicinc.com>
Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20231025135550.13162-3-quic_sibis@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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 <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20231025084614.3092295-6-o.rempel@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Use preferred device_get_match_data() instead of of_match_device() to
get the driver match data. With this, adjust the includes to explicitly
include the correct headers.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20231017203442.2699322-1-robh@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Use preferred i2c_get_match_data() instead of of_match_device() to get
the driver match data. With this, adjust the includes to explicitly
include the correct headers.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20231017203429.2699039-1-robh@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
If probe is reached, we've already matched the device and in the case of
DT matching, the struct device_node pointer will be set. Therefore, there
is no need to call of_match_device() in probe.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20231017203507.2699826-1-robh@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct da9063_regulators.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: Support Opensource <support.opensource@diasemi.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230922175207.work.576-kees@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct da9062_regulators.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: Support Opensource <support.opensource@diasemi.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230922175330.work.066-kees@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The DT bindings for MT6366 regulator defines the supply names for the
PMIC.
Add support for them by adding .supply_name field settings for each
regulator. The buck regulators each have their own supply whose name
can be derived from the regulator name. The LDOs have shared supplies.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230928085537.3246669-12-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
When support for the MT6366 PMIC regulators was added, it was assumed
that it had the same functionality as MT6358. In reality there are
differences. A few regulators have different ranges, or were renamed
and repurposed, or removed altogether.
Add the 3 regulators that were missing from the original submission.
These are added for completeness. VSRAM_CORE is not used in existing
projects. VM18 and VMDDR feed DRAM related consumers, and are not used
in-kernel.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230928085537.3246669-11-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The VCN18 regulator on the MT6366 (only) actually has a wide
configurable range of voltages, even though its name suggests a fixed
output voltage.
Convert it from a fixed LDO to a configurable LDO. Its range of settings
is the same as the VM18 regulator, which is missing and will be added in
a subsequent patch.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230928085537.3246669-10-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The new MT6366 binding does away with the type prefix ("buck_", "ldo_")
in the regulator node names. This better matches the PMIC pin names.
Remaining underscores in names are also replaced with hyphens.
Drop the type prefixes and replace remaining underscores to match the
MT6366 binding.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230928085537.3246669-9-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The DT bindings for MT6358 regulator now defines the supply names for the
PMIC.
Add support for them by adding .supply_name field settings for each
regulator.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230928085537.3246669-8-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The (undocumented) possible values for the buck operating modes on the
MT6358 are the same as those on the MT6397, both for the device tree
bindings and the actual hardware register values.
Reuse the macros for the MT6397 PMIC in the MT6358 regulator driver by
including the mt6397-regulator.h binding header and replacing the
existing macros. This aligns it with other PMIC.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230928085537.3246669-7-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the necessary definitions for the PMA8084 PMIC to the
qcom_spmi-regulator driver to allow reading the actual voltages applied
to the hardware at runtime. This is mainly intended for debugging since
the regulators are usually controlled through the RPM firmware (via
qcom_smd-regulator).
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230912-spmi-pm8909-v1-6-ba4b3bfaf87d@gerhold.net
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the necessary definitions for the PM8019 PMIC to the
qcom_spmi-regulator driver to allow reading the actual voltages applied
to the hardware at runtime. This is mainly intended for debugging since
the regulators are usually controlled through the RPM firmware (via
qcom_smd-regulator).
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230912-spmi-pm8909-v1-4-ba4b3bfaf87d@gerhold.net
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the necessary definitions for the PM8909 PMIC to the
qcom_spmi-regulator driver to allow reading the actual voltages applied
to the hardware at runtime. This is mainly intended for debugging since
the regulators are usually controlled through the RPM firmware (via
qcom_smd-regulator).
Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
Link: https://lore.kernel.org/r/20230912-spmi-pm8909-v1-2-ba4b3bfaf87d@gerhold.net
Signed-off-by: Mark Brown <broonie@kernel.org>
When fixing a memory leak in commit d3c731564e ("regulator: plug
of_node leak in regulator_register()'s error path") it moved the
device_initialize() call earlier, but did not move the `dev->class`
initialization. The bug was spotted and fixed by reverting part of
the commit (in commit 5f4b204b6b "regulator: core: fix kobject
release warning and memory leak in regulator_register()") but
introducing a different bug: now early error paths use `kfree(dev)`
instead of `put_device()` for an already initialized `struct device`.
Move the missing assignments to just after `device_initialize()`.
Fixes: d3c731564e ("regulator: plug of_node leak in regulator_register()'s error path")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/b5b19cb458c40c9d02f3d5a7bd1ba7d97ba17279.1695077303.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Chen-Yu Tsai <wenst@chromium.org>:
Hi,
This is v3 of the remainder of the MT6358 regulator driver cleanup
and improvement series. v1 can be found here [1]; v2 is here [2].
Changes since v2:
- Merged patches dropped
- Fixed up pickable linear ranges' selector values
- Collected tags
- Patch adding missing regulator definitions squashed into patch using
the definitions; recommended by Krzysztof on my MT6366 series.
- Remaining dts patch split out to be sent separately
Changes since v1:
- Merged patches dropped
- Added patch to move VCN33 regulator status sync after ID check
- Added patch to fix VCN33 sync fail error message
- Added patch to add missing register definitions
Various discrepancies were found while preparing to upstream MT8186
device trees, which utilize the MT6366 PMIC, that is also covered by
this driver.
Patches 1~3 should go through the regulator tree, and patch 4 through
the soc/mediatek tree.
** Note: patch 2 needs an ack from Lee for the mfd header change.
This v3 series can be seen as two parts. v1 had three parts, but one
part was fully merged, and then v2 gained another cleanup. v3 drops
the "fixing bogus regulators" part: driver changes are fully merged
and device tree change will be sent separately.
Part 1 - Robust chip ID checking (patch 1)
Angelo suggested making the driver fail to probe if an unexpected chip
ID was found. Patch 1 implements this.
Part 2 - Output voltage fine tuning support (patches 2, 3)
Many of the LDOs on these PMIC support an extra level of output voltage
fine tuning. Most default to no offset, but a couple have a non-zero
offset by default. Previously this was unaccounted for in the driver and
device tree constraints. On the outputs with non-zero offset, this ends
up becoming a discrepancy between the device tree and actual hardware.
These two patches adds support for this second level of tuning, modeled
as bunch of linear ranges. While it's unlikely we need this level of
control, it's nice to be able to read back the accurate hardware
settings.
Please have a look.
Thanks
ChenYu
[1] https://lore.kernel.org/linux-arm-kernel/20230609083009.2822259-1-wenst@chromium.org/
[2] https://lore.kernel.org/linux-mediatek/20230721082903.2038975-1-wenst@chromium.org/
Chen-Yu Tsai (3):
regulator: mt6358: Fail probe on unknown chip ID
regulator: mt6358: Add output voltage fine tuning to fixed regulators
regulator: mt6358: Add output voltage fine tuning to variable LDOs
drivers/regulator/mt6358-regulator.c | 304 ++++++++++++---------------
include/linux/mfd/mt6358/registers.h | 6 +
2 files changed, 144 insertions(+), 166 deletions(-)
--
2.42.0.283.g2d96d420d3-goog
Some of the LDO regulators in the MT6358/MT6366 have sparsely populated
voltage tables, supported by custom get/set operators. While it works,
it requires more code and an extra field to store the lookup table.
These LDOs also have fine voltage calibration settings that can slightly
boost the output voltage from 0 mV to 100 mV, in 10 mV increments.
These combined could be modeled as a pickable set of linear ranges. The
coarse voltage setting is modeled as the range selector, while each
range has 11 selectors, starting from the range's base voltage, up to
+100 mV, in 10mV increments.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230913082919.1631287-4-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The "fixed" LDO regulators found on the MT6358 and MT6366 PMICs have
either no voltage selection register, or only one valid setting.
However these do have a fine voltage calibration setting that can
slightly boost the output voltage from 0 mV to 100 mV, in 10 mV
increments.
Add support for this by changing these into linear range regulators.
Some register definitions that are missing are also added.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230913082919.1631287-3-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The MT6358 and MT6366 PMICs, and likely many others from MediaTek, have
a chip ID register, making the chip semi-discoverable.
The driver currently supports two PMICs and expects to be probed on one
or the other. It does not account for incorrect mfd driver entries or
device trees. While these should not happen, if they do, it could be
catastrophic for the device. The driver should be sure the hardware is
what it expects.
Make the driver fail to probe if the chip ID presented is not a known
one.
Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Fixes: f0e3c6261a ("regulator: mt6366: Add support for MT6366 regulator")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230913082919.1631287-2-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct mc13xxx_regulator_priv.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20230922175402.work.819-kees@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The buck and linear range LDO (VSRAM_*) regulators share one set of ops.
This set includes support for get/set mode. However this only makes
sense for buck regulators, not LDOs. The callbacks were not checking
whether the register offset and/or mask for mode setting was valid or
not. This ends up making the kernel report "normal" mode operation for
the LDOs.
Create a new set of ops without the get/set mode callbacks for the
linear range LDO regulators.
Fixes: f67ff1bd58 ("regulator: mt6358: Add support for MT6358 regulator")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230920085336.136238-1-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The RK808 is already using the proper <linux/gpio/consumer.h>
header and includes the legacy headers <linux/gpio.h> and
<linux/of_gpio.h> for no reason, drop the includes.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230911-descriptors-regulator-v2-1-ce978c52c557@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Biju Das <biju.das.jz@bp.renesas.com>:
This patch series aims to add match data improvements for pv880x0
regulator driver.
These patches are only compile tested.
Use the correct field to fix wrong voltage range selection on regulators
such as tps6287x since the blamed commit.
Fixes: 269cb04b60 ("regulator: Use bitfield values for range selectors")
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Link: https://lore.kernel.org/r/20230911-regulator-voltage-sel-v1-1-886eb1ade8d8@axis.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Make similar OF and ID table to extend support for ID match using
i2c_match_data(). Currently it works only for OF match tables as the
driver_data is wrong for ID match.
While at it, remove trailing comma in the terminator entry for OF/ID
table and drop a space from terminator entry for ID table.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20230903160301.79111-1-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Make similar OF and ID table to extend support for ID match using
i2c_match_data(). Currently it works only for OF match tables as the
driver_data is wrong for ID match.
While at it, drop blank lines before MODULE_DEVICE_TABLE* and remove
trailing comma in the terminator entry for OF/ID table.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20230903154257.70800-1-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Make similar OF and ID table to extend support for ID match using
i2c_match_data(). Currently it works only for OF match tables as the
driver_data is wrong for ID match.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20230826173841.91807-1-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Convert enum->pointer for data in the match tables, so that the hw
differences can be stored in pointer and there by simpily the code.
Add struct ltc3589_info for hw differences between the devices and replace
ltc3589_variant->ltc3589_info for data in the match table. Simplify the
probe() by replacing of_device_get_match_data() and ID lookup for
retrieving data by i2c_get_match_data(). Drop enum ltc3589_variant and
variant from struct ltc3589_info as there are no users.
While at it, dropped trailing comma in the terminator entries for ID
table.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20230828162830.97881-1-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Make similar OF and ID table to extend support for ID match using
i2c_match_data(). Currently it works only for OF match tables as the
driver_data is wrong for ID match.
While at it, drop trailing comma in the terminator entry from ID
table.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20230828165447.106058-1-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Simplify probe() by replacing of_device_get_match_data() and ID lookup for
retrieving match data by i2c_get_match_data().
While at it, use dev_fwnode() API instead of 'client->dev.of_node'.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20230828164746.102992-1-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace pv88080_types->pv88080_compatible_regmap in OF/ID tables and
simplify the probe() by replacing of_match_node() and ID lookup for
retrieving match data by i2c_get_match_data(). After this there is
no user of enum pv88080_types. So drop it.
While at it, move OF table near to the user.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20230903164832.83077-3-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Drop of_match_ptr() from pv88080_regulator_driver and get rid of ugly
CONFIG_OF ifdeffery. This slightly increases the size of pv88080_dt_ids
on non-OF system and shouldn't be an issue.
Add mod_devicetable.h include.
While at it, remove trailing comma in the terminator entry for OF/ID
table.
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20230903164832.83077-2-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
A couple of fixes that came in during the merge window, both driver
specific - one for a bug that came up in testing, one for a bug due to a
misreading of the datasheet.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmT5wtcACgkQJNaLcl1U
h9D42Qf+LB9UYFJKAXPyLkpQYGHKbSaqz6hIMFWjmpsVjvuahI63wVRv/GoPZDIU
B1Zy8mrC4t37BK/CmjlwvxVFPuY+DaYTTBjjnSEnfrDsQZ+PgfIRmfqzxp/q6TYr
cpDOg/HrLkvfzNoTVtnUDz4Kn1l66OAMWXlwZ/AZEW8uD/JY172H7tBfjqDdzDvc
NCxKW0FO/pX07kc1IFaPl6UvZRqJLQUkYl7dKFl7PrG6Lzh1+FKQSUmtZY33Ndgd
LqFux/mc3jsV5E6Y0F899Lf1890VxzYHpbwT1QrHdaXhbqoACrQoaFfLfvd5YQLY
K9ncwzj8hNM87t0LYLH09lSsH5L2Xw==
=UyE6
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v6.6-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"A couple of fixes that came in during the merge window, both driver
specific - one for a bug that came up in testing, one for a bug due
to a misreading of the datasheet"
* tag 'regulator-fix-v6.6-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: tps6594-regulator: Fix random kernel crash
regulator: tps6287x: Fix n_voltages
Random kernel crash detected in TI CICD when regulator driver is added.
This is root caused to irq index increment being done twice causing
irq_data being allocated outside of the range.
- Rework tps6594_request_reg_irqs with correct index increment
- Adjust irq_data kmalloc size to the exact size needed for the device
This has been reported on TI mainline. No public bug report associated.
Reported-by: Udit Kumar <u-kumar1@ti.com>
Fixes: f17ccc5deb ("regulator: tps6594-regulator: Add driver for TI TPS6594 regulators")
Signed-off-by: Jerome Neanne <jneanne@baylibre.com>
Link: https://lore.kernel.org/r/20230828-tps6594_random_boot_crash_fix-v1-1-f29cbf9ddb37@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There are 256 possible voltage settings for each range, not 256 possible
voltage settings in total.
Fixes: 15a1cd245d ("regulator: tps6287x: Fix missing .n_voltages setting")
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com
Link: https://lore.kernel.org/r/20230829-tps-voltages-v1-1-7ba4f958a194@axis.com
Signed-off-by: Mark Brown <broonie@kernel.org
Other tha new device support and some minor fixes this has been a really
quiet release, the only notable things are the new drivers. There's a
couple of MFDs among the new devices so the generic parts are pulled in:
- Support for Analog Devices MAX77831/57/59, Awinc AW37503, Qualcom
PMX75 and RFGEN, RealTek RT5733, RichTek RTQ2208 and Texas
Instruments TPS65086.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmTp6U4ACgkQJNaLcl1U
h9Cu4gf/RZZirDVcISmKrIYn95Dc838pHFe3tIK9Ehbwms/pzBWBzT0Eiy36g4Vd
1pUB6YJKJZIKLOfFAjmudGtT9C3Yrui+3cR3dPtxN793ixfCkT2RVdeaNJDCJ6xo
cPpAekMroDpMSczDvsTaqJzCXb4y+rjsAQ201w+WhegkSLk/yMsW7Y+a6wpaMjwt
qGD/+EDk/54aogPhrGvKq7uLwCgDo2A6HrU2rIIMHYnZuPaSjsPGcd0fZahlP7Mk
1b6/SSJ+KvN0XSAgBz4yFixECb0OG9p5ukpV17hwDAPBbNqLRp+O/o3LFLq+nsoY
yG3RpJQM6r3Bw3KqdxWF/e5sUNkEsQ==
=ZB93
-----END PGP SIGNATURE-----
Merge tag 'regulator-v6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates from Mark Brown:
"Other than new device support and some minor fixes this has been a
really quiet release, the only notable things are the new drivers.
There's a couple of MFDs among the new devices so the generic parts
are pulled in:
- Support for Analog Devices MAX77831/57/59, Awinc AW37503, Qualcom
PMX75 and RFGEN, RealTek RT5733, RichTek RTQ2208 and Texas
Instruments TPS65086"
* tag 'regulator-v6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (68 commits)
regulator: userspace-consumer: Drop event support for this cycle
regulator: aw37503: Switch back to use struct i2c_driver's .probe()
dt-bindings: regulator: qcom,rpmh-regulator: allow i, j, l, m & n as RPMh resource name suffix
regulator: dt-bindings: Add Awinic AW37503
regulator: aw37503: add regulator driver for Awinic AW37503
regulator: tps65086: Select dedicated regulator config for chip variant
mfd: tps65086: Read DEVICE ID register 1 from device
regulator: raa215300: Update help description
regulator: raa215300: Add missing blank space
regulator: raa215300: Change rate from 32000->32768
regulator: db8500-prcmu: Remove unused declaration power_state_active_is_enabled()
regulator: raa215300: Add const definition
regulator: raa215300: Fix resource leak in case of error
regulator: rtq2208: Switch back to use struct i2c_driver's .probe()
regulator: lp872x: Fix Wvoid-pointer-to-enum-cast warning
regulator: max77857: Fix Wvoid-pointer-to-enum-cast warning
regulator: ltc3589: Fix Wvoid-pointer-to-enum-cast warning
regulator: qcom_rpm-regulator: Use devm_kmemdup to replace devm_kmalloc + memcpy
regulator: tps6286x-regulator: Remove redundant of_match_ptr() macros
regulator: pfuze100-regulator: Remove redundant of_match_ptr() macro
...
Drop commit 22475bcc20 ("regulator: userspace-consumer: Add regulator
event support") since Zev Weiss points out that it leaks the constants
we use for notifications out as ABI which isn't ideal, we should have
something more abstracted there. There's a definite need for this
feature but it needs some more work on the interface.
Signed-off-by: Mark Brown <broonie@kernel.org
Link: https://lore.kernel.org/r/20230824-regulator-remove-status-sysfs-v1-1-554956e8c1ca@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org
struct i2c_driver::probe_new is about to go away. Switch the driver to
use the probe callback with the same prototype.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de
Link: https://lore.kernel.org/r/20230824195617.8888-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org
Merge series from like@awinic.com:
Add regulator driver for the device Awinic AW37503 which is
single inductor - dual output power supply device. AW37503
device is designed to support general positive/negative
driven applications like TFT display panels.
Add regulator driver for the device Awinic AW37503 which is single
inductor - dual output power supply device. AW37503 device is
designed to support general positive/negative driven applications
like TFT display panels.
AW37503 regulator driver supports to enable/disable and set voltage
on its output.
Signed-off-by: Alec Li <like@awinic.com>
Link: https://lore.kernel.org/r/20230821035355.1269976-2-like@awinic.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some configurations differ between chip variants, e,g. the register
to control the on of state of LDOA1 and SWB2. Thus, it is necessary
to choose the correct configuration for a dedicated device.
If the wrong configuration was used, the LDOA1 output that was
disabled by the bootloader was enabled in Kernel again.
Each chip variant gets its dedicated configuration selected by
the chip ID previously collected from MFD probe function.
The VTT enum value (tps65086_regulators) is shifted because not all
chip variants have a separate SWB2 switch. Sometimes they are merged.
So the configuration possibilities differ, thus the regulator
configuration arrays have a different length.
Signed-off-by: Andre Werner <andre.werner@systec-electronic.com>
Link: https://lore.kernel.org/r/20230818083721.29790-5-andre.werner@systec-electronic.com
Signed-off-by: Mark Brown <broonie@kernel.org>
