summaryrefslogtreecommitdiff
path: root/drivers/regulator/core.c
AgeCommit message (Collapse)AuthorFilesLines
2023-02-23regulator: core: Use ktime_get_boottime() to determine how long a regulator ↵Matthias Kaehlcke1-3/+3
was off 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 <mka@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20230223003301.v2.1.I9719661b8eb0a73b8c416f9c26cf5bd8c0563f99@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2022-12-24Merge tag 'regulator-fix-v6.2-rc1' of ↵Linus Torvalds1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator 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
2022-12-15regulator: core: fix deadlock on regulator enableJohan Hovold1-1/+1
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 <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20221215104646.19818-1-johan+linaro@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-12-14regulator: core: Fix resolve supply lookup issueChiYuan Huang1-1/+1
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 <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1670981831-12583-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-12-13Merge tag 'regulator-v6.2' of ↵Linus Torvalds1-24/+39
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator 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() ...
2022-12-08regulator: core: Use different devices for resource allocation and DT lookupChiYuan Huang1-4/+4
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-12-02regulator: core: fix resource leak in regulator_register()Yang Yingliang1-0/+1
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 <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20221202025111.496402-1-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-12-01regulator: core: fix module refcount leak in set_supply()Yang Yingliang1-0/+1
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 <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20221201122706.4055992-2-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-12-01regulator: core: fix use_count leakage when handling boot-onRui Zhang1-1/+7
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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-11-26Merge tag 'regulator-fix-v6.1-rc6' of ↵Linus Torvalds1-2/+6
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator 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()
2022-11-23regulator: core: use kfree_const() to free space conditionallyWang ShaoBo1-1/+1
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: 87fe29b61f95 ("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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-11-16regulator: core: fix UAF in destroy_regulator()Yang Yingliang1-1/+1
I got a UAF report as following: ================================================================== BUG: KASAN: use-after-free in __lock_acquire+0x935/0x2060 Read of size 8 at addr ffff88810e838220 by task python3/268 Call Trace: <TASK> dump_stack_lvl+0x67/0x83 print_report+0x178/0x4b0 kasan_report+0x90/0x190 __lock_acquire+0x935/0x2060 lock_acquire+0x156/0x400 _raw_spin_lock+0x2a/0x40 lockref_get+0x11/0x30 simple_recursive_removal+0x41/0x440 debugfs_remove.part.12+0x32/0x50 debugfs_remove+0x29/0x30 _regulator_put.cold.54+0x3e/0x27f regulator_put+0x1f/0x30 release_nodes+0x6a/0xa0 devres_release_all+0xf8/0x150 Allocated by task 37: kasan_save_stack+0x1c/0x40 kasan_set_track+0x21/0x30 __kasan_slab_alloc+0x5d/0x70 slab_post_alloc_hook+0x62/0x510 kmem_cache_alloc_lru+0x222/0x5a0 __d_alloc+0x31/0x440 d_alloc+0x30/0xf0 d_alloc_parallel+0xc4/0xd20 __lookup_slow+0x15e/0x2f0 lookup_one_len+0x13a/0x150 start_creating+0xea/0x190 debugfs_create_dir+0x1e/0x210 create_regulator+0x254/0x4e0 _regulator_get+0x2a1/0x467 _devm_regulator_get+0x5a/0xb0 regulator_virtual_probe+0xb9/0x1a0 Freed by task 30: kasan_save_stack+0x1c/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x50 __kasan_slab_free+0x102/0x190 kmem_cache_free+0xf6/0x600 rcu_core+0x54c/0x12b0 __do_softirq+0xf2/0x5e3 Last potentially related work creation: kasan_save_stack+0x1c/0x40 __kasan_record_aux_stack+0x98/0xb0 call_rcu+0x42/0x700 dentry_free+0x6c/0xd0 __dentry_kill+0x23b/0x2d0 dput.part.31+0x431/0x780 simple_recursive_removal+0xa9/0x440 debugfs_remove.part.12+0x32/0x50 debugfs_remove+0x29/0x30 regulator_unregister+0xe3/0x230 release_nodes+0x6a/0xa0 ================================================================== Here is how happened: processor A processor B regulator_register() rdev_init_debugfs() rdev->debugfs = debugfs_create_dir() devm_regulator_get() rdev = regulator_dev_lookup() create_regulator(rdev) // using rdev->debugfs as parent debugfs_create_dir(rdev->debugfs) mfd_remove_devices_fn() release_nodes() regulator_unregister() // free rdev->debugfs debugfs_remove_recursive(rdev->debugfs) release_nodes() destroy_regulator() debugfs_remove_recursive() <- causes UAF In devm_regulator_get(), after getting rdev, the refcount is get, so fix this by moving debugfs_remove_recursive() to regulator_dev_release(), then it can be proctected by the refcount, the 'rdev->debugfs' can not be freed until the refcount is 0. Fixes: 5de705194e98 ("regulator: Add basic per consumer debugfs") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20221116033706.3595812-1-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-11-16regulator: core: fix kobject release warning and memory leak in ↵Zeng Heng1-1/+5
regulator_register() Here is a warning report about lack of registered release() from kobject lib: Device '(null)' does not have a release() function, it is broken and must be fixed. WARNING: CPU: 0 PID: 48430 at drivers/base/core.c:2332 device_release+0x104/0x120 Call Trace: kobject_put+0xdc/0x180 put_device+0x1b/0x30 regulator_register+0x651/0x1170 devm_regulator_register+0x4f/0xb0 When regulator_register() returns fail and directly goto `clean` symbol, rdev->dev has not registered release() function yet (which is registered by regulator_class in the following), so rdev needs to be freed manually. If rdev->dev.of_node is not NULL, which means the of_node has gotten by regulator_of_get_init_data(), it needs to call of_node_put() to avoid refcount leak. Otherwise, only calling put_device() would lead memory leak of rdev in further: unreferenced object 0xffff88810d0b1000 (size 2048): comm "107-i2c-rtq6752", pid 48430, jiffies 4342258431 (age 1341.780s) backtrace: kmalloc_trace+0x22/0x110 regulator_register+0x184/0x1170 devm_regulator_register+0x4f/0xb0 When regulator_register() returns fail and goto `wash` symbol, rdev->dev has registered release() function, so directly call put_device() to cleanup everything. Fixes: d3c731564e09 ("regulator: plug of_node leak in regulator_register()'s error path") Signed-off-by: Zeng Heng <zengheng4@huawei.com> Link: https://lore.kernel.org/r/20221116074339.1024240-1-zengheng4@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-11-15regulator: core: fix unbalanced of node refcount in regulator_dev_lookup()Yang Yingliang1-0/+1
I got the the following report: OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /i2c/pmic@62/regulators/exten In of_get_regulator(), the node is returned from of_parse_phandle() with refcount incremented, after using it, of_node_put() need be called. Fixes: 69511a452e6d ("regulator: map consumer regulator based on device tree") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20221115091508.900752-1-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-11-03regulator: devres: Add devm_regulator_bulk_get_exclusive()Zev Weiss1-18/+24
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-10-05Merge tag 'regulator-v6.1' of ↵Linus Torvalds1-35/+63
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator updates from Mark Brown: "The core work this time around has mostly been around the code to manage regulator modes, simplifying the interface for configuring modes to not take account of the voltage and as a side effect resolving a bootstrapping issue on systems where we can't read the voltage from the regulator. Otherwise it's been quite a quiet release with some new drivers and a devm helper: - Make the load handling in the Qualcomm RPMH regulators much more idiomatic and general cleanups to the handling of load configuration - devm helper for a combined get and enable operation - Support for MediaTek MT6331, Qualcomm PM660, 660L and PM6125, Texas Instruments TPS65219" * tag 'regulator-v6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (45 commits) dt-bindings: gpio-regulator: add vin-supply property support regulator: gpio: Add input_supply support in gpio_regulator_config regulator: tps65219: Fix is_enabled checking in tps65219_set_bypass regulator: qcom,rpmh: add pm660 and pm660l pmics regulator: qcom-rpmh: add pm660 and pm660l pmics regulator: of: Fix kernel-doc regulator: of: Fix kernel-doc regulator: Add driver for MT6332 PMIC regulators regulator: Add bindings for MT6332 regulator regulator: Add driver for MT6331 PMIC regulators regulator: Add bindings for MT6331 regulator regulator: tps65219: Fix .bypass_val_on setting regulator: qcom_rpm: Fix circular deferral regression regulator: core: Prevent integer underflow regulator: dt-bindings: qcom,rpmh: Indicate regulator-allow-set-load dependencies regulator: bd9576: switch to using devm_fwnode_gpiod_get() regulator: bd71815: switch to using devm_fwnode_gpiod_get() regulator: core: Fix regulator supply registration with sysfs regulator: tps65219: change tps65219_regulator_irq_types to static regulator: core: Don't err if allow-set-load but no allowed-modes ...
2022-09-10regulator: core: Prevent integer underflowPatrick Rudolph1-1/+1
By using a ratio of delay to poll_enabled_time that is not integer time_remaining underflows and does not exit the loop as expected. As delay could be derived from DT and poll_enabled_time is defined in the driver this can easily happen. Use a signed iterator to make sure that the loop exits once the remaining time is negative. Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Link: https://lore.kernel.org/r/20220909125954.577669-1-patrick.rudolph@9elements.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-08Merge tag 'regulator-fix-v6.0-rc4' of ↵Linus Torvalds1-2/+7
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fixes from Mark Brown: "One core fix here improving the error handling on enable failure, plus smaller fixes for the pfuze100 drive and the SPMI DT bindings" * tag 'regulator-fix-v6.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: Fix qcom,spmi-regulator schema regulator: pfuze100: Fix the global-out-of-bounds access in pfuze100_regulator_probe() regulator: core: Clean up on enable failure
2022-08-29regulator: core: Fix regulator supply registration with sysfsChristian Kohlschütter1-23/+21
In "regulator: core: Resolve supply name earlier to prevent double-init", we introduced a bug that prevented the regulator names from registering properly with sysfs. Reorder regulator_register such that supply names are properly resolved and registered. Fixes: 8a866d527ac0 ("regulator: core: Resolve supply name earlier to prevent double-init") Link: https://lore.kernel.org/all/58b92e75-f373-dae7-7031-8abd465bb874@samsung.com/ Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20220829165543.24856-1-christian@kohlschutter.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-25regulator: core: Don't err if allow-set-load but no allowed-modesDouglas Anderson1-0/+12
Apparently the device trees of some boards have the property "regulator-allow-set-load" for some of their regulators but then they don't specify anything for "regulator-allowed-modes". That's not really legit, but... ...before commit efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") they used to get away with it, at least on boards using RPMH regulators. That's because when a regulator driver implements set_load() then the core doesn't look at "regulator-allowed-modes" when trying to automatically adjust things in response to the regulator's load. The core doesn't know what mode we'll end up in, so how could it validate it? Said another way: before commit efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") some boards _were_ having the regulator mode adjusted despite listing no allowed modes. After commit efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") these same boards were now getting an error returned when trying to use their regulators, since simply enabling a regulator tries to update its load and that was failing. We don't really want to go back to the behavior from before commit efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()"). Boards shouldn't have been changing modes if no allowed modes were listed. However, the behavior after commit efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") isn't the best because now boards can't even turn their regulators on. Let's choose to detect this case and return "no error" from drms_uA_update(). The net-result will be _different_ behavior than we had before commit efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()"), but this new behavior seems more correct. If a board truly needed the mode switched then its device tree should be updated to list the allowed modes. Reported-by: Andrew Halaney <ahalaney@redhat.com> Fixes: efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Andrew Halaney <ahalaney@redhat.com> Link: https://lore.kernel.org/r/20220824142229.RFT.v2.2.I6f77860e5cd98bf5c67208fa9edda4a08847c304@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-25regulator: core: Require regulator drivers to check uV for get_optimum_mode()Douglas Anderson1-8/+14
The get_optimum_mode() for regulator drivers is passed the input voltage and output voltage as well as the current. This is because, in theory, the optimum mode can depend on all three things. It turns out that for all regulator drivers in mainline only the current is looked at when implementing get_optimum_mode(). None of the drivers take the input or output voltage into account. Despite the fact that none of the drivers take the input or output voltage into account, though, the regulator framework will error out before calling into get_optimum_mode() if it doesn't know the input or output voltage. The above behavior turned out to be a probelm for some boards when we landed commit efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()"). Before that change we'd have no problems running drms_uA_update() for RPMH regulators even if a regulator's input or output voltage was unknown. After that change drms_uA_update() started to fail. This is because typically boards using RPMH regulators don't model the input supplies of RPMH regulators. Input supplies for RPMH regulators nearly always come from the output of other RPMH regulators (or always-on regulators) and RPMH firmware is initialized with this knowledge and handles enabling (and adjusting the voltage of) input supplies. While we could model the parent/child relationship of the regulators in Linux, many boards don't bother since it adds extra overhead. Let's change the regulator core to make things work again. Now if we fail to get the input or output voltage we'll still call into get_optimum_mode() and we'll just pass error codes in for input_uV and/or output_uV parameters. Since no existing regulator drivers even look at input_uV and output_uV we don't need to add this error handling anywhere right now. We'll add some comments in the core so that it's obvious that (if regulator drivers care) it's up to them to add the checks. Reported-by: Andrew Halaney <ahalaney@redhat.com> Fixes: efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Andrew Halaney <ahalaney@redhat.com> Link: https://lore.kernel.org/r/20220824142229.RFT.v2.1.I137e6bef4f6d517be7b081be926059321102fd3d@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-22regulator: core: Remove "ramp_delay not set" debug messageChristian Kohlschütter1-3/+1
This message shows up occasionally but in bursts (seen up to 30 times per second on my ODROID N2+). According to Matthias Kaehlcke's comment in 'regulator: core: silence warning: "VDD1: ramp_delay not set"', this message should have been removed after restructuring previous code that assumed that ramp_delay being zero in that function was an error. Link: https://lore.kernel.org/lkml/625675256c0d75805f088b4be17a3308dc1b7ea4.1477571498.git.hns@goldelico.com/T/ Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com> Link: https://lore.kernel.org/r/20220820131420.16608-1-christian@kohlschutter.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-22regulator: core: Clean up on enable failureAndrew Halaney1-2/+7
If regulator_enable() fails, enable_count is incremented still. A consumer, assuming no matching regulator_disable() is necessary on failure, will then get this error message upon regulator_put() since enable_count is non-zero: [ 1.277418] WARNING: CPU: 3 PID: 1 at drivers/regulator/core.c:2304 _regulator_put.part.0+0x168/0x170 The consumer could try to fix this in their driver by cleaning up on error from regulator_enable() (i.e. call regulator_disable()), but that results in the following since regulator_enable() failed and didn't increment user_count: [ 1.258112] unbalanced disables for vreg_l17c [ 1.262606] WARNING: CPU: 4 PID: 1 at drivers/regulator/core.c:2899 _regulator_disable+0xd4/0x190 Fix this by decrementing enable_count upon failure to enable. With this in place, just the reason for failure to enable is printed as expected and developers can focus on the root cause of their issue instead of thinking their usage of the regulator consumer api is incorrect. For example, in my case: [ 1.240426] vreg_l17c: invalid input voltage found Fixes: 5451781dadf8 ("regulator: core: Only count load for enabled consumers") Signed-off-by: Andrew Halaney <ahalaney@redhat.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Brian Masney <bmasney@redhat.com> Link: https://lore.kernel.org/r/20220819194336.382740-1-ahalaney@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-18regulator: core: Resolve supply name earlier to prevent double-initChristian Kohlschütter1-19/+33
Previously, an unresolved regulator supply reference upon calling regulator_register on an always-on or boot-on regulator caused set_machine_constraints to be called twice. This in turn may initialize the regulator twice, leading to voltage glitches that are timing-dependent. A simple, unrelated configuration change may be enough to hide this problem, only to be surfaced by chance. One such example is the SD-Card voltage regulator in a NanoPI R4S that would not initialize reliably unless the registration flow was just complex enough to allow the regulator to properly reset between calls. Fix this by re-arranging regulator_register, trying resolve the regulator's supply early enough that set_machine_constraints does not need to be called twice. Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com> Link: https://lore.kernel.org/r/20220818124646.6005-1-christian@kohlschutter.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-10regulator: core: Fix missing error return from regulator_bulk_get()Douglas Anderson1-1/+1
In commit 6eabfc018e8d ("regulator: core: Allow specifying an initial load w/ the bulk API") I changed the error handling but had a subtle that caused us to always return no error even if there was an error. Fix it. Fixes: 6eabfc018e8d ("regulator: core: Allow specifying an initial load w/ the bulk API") Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20220809142738.1.I91625242f137c707bb345c51c80c5ecee02eeff3@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-28regulator: Consumer load management improvementsMark Brown1-8/+12
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.
2022-07-27regulator: core: Allow specifying an initial load w/ the bulk APIDouglas Anderson1-8/+12
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>
2022-07-19regulator: core: Fix off-on-delay-us for always-on/boot-on regulatorsChristian Kohlschütter1-2/+3
Regulators marked with "regulator-always-on" or "regulator-boot-on" as well as an "off-on-delay-us", may run into cycling issues that are hard to detect. This is caused by the "last_off" state not being initialized in this case. Fix the "last_off" initialization by setting it to the current kernel time upon initialization, regardless of always_on/boot_on state. Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com> Link: https://lore.kernel.org/r/FAFD5B39-E9C4-47C7-ACF1-2A04CD59758D@kohlschutter.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-05-17Merge remote-tracking branch 'regulator/for-5.19' into regulator-nextMark Brown1-14/+72
2022-05-05regulator: core: Fix enable_count imbalance with EXCLUSIVE_GETZev Weiss1-2/+5
Since the introduction of regulator->enable_count, a driver that did an exclusive get on an already-enabled regulator would end up with enable_count initialized to 0 but rdev->use_count initialized to 1. With that starting point the regulator is effectively stuck enabled, because if the driver attempted to disable it it would fail the enable_count underflow check in _regulator_handle_consumer_disable(). The EXCLUSIVE_GET path in _regulator_get() now initializes enable_count along with rdev->use_count so that the regulator can be disabled without underflowing the former. Signed-off-by: Zev Weiss <zev@bewilderbeest.net> Fixes: 5451781dadf85 ("regulator: core: Only count load for enabled consumers") Link: https://lore.kernel.org/r/20220505043152.12933-1-zev@bewilderbeest.net Signed-off-by: Mark Brown <broonie@kernel.org>
2022-05-04regulator: core: Add error flags to sysfs attributesZev Weiss1-0/+45
If a regulator provides a get_error_flags() operation, its sysfs attributes will now include an entry for each defined REGULATOR_ERROR_* flag. Signed-off-by: Zev Weiss <zev@bewilderbeest.net> Link: https://lore.kernel.org/r/20220504065252.6955-3-zev@bewilderbeest.net Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-21regulator: core: Sleep (not delay) in set_voltage()Brian Norris1-6/+1
These delays can be relatively large (e.g., hundreds of microseconds to several milliseconds on RK3399 Gru systems). Per Documentation/timers/timers-howto.rst, that should usually use a sleeping delay. Let's use the existing regulator delay helper to handle both large and small delays appropriately. This avoids burning a bunch of CPU time and hurting scheduling latencies when hitting regulators a lot (e.g., during cpufreq). The sleep vs. delay issue choice has been made differently over time -- early versions of RK3399 Gru PWM-regulator support used usleep_range() in pwm-regulator.c. More of this got moved into the regulator core, in commits like: 73e705bf81ce regulator: core: Add set_voltage_time op At the same time, the sleep turned into a delay. It's OK to sleep in _regulator_do_set_voltage(), as we aren't in an atomic context. (All our callers grab various mutexes already.) I avoid using fsleep() because it uses a usleep_range() of [N to N*2], and usleep_range() very commonly biases to the high end of the range. We don't want to double the expected delay, especially for long delays. Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20220420141511.v2.2.If0fc61a894f537b052ca41572aff098cf8e7e673@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-21regulator: core: Rename _regulator_enable_delay()Brian Norris1-8/+8
I want to use it in other contexts besides _regulator_do_enable(). Signed-off-by: Brian Norris <briannorris@chromium.org> Link: https://lore.kernel.org/r/20220420141511.v2.1.I31ef0014c9597d53722ab513890f839f357fdfb3@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-04regulator: Flag uncontrollable regulators as always_onMark Brown1-0/+18
While we currently assume that regulators with no control available are just uncontionally enabled this isn't always as clearly displayed to users as is desirable, for example the code for disabling unused regulators will log that it is about to disable them. Clean this up a bit by setting always_on during constraint evaluation if we have no available mechanism for controlling the regualtor so things that check the constraint will do the right thing. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220325144637.1543496-1-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-02-08regulator: core: fix false positive in regulator_late_cleanup()Oliver Barta1-10/+3
The check done by regulator_late_cleanup() to detect whether a regulator is on was inconsistent with the check done by _regulator_is_enabled(). While _regulator_is_enabled() takes the enable GPIO into account, regulator_late_cleanup() was not doing that. This resulted in a false positive, e.g. when a GPIO-controlled fixed regulator was used, which was not enabled at boot time, e.g. reg_disp_1v2: reg_disp_1v2 { compatible = "regulator-fixed"; regulator-name = "display_1v2"; regulator-min-microvolt = <1200000>; regulator-max-microvolt = <1200000>; gpio = <&tlmm 148 0>; enable-active-high; }; Such regulator doesn't have an is_enabled() operation. Nevertheless it's state can be determined based on the enable GPIO. The check in regulator_late_cleanup() wrongly assumed that the regulator is on and tried to disable it. Signed-off-by: Oliver Barta <oliver.barta@aptiv.com> Link: https://lore.kernel.org/r/20220208084645.8686-1-oliver.barta@aptiv.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-02Merge tag 'regulator-v5.16' of ↵Linus Torvalds1-4/+8
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator updates from Mark Brown: "Thanks to the removal of the unused TPS80021 driver the regulator updates for this cycle actually have a negative diffstat. Otherwise it's been quite a quiet release, lots of fixes and small improvements with the biggest individual changes being several conversions of DT bindings to YAML format" * tag 'regulator-v5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (34 commits) regulator: Don't error out fixed regulator in regulator_sync_voltage() regulator: tps80031: Remove driver regulator: Fix SY7636A breakage regulator: uniphier: Add binding for NX1 SoC regulator: uniphier: Add USB-VBUS compatible string for NX1 SoC regulator: qcom,rpmh: Add compatible for PM6350 regulator: qcom-rpmh: Add PM6350 regulators regulator: sy7636a: Remove requirement on sy7636a mfd regulator: tps62360: replacing legacy gpio interface for gpiod regulator: lp872x: Remove lp872x_dvs_state regulator: lp872x: replacing legacy gpio interface for gpiod regulator: dt-bindings: samsung,s5m8767: convert to dtschema regulator: dt-bindings: samsung,s2mpa01: convert to dtschema regulator: dt-bindings: samsung,s2m: convert to dtschema dt-bindings: clock: samsung,s2mps11: convert to dtschema regulator: dt-bindings: samsung,s5m8767: correct s5m8767,pmic-buck-default-dvs-idx property regulator: s5m8767: do not use reset value as DVS voltage if GPIO DVS is disabled regulator: dt-bindings: maxim,max8973: convert to dtschema regulator: dt-bindings: maxim,max8997: convert to dtschema regulator: dt-bindings: maxim,max8952: convert to dtschema ...
2021-10-23regulator: Don't error out fixed regulator in regulator_sync_voltage()Dmitry Osipenko1-0/+3
Fixed regulator can't change voltage and regulator_sync_voltage() returns -EINVAL in this case. Make regulator_sync_voltage() to succeed for regulators that are incapable to change voltage. On NVIDIA Tegra power management driver needs to sync voltage and we have one device (Trimslice) that uses fixed regulator which is getting synced. The syncing error isn't treated as fatal, but produces a noisy error message. This patch silences that error. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20211021183308.27786-1-digetx@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-30regulator: Lower priority of logging when setting supplyMark Brown1-1/+1
We lowered all the other constraint related log messages to debug level so lower the logging of what supplies we're configuring to debug level too. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210929140717.3769-1-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-17kernel/locking: Add context to ww_mutex_trylock()Maarten Lankhorst1-1/+1
i915 will soon gain an eviction path that trylock a whole lot of locks for eviction, getting dmesg failures like below: BUG: MAX_LOCK_DEPTH too low! turning off the locking correctness validator. depth: 48 max: 48! 48 locks held by i915_selftest/5776: #0: ffff888101a79240 (&dev->mutex){....}-{3:3}, at: __driver_attach+0x88/0x160 #1: ffffc900009778c0 (reservation_ww_class_acquire){+.+.}-{0:0}, at: i915_vma_pin.constprop.63+0x39/0x1b0 [i915] #2: ffff88800cf74de8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.63+0x5f/0x1b0 [i915] #3: ffff88810c7f9e38 (&vm->mutex/1){+.+.}-{3:3}, at: i915_vma_pin_ww+0x1c4/0x9d0 [i915] #4: ffff88810bad5768 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915] #5: ffff88810bad60e8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915] ... #46: ffff88811964d768 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915] #47: ffff88811964e0e8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915] INFO: lockdep is turned off. Fixing eviction to nest into ww_class_acquire is a high priority, but it requires a rework of the entire driver, which can only be done one step at a time. As an intermediate solution, add an acquire context to ww_mutex_trylock, which allows us to do proper nesting annotations on the trylocks, making the above lockdep splat disappear. This is also useful in regulator_lock_nested, which may avoid dropping regulator_nesting_mutex in the uncontended path, so use it there. TTM may be another user for this, where we could lock a buffer in a fastpath with list locks held, without dropping all locks we hold. [peterz: rework actual ww_mutex_trylock() implementations] Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/YUBGPdDDjKlxAuXJ@hirez.programming.kicks-ass.net
2021-09-13regulator: core: resolve supply voltage deferral silentlyBrian Norris1-3/+4
Voltage-controlled regulators depend on their supply regulator for retrieving their voltage, and so they might return -EPROBE_DEFER at this stage. Our caller already attempts to resolve supplies and retry, so we shouldn't be printing this error to logs. Quiets log messages like this, on Rockchip RK3399 Gru/Kevin boards: [ 1.033057] ppvar_bigcpu: failed to get the current voltage: -EPROBE_DEFER ... [ 1.036735] ppvar_litcpu: failed to get the current voltage: -EPROBE_DEFER ... [ 1.040366] ppvar_gpu: failed to get the current voltage: -EPROBE_DEFER ... [ 1.044086] ppvar_centerlogic: failed to get the current voltage: -EPROBE_DEFER Cc: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Link: https://lore.kernel.org/r/20210826124015.1.Iab79c6dd374ec48beac44be2fcddd165dd26476b@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2021-06-23Merge remote-tracking branch 'regulator/for-5.14' into regulator-nextMark Brown1-89/+227
2021-06-21Merge series "Extend regulator notification support" from Matti Vaittinen ↵Mark Brown1-19/+144
<matti.vaittinen@fi.rohmeurope.com>: Extend regulator notification support This series extends the regulator notification and error flag support. Initial discussion on the topic can be found here: https://lore.kernel.org/lkml/6046836e22b8252983f08d5621c35ececb97820d.camel@fi.rohmeurope.com/ In a nutshell - the series adds: 1. WARNING level events/error flags. (Patch 3) Current regulator 'ERROR' event notifications for over/under voltage, over current and over temperature are used to indicate condition where monitored entity is so badly "off" that it actually indicates a hardware error which can not be recovered. The most typical hanling for that is believed to be a (graceful) system-shutdown. Here we add set of 'WARNING' level flags to allow sending notifications to consumers before things are 'that badly off' so that consumer drivers can implement recovery-actions. 2. Device-tree properties for specifying limit values. (Patches 1, 5) Add limits for above mentioned 'ERROR' and 'WARNING' levels (which send notifications to consumers) and also for a 'PROTECTION' level (which will be used to immediately shut-down the regulator(s) W/O informing consumer drivers. Typically implemented by hardware). Property parsing is implemented in regulator core which then calls callback operations for limit setting from the IC drivers. A warning is emitted if protection is requested by device tree but the underlying IC does not support configuring requested protection. 3. Helpers which can be registered by IC. (Patch 4) Target is to avoid implementing IRQ handling and IRQ storm protection in each IC driver. (Many of the ICs implementin these IRQs do not allow masking or acking the IRQ but keep the IRQ asserted for the whole duration of problem keeping the processor in IRQ handling loop). 4. Emergency poweroff function (refactored out of the thermal_core to kernel/reboot.c) which is called if IC fires error IRQs but IC reading fails and given retry-count is exceeded. (Patches 2, 4) Please note that the mutex in the emergency shutdown was replaced by a simple atomic in order to allow call from any context. The helper was attempted to be done so it could be used to implement roughly same logic as is used in qcom-labibb regulator. This means amongst other things a safety shut-down if IC registers are not readable. Using these shut-down retry counters are optional. The idea is that the helper could be also used by simpler ICs which do not provide status register(s) which can be used to check if error is still active. ICs which do not have such status register can simply omit the 'renable' callback (and retry-counts etc) - and helper assumes the situation is Ok and re-enables IRQ after given time period. If problem persists the handler is ran again and another notification is sent - but at least the delay allows processor to avoid IRQ loop. Patch 7 takes this notification support in use at BD9576MUF. Patch 8 is related to MFD change which is not really related to the RFC here. It was added to this series in order to avoid potential conflicts. Patch 9 adds a maintainers entry. Changelog v10-RESEND: - rebased on v5.13-rc4 Changelog v10: - rebased on v5.13-rc2 - Move rdev_*() print macros to the internal.h and use rdev_dbg() from irq_helpers.c - Export rdev_get_name() and move it from coupler.h to driver.h for others to use. (It was already in coupler.h but not exported - usage was limited and coupler.h does not sound like optimal place as rdev_name is not only used by coupled regulators) - Send all regulator notifications from irq_helpers.c at one OR'd event for the sake of simplicity. For BD9576 this does not matter as it has own IRQ for each event case. Header defining events says they may be OR'd. - Change WARN() at protection shutdown to pr_emerg as suggested by Petr. Changelog v9: - rebases on v5.13-rc1 - Update thermal documentation - Fix regulator notification event number Changelog v8: - split shutdown API adding and thermal core taking it in use to own patches. - replace the spinlock with atomic when ensuring the emergency shutdown is only called once. Changelog v7: general: - rebased on v5.12-rc7 - new patch for refactoring the hw-failure reboot logic out of thermal_core.c for others to use. notification helpers: - fix regulator error_flags query - grammar/typos - do not BUG() but attempt to shut-down the system - use BITS_PER_TYPE() Changelog v6: Add MAINTAINERS entry Changes to IRQ notifiers - move devm functions to drivers/regulator/devres.c - drop irq validity check - use devm_add_action_or_reset() - fix styling issues - fix kerneldocs Changelog v5: - Fix the badly formatted pr_emerg() call. Changelog v4: - rebased on v5.12-rc6 - dropped RFC - fix external FET DT-binding. - improve prints for cases when expecting HW failure. - styling and typos Changelog v3: Regulator core: - Fix dangling pointer access at regulator_irq_helper() stpmic1_regulator: - fix function prototype (compile error) bd9576-regulator: - Update over current limits to what was given in new data-sheet (REV00K) - Allow over-current monitoring without external FET. Set limits to values given in data-sheet (REV00K). Changelog v2: Generic: - rebase on v5.12-rc2 + BD9576 series - Split devm variant of delayed wq to own series Regulator framework: - Provide non devm variant of IRQ notification helpers - shorten dt-property names as suggested by Rob - unconditionally call map_event in IRQ handling and require it to be populated BD9576 regulators: - change the FET resistance property to micro-ohms - fix voltage computation in OC limit setting
2021-06-21regulator: add property parsing and callbacks to set protection limitsMatti Vaittinen1-1/+121
Add DT property parsing code and setting callback for regulator over/under voltage, over-current and temperature error limits. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/e7b8007ba9eae7076178bf3363fb942ccb1cc9a5.1622628334.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-06-21regulator: IRQ based event/error notification helpersMatti Vaittinen1-7/+22
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>
2021-06-21regulator: move rdev_print helpers to internal.hMatti Vaittinen1-11/+1
The rdev print helpers are a nice way to print messages related to a specific regulator device. Move them from core.c to internal.h As the rdev print helpers use rdev_get_name() export it from core.c. Also move the declaration from coupler.h to driver.h because the rdev name is not just a coupled regulator property. I guess the main audience for rdev_get_name() will be the regulator core and drivers. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/dc7fd70dc31de4d0e820b7646bb78eeb04f80735.1622628333.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-06-14Merge tag 'for-5.14-regulator' of ↵Mark Brown1-0/+23
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into regulator-5.14 regulator: Changes for v5.14-rc1 This adds regulator_sync_voltage_rdev(), which is used as a dependency for new Tegra power domain code.
2021-06-02regulator: core: Use DEVICE_ATTR_RO macroYueHaibing1-70/+60
Use DEVICE_ATTR_RO() helper instead of plain DEVICE_ATTR(), which makes the code a bit shorter and easier to read. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20210529115226.25376-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-06-01regulator: core: Add regulator_sync_voltage_rdev()Dmitry Osipenko1-0/+23
Some NVIDIA Tegra devices use a CPU soft-reset method for the reboot and in this case we need to restore the coupled voltages to the state that is suitable for hardware during boot. Add new regulator_sync_voltage_rdev() helper which is needed by regulator drivers in order to sync voltage of a coupled regulators. Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-05-21regulator: core: resolve supply for boot-on/always-on regulatorsDmitry Baryshkov1-0/+6
For the boot-on/always-on regulators the set_machine_constrainst() is called before resolving rdev->supply. Thus the code would try to enable rdev before enabling supplying regulator. Enforce resolving supply regulator before enabling rdev. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210519221224.2868496-1-dmitry.baryshkov@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-04-23regulator: core: Fix off_on_delay handlingVincent Whitchurch1-25/+8
The jiffies-based off_on_delay implementation has a couple of problems that cause it to sometimes not actually delay for the required time: (1) If, for example, the off_on_delay time is equivalent to one jiffy, and the ->last_off_jiffy is set just before a new jiffy starts, then _regulator_do_enable() does not wait at all since it checks using time_before(). (2) When jiffies overflows, the value of "remaining" becomes higher than "max_delay" and the code simply proceeds without waiting. Fix these problems by changing it to use ktime_t instead. [Note that since jiffies doesn't start at zero but at INITIAL_JIFFIES ("-5 minutes"), (2) above also led to the code not delaying if the first regulator_enable() is called when the ->last_off_jiffy is not initialised, such as for regulators with ->constraints->boot_on set. It's not clear to me if this was intended or not, but I've preserved this behaviour explicitly with the check for a non-zero ->last_off.] Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Link: https://lore.kernel.org/r/20210423114524.26414-1-vincent.whitchurch@axis.com Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-11-17 06:35:49 +0300