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>
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.
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.
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>
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>
