#
8f3cbcd6 |
|
06-Dec-2022 |
ChiYuan Huang <cy_huang@richtek.com> |
regulator: core: Use different devices for resource allocation and DT lookup 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>
|
#
fd184506 |
|
31-Oct-2022 |
Zev Weiss <zev@bewilderbeest.net> |
regulator: devres: Add devm_regulator_bulk_get_exclusive() 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>
|
#
da279e69 |
|
12-Aug-2022 |
Matti Vaittinen <mazziesaccount@gmail.com> |
regulator: Add devm helpers for get and enable 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>
|
#
1de452a0 |
|
26-Jul-2022 |
Douglas Anderson <dianders@chromium.org> |
regulator: core: Allow drivers to define their init data as const 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>
|
#
4d9f4d1d |
|
25-Jun-2021 |
Alexandru Ardelean <aardelean@deviqon.com> |
regulator: devres: unexport devm_regulator_unregister_supply_alias() This API hook isn't used anywhere outside of the regulator devres code. This function is needed for the devm_regulator_bulk_register_supply_alias() function on the error path, to cleanup any previously registered supply aliases. This change makes the devm_regulator_unregister_supply_alias() local to the regulator core framework, to avoid it being used in any weird logic. It's also removing the doc-string for devm_regulator_unregister_supply_alias(), since it doesn't need to be documented anymore, as no other external consumer should use it. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210625122324.327585-5-aardelean@deviqon.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
eed43b96 |
|
25-Jun-2021 |
Alexandru Ardelean <aardelean@deviqon.com> |
regulator: devres: remove devm_regulator_bulk_unregister_supply_alias() This API hook isn't used anywhere and most-likely exists 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 this also discourages any weird logic that could be created with such an API function. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210625122324.327585-4-aardelean@deviqon.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
4ff75a29 |
|
25-Jun-2021 |
Alexandru Ardelean <aardelean@deviqon.com> |
regulator: devres: remove devm_regulator_unregister() function This API hook isn't used anywhere and most-likely exists 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 this also discourages any weird logic that could be created with such an API function. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210625122324.327585-3-aardelean@deviqon.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
7111c6d1 |
|
02-Jun-2021 |
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> |
regulator: IRQ based event/error notification helpers Provide helper function for IC's implementing regulator notifications when an IRQ fires. The helper also works for IRQs which can not be acked. Helper can be set to disable the IRQ at handler and then re-enabling it on delayed work later. The helper also adds regulator_get_error_flags() errors in cache for the duration of IRQ disabling. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/ebdf86d8c22b924667ec2385330e30fcbfac0119.1622628334.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
a7c15187 |
|
08-Jul-2020 |
Lee Jones <lee.jones@linaro.org> |
regulator: devres: Standardise on function documentation headers Line up descriptions, start description with a lower-case character and omit old definitions such as quoting the old argument "consumer". Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20200708124832.3441649-4-lee.jones@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
9565cccd |
|
08-Jul-2020 |
Lee Jones <lee.jones@linaro.org> |
regulator: devres: Fix issues with kerneldoc headers Provide descriptions for some missing function args and rename others to match the names used. Fixes the following W=1 warning(s): drivers/regulator/devres.c:187: warning: Function parameter or member 'dev' not described in 'devm_regulator_register' drivers/regulator/devres.c:226: warning: Function parameter or member 'dev' not described in 'devm_regulator_unregister' drivers/regulator/devres.c:226: warning: Function parameter or member 'rdev' not described in 'devm_regulator_unregister' drivers/regulator/devres.c:226: warning: Excess function parameter 'regulator' description in 'devm_regulator_unregister' Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20200708124832.3441649-2-lee.jones@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
2874c5fd |
|
27-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152 Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 3029 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
3eaeb475 |
|
03-Feb-2017 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
regulator: core: optimize devm_regulator_bulk_get() When performing this bulk operation, there is no need to track every supply individually. It is more efficient to treat entire group as a single managed resource. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
a8bd42a9 |
|
03-Feb-2017 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
regulator: core: have _regulator_get() accept get_type argument Instead of separate "exclusive" and "allow_dummy" arguments, that formed 3 valid combinations (normal, exclusive and optional) and an invalid one, let's accept explicit "get_type", like we did in devm-managed code. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
565f9b07 |
|
16-Aug-2016 |
Bjorn Andersson <bjorn.andersson@linaro.org> |
regulator: Remove support for optional supplies in the bulk API The patch was based on my missinterpretation of the API and only accidentally worked for me. Let's clean it out to not confuse others. This reverts commit 3ff3f518a135fa4592fe2817e9ac2cce1fa23dc2. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
3ff3f518 |
|
09-Nov-2015 |
Bjorn Andersson <bjorn.andersson@sonymobile.com> |
regulator: Make bulk API support optional supplies Make it possible to use the bulk API with optional supplies, by allowing the consumer to marking supplies as optional in the regulator_bulk_data. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
046db763 |
|
05-Mar-2015 |
Charles Keepax <ckeepax@gmail.com> |
regulator: core: Add devres versions of notifier registration Add devm_regulator_register_notifier, this adds the resource against the device for the consumer supply we are registering the notifier for. There seem to be few use-cases where this wouldn't be the users intention and this ensures the notifiers will always be removed at the correct time. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
9f8c0fe9 |
|
23-May-2014 |
Lee Jones <lee.jones@linaro.org> |
regulator: Constify the pointer to alias name array Toughen-up checks for read-only regulator names. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
a06ccd9c |
|
15-Oct-2013 |
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> |
regulator: core: Add ability to create a lookup alias for supply These patches add the ability to create an alternative device on which a lookup for a certain supply should be conducted. A common use-case for this would be devices that are logically represented as a collection of drivers within Linux but are are presented as a single device from device tree. It this case it is necessary for each sub device to locate their supply data on the main device. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@linaro.org>
|
#
0cdfcc0f |
|
11-Sep-2013 |
Mark Brown <broonie@linaro.org> |
regulator: core: Split devres code out into a separate file Cut down on the size of core.c a bit more and ensure that the devres versions of things don't do too much peering inside the internals of the APIs they wrap. Signed-off-by: Mark Brown <broonie@linaro.org>
|