Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.132 2022-12-08T13:02:37+00:00 2022-12-08T13:02:37+00:00 ChiYuan Huang cy_huang@richtek.com 2022-12-06T07:22:21+00:00 urn:sha1:8f3cbcd6b440032ebc7f7d48a1689dcc70a4eb98 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> 2022-11-03T13:34:53+00:00 Zev Weiss zev@bewilderbeest.net 2022-10-31T23:37:02+00:00 urn:sha1:fd1845069711cdf1b1aaaa0f22311b7736396331 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> 2022-08-18T11:51:48+00:00 Matti Vaittinen mazziesaccount@gmail.com 2022-08-12T10:10:37+00:00 urn:sha1:da279e6965b3838e99e5c0ab8f76b87bf86b31a5 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> 2022-07-27T12:47:30+00:00 Douglas Anderson dianders@chromium.org 2022-07-26T17:38:23+00:00 urn:sha1:1de452a0edda26f1483d1d934f692eab13ba669a 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> 2021-07-11T22:50:34+00:00 Alexandru Ardelean aardelean@deviqon.com 2021-06-25T12:23:24+00:00 urn:sha1:4d9f4d1de3ceb84fa6ce68177a26b8fac6a71290 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> 2021-07-11T22:50:33+00:00 Alexandru Ardelean aardelean@deviqon.com 2021-06-25T12:23:23+00:00 urn:sha1:eed43b96ede9c3f018ad24149de83f24b86ad729 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> 2021-07-11T22:50:32+00:00 Alexandru Ardelean aardelean@deviqon.com 2021-06-25T12:23:22+00:00 urn:sha1:4ff75a29976590bc7afe3ed75d547c1f2a924c75 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> 2021-06-21T12:08:40+00:00 Matti Vaittinen matti.vaittinen@fi.rohmeurope.com 2021-06-03T05:41:55+00:00 urn:sha1:7111c6d1b31b42c8c758f6681e895a5116e3bad6 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> 2020-07-08T16:37:54+00:00 Lee Jones lee.jones@linaro.org 2020-07-08T12:48:32+00:00 urn:sha1:a7c15187b391d7fe9903903475a94e5cd5b796d6 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> 2020-07-08T16:37:52+00:00 Lee Jones lee.jones@linaro.org 2020-07-08T12:48:30+00:00 urn:sha1:9565cccd64876dd1f8732fad3a04f8daa41fcef9 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>