user/sven/linux.git/drivers/regulator/core.c, branch v6.2.7

regulator: core: Use ktime_get_boottime() to determine how long a regulator was off

2023-03-10T08:29:47Z

commit 80d2c29e09e663761c2778167a625b25ffe01b6f upstream. For regulators with 'off-on-delay-us' the regulator framework currently uses ktime_get() to determine how long the regulator has been off before re-enabling it (after a delay if needed). A problem with using ktime_get() is that it doesn't account for the time the system is suspended. As a result a regulator with a longer 'off-on-delay' (e.g. 500ms) that was switched off during suspend might still incurr in a delay on resume before it is re-enabled, even though the regulator might have been off for hours. ktime_get_boottime() accounts for suspend time, use it instead of ktime_get(). Fixes: a8ce7bd89689 ("regulator: core: Fix off_on_delay handling") Cc: stable@vger.kernel.org # 5.13+ Signed-off-by: Matthias Kaehlcke Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/20230223003301.v2.1.I9719661b8eb0a73b8c416f9c26cf5bd8c0563f99@changeid Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

Merge tag 'regulator-fix-v6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator

2022-12-23T22:38:00Z

Pull regulator fixes from Mark Brown: "Two core fixes here, one for a long standing race which some Qualcomm systems have started triggering with their UFS driver and another fixing a problem with supply lookup introduced by the fixes for devm related use after free issues that were introduced in this merge window" * tag 'regulator-fix-v6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: core: fix deadlock on regulator enable regulator: core: Fix resolve supply lookup issue

regulator: core: fix deadlock on regulator enable

2022-12-15T11:56:26Z

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: 9243a195be7a ("regulator: core: Change voltage setting path") Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") Cc: stable@vger.kernel.org # 5.0 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20221215104646.19818-1-johan+linaro@kernel.org Signed-off-by: Mark Brown

regulator: core: Fix resolve supply lookup issue

2022-12-14T13:36:45Z

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: 8f3cbcd6b440 ("regulator: core: Use different devices for resource allocation and DT lookup") Reported-by: Marek Szyprowski Tested-by: Marek Szyprowski Signed-off-by: ChiYuan Huang Link: https://lore.kernel.org/r/1670981831-12583-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown

Merge tag 'regulator-v6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator

2022-12-13T20:49:59Z

Pull regulator updates from Mark Brown: "Quite a quiet release for regulator, the diffstat is dominated by the I2C migration to probe_new() and the newly added MT6357 driver. We've just one framework addition and the rest is all new device support, fixes and cleanups. The framework addition is an API for requesting all regulators defined in DT, this isn't great practice but has reasonable applications when there is generic code handling devices on buses where the bus specification doesn't include power. The immediate application is MDIO but I believe there's others, it's another API that'll need an eye keeping on it for undesirable usage. Summary: - An API for requesting all regulators defined in DT - Conversion of lots of drivers to the I2C probe_new() API - Support for Mediatek MT6357, Qualcomm PM8550, PMR735a and Richtek RT6190" * tag 'regulator-v6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (56 commits) regulator: core: Use different devices for resource allocation and DT lookup dt-bindings: Add missing 'unevaluatedProperties' to regulator nodes regulator: qcom-labibb: Fix missing of_node_put() in qcom_labibb_regulator_probe() regulator: add mt6357 regulator regulator: dt-bindings: Add binding schema for mt6357 regulators regulator: core: fix resource leak in regulator_register() regulator: core: fix module refcount leak in set_supply() regulator: core: fix use_count leakage when handling boot-on regulator: rk808: Use dev_err_probe regulator: rk808: reduce 'struct rk808' usage regulator: Drop obsolete dependencies on COMPILE_TEST regulator: pv88080-regulator: Convert to i2c's .probe_new() regulator: pfuze100-regulator: Convert to i2c's .probe_new() regulator: isl6271a-regulator: Convert to i2c's .probe_new() regulator: fan53555: Convert to i2c's .probe_new() regulator: act8865-regulator: Convert to i2c's .probe_new() regulator: qcom-rpmh: Add support for PM8550 regulators regulator: dt-bindings: qcom,rpmh: Add compatible for PM8550 regulator: tps65023-regulator: Convert to i2c's .probe_new() regulator: tps62360-regulator: Convert to i2c's .probe_new() ...

regulator: core: Use different devices for resource allocation and DT lookup

2022-12-08T13:02:37Z

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 Signed-off-by: ChiYuan Huang Link: https://lore.kernel.org/r/1670311341-32664-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown

regulator: core: fix resource leak in regulator_register()

2022-12-02T11:55:58Z

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: aea6cb99703e ("regulator: resolve supply after creating regulator") Fixes: 8a866d527ac0 ("regulator: core: Resolve supply name earlier to prevent double-init") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221202025111.496402-1-yangyingliang@huawei.com Signed-off-by: Mark Brown

regulator: core: fix module refcount leak in set_supply()

2022-12-01T17:19:12Z

If create_regulator() fails in set_supply(), the module refcount needs be put to keep refcount balanced. Fixes: e2c09ae7a74d ("regulator: core: Increase refcount for regulator supply's module") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221201122706.4055992-2-yangyingliang@huawei.com Signed-off-by: Mark Brown

regulator: core: fix use_count leakage when handling boot-on

2022-12-01T11:41:19Z

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 Link: https://lore.kernel.org/r/20221201033806.2567812-1-zr.zhang@vivo.com Signed-off-by: Mark Brown

Merge tag 'regulator-fix-v6.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator

2022-11-25T21:54:48Z

Pull regulator fixes from Mark Brown: "This is more changes than I'd like this late although the diffstat is still fairly small, I kept on holding off as new fixes came in to give things time to soak in -next but should probably have tagged and sent an additional pull request earlier. There's some relatively large fixes to the twl6030 driver to fix issues with the TWL6032 variant which resulted from some work on the core TWL6030 driver, a couple of fixes for error handling paths (mostly in the core), and a nice stability fix for the sgl51000 driver that's been pulled out of a BSP" * tag 'regulator-fix-v6.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: twl6030: fix get status of twl6032 regulators regulator: twl6030: re-add TWL6032_SUBCLASS regulator: slg51000: Wait after asserting CS pin regulator: core: fix UAF in destroy_regulator() regulator: rt5759: fix OOB in validate_desc() regulator: core: fix kobject release warning and memory leak in regulator_register()