- 15 Dec, 2022 1 commit
-
-
Johan Hovold authored
When updating the operating mode as part of regulator enable, the caller has already locked the regulator tree and drms_uA_update() must not try to do the same in order not to trigger a deadlock. The lock inversion is reported by lockdep as: ====================================================== WARNING: possible circular locking dependency detected 6.1.0-next-20221215 #142 Not tainted ------------------------------------------------------ udevd/154 is trying to acquire lock: ffffc11f123d7e50 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x280 but task is already holding lock: ffff80000e4c36e8 (regulator_ww_class_acquire){+.+.}-{0:0}, at: regulator_enable+0x34/0x80 which lock already depends on the new lock. ... Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(regulator_ww_class_acquire); lock(regulator_list_mutex); lock(regulator_ww_class_acquire); lock(regulator_list_mutex); *** DEADLOCK *** just before probe of a Qualcomm UFS controller (occasionally) deadlocks when enabling one of its regulators. Fixes: 9243a195 ("regulator: core: Change voltage setting path") Fixes: f8702f9e ("regulator: core: Use ww_mutex for regulators locking") Cc: stable@vger.kernel.org # 5.0 Signed-off-by:Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20221215104646.19818-1-johan+linaro@kernel.orgSigned-off-by:
Mark Brown <broonie@kernel.org>
-
- 14 Dec, 2022 1 commit
-
-
ChiYuan Huang authored
From Marek's log, the previous change modify the parent of rdev. https://lore.kernel.org/all/58b92e75-f373-dae7-7031-8abd465bb874@samsung.com/ In 'regulator_resolve_supply', it uses the parent DT node of rdev as the DT-lookup starting node. But the parent DT node may not exist. This will cause the NULL supply issue. This patch modify the parent of rdev back to the device that provides from 'regulator_config' in 'regulator_register'. Fixes: 8f3cbcd6 ("regulator: core: Use different devices for resource allocation and DT lookup") Reported-by:
Marek Szyprowski <m.szyprowski@samsung.com> Tested-by:
ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1670981831-12583-1-git-send-email-u0084500@gmail.comSigned-off-by:
-
- 08 Dec, 2022 2 commits
-
-
ChiYuan Huang authored
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:
-
Rob Herring authored
Several regulator schemas are missing 'unevaluatedProperties' constraint which means any extra properties are allowed. Upon adding the constraint, there's numerous warnings from using the deprecated 'regulator-compatible' property. Remove the usage as examples shouldn't be using long since deprecated properties. Signed-off-by:
Rob Herring <robh@kernel.org> Acked-by:
Lee Jones <lee@kernel.org> Acked-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20221206211554.92005-1-robh@kernel.orgSigned-off-by:
-
- 07 Dec, 2022 1 commit
-
-
Yuan Can authored
The reg_node needs to be released through of_node_put() in the error handling path when of_irq_get_byname() failed. Fixes: 390af53e ("regulator: qcom-labibb: Implement short-circuit and over-current IRQs") Signed-off-by:
Yuan Can <yuancan@huawei.com> Link: https://lore.kernel.org/r/20221203062109.115043-1-yuancan@huawei.comSigned-off-by:
-
- 02 Dec, 2022 4 commits
-
-
Mark Brown authored
Merge series from Alexandre Mergnat <amergnat@baylibre.com>: This adds regulator support for the MT6357 PMIC.
-
Fabien Parent authored
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.comSigned-off-by:
-
Fabien Parent authored
Add YAML schema for the MediaTek MT6357 regulators. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Yang Yingliang authored
I got some resource leak reports while doing fault injection test: OF: ERROR: memory leak, expected refcount 1 instead of 100, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /i2c/pmic@64/regulators/buck1 unreferenced object 0xffff88810deea000 (size 512): comm "490-i2c-rt5190a", pid 253, jiffies 4294859840 (age 5061.046s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff a0 1e 00 a1 ff ff ff ff ................ backtrace: [<00000000d78541e2>] kmalloc_trace+0x21/0x110 [<00000000b343d153>] device_private_init+0x32/0xd0 [<00000000be1f0c70>] device_add+0xb2d/0x1030 [<00000000e3e6344d>] regulator_register+0xaf2/0x12a0 [<00000000e2f5e754>] devm_regulator_register+0x57/0xb0 [<000000008b898197>] rt5190a_probe+0x52a/0x861 [rt5190a_regulator] unreferenced object 0xffff88810b617b80 (size 32): comm "490-i2c-rt5190a", pid 253, jiffies 4294859904 (age 5060.983s) hex dump (first 32 bytes): 72 65 67 75 6c 61 74 6f 72 2e 32 38 36 38 2d 53 regulator.2868-S 55 50 50 4c 59 00 ff ff 29 00 00 00 2b 00 00 00 UPPLY...)...+... backtrace: [<000000009da9280d>] __kmalloc_node_track_caller+0x44/0x1b0 [<0000000025c6a4e5>] kstrdup+0x3a/0x70 [<00000000790efb69>] create_regulator+0xc0/0x4e0 [<0000000005ed203a>] regulator_resolve_supply+0x2d4/0x440 [<0000000045796214>] regulator_register+0x10b3/0x12a0 [<00000000e2f5e754>] devm_regulator_register+0x57/0xb0 [<000000008b898197>] rt5190a_probe+0x52a/0x861 [rt5190a_regulator] After calling regulator_resolve_supply(), the 'rdev->supply' is set by set_supply(), after this set, in the error path, the resources need be released, so call regulator_put() to avoid the leaks. Fixes: aea6cb99 ("regulator: resolve supply after creating regulator") Fixes: 8a866d52 ("regulator: core: Resolve supply name earlier to prevent double-init") Signed-off-by:
-
- 01 Dec, 2022 2 commits
-
-
Yang Yingliang authored
If create_regulator() fails in set_supply(), the module refcount needs be put to keep refcount balanced. Fixes: e2c09ae7 ("regulator: core: Increase refcount for regulator supply's module") Signed-off-by:
-
Rui Zhang authored
I found a use_count leakage towards supply regulator of rdev with boot-on option. ┌───────────────────┐ ┌───────────────────┐ │ regulator_dev A │ │ regulator_dev B │ │ (boot-on) │ │ (boot-on) │ │ use_count=0 │
◀ ──supply──│ use_count=1 │ │ │ │ │ └───────────────────┘ └───────────────────┘ In case of rdev(A) configured with `regulator-boot-on', the use_count of supplying regulator(B) will increment inside regulator_enable(rdev->supply). Thus, B will acts like always-on, and further balanced regulator_enable/disable cannot actually disable it anymore. However, B was also configured with `regulator-boot-on', we wish it could be disabled afterwards. Signed-off-by:Rui Zhang <zr.zhang@vivo.com> Link: https://lore.kernel.org/r/20221201033806.2567812-1-zr.zhang@vivo.comSigned-off-by:
-
- 28 Nov, 2022 2 commits
-
-
Sebastian Reichel authored
Print error message for potential EPROBE_DEFER error using dev_err_probe, which captures the reason in /sys/kernel/debug/devices_deferred and otherwise silences the message. Signed-off-by:
-
Sebastian Reichel authored
Reduce usage of 'struct rk808' (driver data of the parent MFD), so that only the chip variant field is still being accessed directly. This allows restructuring the MFD driver to support SPI based PMICs. Acked-by:
-
- 25 Nov, 2022 1 commit
-
-
Mark Brown authored
Linux 6.1-rc4 which should get my CI working on RPi3s again.
-
- 24 Nov, 2022 7 commits
-
-
Jean Delvare authored
Since commit 0166dc11 ("of: make CONFIG_OF user selectable"), it is possible to test-build any driver which depends on OF on any architecture by explicitly selecting OF. Therefore depending on COMPILE_TEST as an alternative is no longer needed. It is actually better to always build such drivers with OF enabled, so that the test builds are closer to how each driver will actually be built on its intended target. Building them without OF may not test much as the compiler will optimize out potentially large parts of the code. In the worst case, this could even pop false positive warnings. Dropping COMPILE_TEST here improves the quality of our testing and avoids wasting time on non-existent issues. As a minor optimization, this also lets us drop several occurrences of of_match_ptr(), __maybe_unused and some ifdef guarding, as we now know what all of this will resolve to, we might as well save cpp some work. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Icenowy Zheng <icenowy@aosc.io> Link: https://lore.kernel.org/r/20221124144708.64371b98@endymion.delvareSigned-off-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-for-MFD-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by:
-
Mark Brown authored
Merge series from Abel Vesa <abel.vesa@linaro.org>: This patchset adds regulator support for the new Qualcomm PM8550 PMIC.
-
- 23 Nov, 2022 15 commits
-
-
Mark Brown authored
Merge series from Matti Vaittinen <mazziesaccount@gmail.com>: Minor (printing) improvements for ROHM regulator drivers. This series: - Drops an unnecessary info print from bd718x7. (Added a fixes tag for this but not really sure if worth adding to stable) - Convert the ROHM BDxxxxx PMIC regulator drivers to use dev_err_probe(). - Change the probe logic for bd718x7 to favor the more usual devm-style where errors are returned immediately.
-
Abel Vesa authored
Add the rpmh regulators found in PM8550 PMIC and its variants, along with their compatibles and configuration data. They also contain some FT-SMPS 525, so add their configuration as well. Signed-off-by:
Abel Vesa <abel.vesa@linaro.org> Reviewed-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20221123153638.721254-3-abel.vesa@linaro.orgSigned-off-by:
-
Abel Vesa authored
Add compatible string for PM8550 used in SM8550 boards. Signed-off-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by:
Michael Hennerich <michael.hennerich@analog.com> Acked-for-MFD-by:
-
Wang ShaoBo authored
Use kfree_const() to free supply_name conditionally in create_regulator() as supply_name may be allocated from kmalloc() or directly from .rodata section. Fixes: 87fe29b6 ("regulator: push allocations in create_regulator() outside of lock") Signed-off-by:
Wang ShaoBo <bobo.shaobowang@huawei.com> Link: https://lore.kernel.org/r/20221123034616.3609537-1-bobo.shaobowang@huawei.comSigned-off-by:
-
Matti Vaittinen authored
The dev_err_probe() has (at least) following benefits over dev_err() when printing an error print for a failed function call at a device driver probe: - Omit error level print if error is 'EPRBE_DEFER' - Standardized print format for returned error - return the error value allowing shortening calls like: if (ret) { dev_err(...); return ret; } to if (ret) return dev_err_probe(...); Convert the ROHM BD718x7 regulator driver to use the dev_err_probe() when returned error is not hard-coded constant. NOTE: This commit also changes the error handling path to return immediately from a spot where the error is spotted instead of using a single point of exit. Signed-off-by:Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/fee54c2d04bb41b51381e31523f9ed31575206d2.1669203610.git.mazziesaccount@gmail.comSigned-off-by:
-
Matti Vaittinen authored
The dev_err_probe() has (at least) following benefits over dev_err() when printing an error print for a failed function call at a device driver probe: - Omit error level print if error is 'EPRBE_DEFER' - Standardized print format for returned error - return the error value allowing shortening calls like: if (ret) { dev_err(...); return ret; } to if (ret) return dev_err_probe(...); Convert the ROHM BD71828, ROHM BD71815 and ROHM BD9576 regulator drivers to use the dev_err_probe() when returned error is not hard-coded constant. Signed-off-by: -
Matti Vaittinen authored
A device-tree node name was printed when bd718x7 driver's feedback-loop feature was developed. This print was accidentally left in driver. The info-level print just pollutes the log. Drop unnecessary pr_info() Fixes: d2ad9811 ("regulator: bd718x7: Support external connection to scale voltages") Signed-off-by:
-
Mark Brown authored
Merge branch 'i2c/client_device_id_helper-immutable' of https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux into regulator-6.2 so we can apply I2C API fixups.
-
- 22 Nov, 2022 4 commits
-
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
