summaryrefslogtreecommitdiff
path: root/drivers/regulator
AgeCommit message (Collapse)AuthorFilesLines
2023-03-10regulator: core: Use ktime_get_boottime() to determine how long a regulator ↵Matthias Kaehlcke1-3/+3
was off 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 <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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-10regulator: s5m8767: Bounds check id indexing into arraysKees Cook1-1/+5
[ Upstream commit e314e15a0b58f9d051c00b25951073bcdae61953 ] The compiler has no way to know if "id" is within the array bounds of the regulators array. Add a check for this and a build-time check that the regulators and reg_voltage_map arrays are sized the same. Seen with GCC 13: ../drivers/regulator/s5m8767.c: In function 's5m8767_pmic_probe': ../drivers/regulator/s5m8767.c:936:35: warning: array subscript [0, 36] is outside array bounds of 'struct regulator_desc[37]' [-Warray-bounds=] 936 | regulators[id].vsel_reg = | ~~~~~~~~~~^~~~ Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: linux-samsung-soc@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230128005358.never.313-kees@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10regulator: max77802: Bounds check regulator id against opmodeKees Cook1-10/+24
[ Upstream commit 4fd8bcec5fd7c0d586206fa2f42bd67b06cdaa7e ] Explicitly bounds-check the id before accessing the opmode array. Seen with GCC 13: ../drivers/regulator/max77802-regulator.c: In function 'max77802_enable': ../drivers/regulator/max77802-regulator.c:217:29: warning: array subscript [0, 41] is outside array bounds of 'unsigned int[42]' [-Warray-bounds=] 217 | if (max77802->opmode[id] == MAX77802_OFF_PWRREQ) | ~~~~~~~~~~~~~~~~^~~~ ../drivers/regulator/max77802-regulator.c:62:22: note: while referencing 'opmode' 62 | unsigned int opmode[MAX77802_REG_MAX]; | ^~~~~~ Cc: Javier Martinez Canillas <javier@dowhile0.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20230127225203.never.864-kees@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10regulator: tps65219: use generic set_bypass()Jerome Neanne1-19/+1
[ Upstream commit 0365df81145a4cfaae5f4da896160de512256e6d ] Due to wrong interpretation of the specification, custom implementation was used instead of standard regmap helper. LINK: https://lore.kernel.org/all/c2014039-f1e8-6976-33d6-52e2dd4e7b66@baylibre.com/ Fixes: c12ac5fc3e0a ("regulator: drivers: Add TI TPS65219 PMIC regulators support") Regulator does NOT require to be off to be switched to bypass mode. Signed-off-by: Jerome Neanne <jneanne@baylibre.com> Link: https://lore.kernel.org/r/20230203140119.13029-1-jneanne@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10regulator: tps65219: use IS_ERR() to detect an error pointerRandy Dunlap1-1/+1
[ Upstream commit 2bbba115c3c9a647bcb3201b014fcc3728fe75c8 ] Fix pointer comparison to integer warning from gcc & sparse: GCC: ../drivers/regulator/tps65219-regulator.c:370:26: warning: ordered comparison of pointer with integer zero [-Wextra] 370 | if (rdev < 0) { | ^ sparse warning: drivers/regulator/tps65219-regulator.c:370:26: sparse: error: incompatible types for operation (<): drivers/regulator/tps65219-regulator.c:370:26: sparse: struct regulator_dev *[assigned] rdev drivers/regulator/tps65219-regulator.c:370:26: sparse: int Fixes: c12ac5fc3e0a ("regulator: drivers: Add TI TPS65219 PMIC regulators support") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Jerome Neanne <jneanne@baylibre.com> Cc: Tony Lindgren <tony@atomide.com> Cc: linux-omap@vger.kernel.org Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230114185736.2076-1-rdunlap@infradead.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-01-18regulator: da9211: Use irq handler when readyRicardo Ribalda1-5/+6
[ Upstream commit 02228f6aa6a64d588bc31e3267d05ff184d772eb ] If the system does not come from reset (like when it is kexec()), the regulator might have an IRQ waiting for us. If we enable the IRQ handler before its structures are ready, we crash. This patch fixes: [ 1.141839] Unable to handle kernel read from unreadable memory at virtual address 0000000000000078 [ 1.316096] Call trace: [ 1.316101] blocking_notifier_call_chain+0x20/0xa8 [ 1.322757] cpu cpu0: dummy supplies not allowed for exclusive requests [ 1.327823] regulator_notifier_call_chain+0x1c/0x2c [ 1.327825] da9211_irq_handler+0x68/0xf8 [ 1.327829] irq_thread+0x11c/0x234 [ 1.327833] kthread+0x13c/0x154 Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Adam Ward <DLG-Adam.Ward.opensource@dm.renesas.com> Link: https://lore.kernel.org/r/20221124-da9211-v2-0-1779e3c5d491@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31regulator: core: fix deadlock on regulator enableJohan Hovold1-1/+1
commit cb3543cff90a4448ed560ac86c98033ad5fecda9 upstream. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-31regulator: core: Fix resolve supply lookup issueChiYuan Huang1-1/+1
[ Upstream commit 0debed5b117d11e33cba52870c4dcb64f5911891 ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31regulator: core: Use different devices for resource allocation and DT lookupChiYuan Huang4-7/+7
[ Upstream commit 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31regulator: core: fix use_count leakage when handling boot-onRui Zhang1-1/+7
[ Upstream commit 0591b14ce0398125439c759f889647369aa616a0 ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31regulator: qcom-labibb: Fix missing of_node_put() in ↵Yuan Can1-0/+1
qcom_labibb_regulator_probe() [ Upstream commit cf34ac6aa2b12fb0c3aacfdcae8acd7904b949ec ] The reg_node needs to be released through of_node_put() in the error handling path when of_irq_get_byname() failed. Fixes: 390af53e0411 ("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.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31regulator: core: fix resource leak in regulator_register()Yang Yingliang1-0/+1
[ Upstream commit ba62319a42c50e6254e98b3f316464fac8e77968 ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31regulator: core: fix module refcount leak in set_supply()Yang Yingliang1-0/+1
[ Upstream commit da46ee19cbd8344d6860816b4827a7ce95764867 ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31regulator: core: use kfree_const() to free space conditionallyWang ShaoBo1-1/+1
[ Upstream commit dc8d006d15b623c1d80b90b45d6dcb6e890dad09 ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31regulator: qcom-rpmh: Fix PMR735a S3 regulator specKonrad Dybcio1-1/+1
[ Upstream commit dd801b2265c81bf0c8b0b4b8f7c1e7bfed078403 ] PMR735a has a wider range than previously defined. Fix it. Fixes: c4e5aa3dbee5 ("regulator: qcom-rpmh: Add PM7325/PMR735A regulator support") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20221110210706.80301-1-konrad.dybcio@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31regulator: core: fix unbalanced of node refcount in regulator_dev_lookup()Yang Yingliang1-0/+1
[ Upstream commit f2b41b748c19962b82709d9f23c6b2b0ce9d2f91 ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-11-26Merge tag 'regulator-fix-v6.1-rc6' of ↵Linus Torvalds4-6/+22
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-22regulator: twl6030: fix get status of twl6032 regulatorsAndreas Kemnade1-4/+11
Status is reported as always off in the 6032 case. Status reporting now matches the logic in the setters. Once of the differences to the 6030 is that there are no groups, therefore the state needs to be read out in the lower bits. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Link: https://lore.kernel.org/r/20221120221208.3093727-3-andreas@kemnade.info Signed-off-by: Mark Brown <broonie@kernel.org>
2022-11-22regulator: twl6030: re-add TWL6032_SUBCLASSAndreas Kemnade1-0/+2
In former times, info->feature was populated via the parent driver by pdata/regulator_init_data->driver_data for all regulators when USB_PRODUCT_ID_LSB indicates a TWL6032. Today, the information is not set, so re-add it at the regulator definitions. Fixes: 25d82337705e2 ("regulator: twl: make driver DT only") Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Link: https://lore.kernel.org/r/20221120221208.3093727-2-andreas@kemnade.info Signed-off-by: Mark Brown <broonie@kernel.org>
2022-11-18regulator: slg51000: Wait after asserting CS pinKonrad Dybcio1-0/+2
Sony's downstream driver [1], among some other changes, adds a seemingly random 10ms usleep_range, which turned out to be necessary for the hardware to function properly on at least Sony Xperia 1 IV. Without this, I2C transactions with the SLG51000 straight up fail. Relax (10-10ms -> 10-11ms) and add the aforementioned sleep to make sure the hardware has some time to wake up. (nagara-2.0.0-mlc/vendor/semc/hardware/camera-kernel-module/) [1] https://developer.sony.com/file/download/open-source-archive-for-64-0-m-4-29/ Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20221118131035.54874-1-konrad.dybcio@linaro.org 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: rt5759: fix OOB in validate_desc()Yang Yingliang1-0/+1
I got the following OOB report: BUG: KASAN: slab-out-of-bounds in validate_desc+0xba/0x109 Read of size 8 at addr ffff888107db8ff0 by task python3/253 Call Trace: <TASK> dump_stack_lvl+0x67/0x83 print_report+0x178/0x4b0 kasan_report+0x90/0x190 validate_desc+0xba/0x109 gpiod_set_value_cansleep+0x40/0x5a regulator_ena_gpio_ctrl+0x93/0xfc _regulator_do_enable.cold.61+0x89/0x163 set_machine_constraints+0x140a/0x159c regulator_register.cold.73+0x762/0x10cd devm_regulator_register+0x57/0xb0 rt5759_probe+0x3a0/0x4ac [rt5759_regulator] The desc used in validate_desc() is passed from 'reg_cfg.ena_gpiod', which is not initialized. Fix this by initializing 'reg_cfg' to 0. Fixes: 7b36ddb208bd ("regulator: rt5759: Add support for Richtek RT5759 DCDC converter") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20221116092943.1668326-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-10-07Merge tag 'mfd-next-6.1' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd Pull MFD updates from Lee Jones: "Core Frameworks: - Fix 'mfd_of_node_list' OF node entry resource leak New Drivers: - Add support for Ocelot VSC7512 Networking Chip - Add support for MediaTek MT6370 subPMIC - Add support for Richtek RT5120 (I2C) PMIC New Device Support: - Add support for Rockchip RV1126 and RK3588 to Syscon - Add support for Rockchip RK817 Battery Charger to RK808 - Add support for Silergy SY7636a Voltage Regulator to Simple MFD - Add support for Qualcomm PMP8074 PMIC to QCOM SPMI - Add support for Secure Update to Intel M10 BMC New Functionality: - Provide SSP type to Intel's LPSS (PCI) SPI driver Fix-ups: - Remove legacy / unused code; stmpe, intel_soc_pmic_crc, syscon - Unify / simplify; intel_soc_pmic_crc - Trivial reordering / spelling, etc; Makefile, twl-core - Convert to managed resources; intel_soc_pmic_crc - Use appropriate APIs; intel_soc_pmic_crc - strscpy() conversion; htc-i2cpld, lpc_ich, mfd-core - GPIOD conversion; htc-i2cpld, stmpe - Add missing header file includes; twl4030-irq - DT goodies; stmpe, mediatek,mt6370, x-powers,axp152, aspeed,ast2x00-scu, mediatek,mt8195-scpsys, qcom,spmi-pmic, syscon, qcom,tcsr, rockchip,rk817, sprd,ums512-glbreg, dlg,da9063 Bug Fixes: - Properly check return values; sm501, htc-i2cpld - Repair Two-Wire Bus Mode; da9062-core - Fix error handling; intel_soc_pmic_core, fsl-imx25-tsadc, lp8788, lp8788-irq" * tag 'mfd-next-6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (60 commits) mfd: syscon: Remove repetition of the regmap_get_val_endian() mfd: ocelot-spi: Add missing MODULE_DEVICE_TABLE power: supply: Add charger driver for Rockchip RK817 dt-bindings: mfd: mt6370: Fix the indentation in the example mfd: da9061: Fix Failed to set Two-Wire Bus Mode. mfd: htc-i2cpld: Fix an IS_ERR() vs NULL bug in htcpld_core_probe() dt-bindings: mfd: qcom,tcsr: Drop simple-mfd from IPQ6018 mfd: sm501: Add check for platform_driver_register() dt-bindings: mfd: mediatek: Add scpsys compatible for mt8186 mfd: twl4030: Add missed linux/device.h header dt-bindings: mfd: dlg,da9063: Add missing regulator patterns dt-bindings: mfd: sprd: Add bindings for ums512 global registers mfd: intel_soc_pmic_chtdc_ti: Switch from __maybe_unused to pm_sleep_ptr() etc dt-bindings: mfd: syscon: Add rk3588 QoS register compatible mfd: stmpe: Switch to using gpiod API mfd: qcom-spmi-pmic: Add pm7250b compatible dt-bindings: mfd: Add missing (unevaluated|additional)Properties on child nodes mfd/omap1: htc-i2cpld: Convert to a pure GPIO driver mfd: intel-m10-bmc: Add d5005 bmc secure update driver dt-bindings: mfd: syscon: Drop ref from reg-io-width ...
2022-10-05Merge tag 'regulator-v6.1' of ↵Linus Torvalds17-347/+2206
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-10-05Merge tag 'i2c-for-6.1-rc1' of ↵Linus Torvalds3-8/+3
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c updates from Wolfram Sang: - 'remove' callback converted to return void. Big change with trivial fixes all over the tree. Other subsystems depending on this change have been asked to pull an immutable topic branch for this. - new driver for Microchip PCI1xxxx switch - heavy refactoring of the Mellanox BlueField driver - we prefer async probe in the i801 driver now - the rest is usual driver updates (support for more SoCs, some refactoring, some feature additions) * tag 'i2c-for-6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (37 commits) i2c: pci1xxxx: prevent signed integer overflow i2c: acpi: Replace zero-length array with DECLARE_FLEX_ARRAY() helper i2c: i801: Prefer async probe i2c: designware-pci: Use standard pattern for memory allocation i2c: designware-pci: Group AMD NAVI quirk parts together i2c: microchip: pci1xxxx: Add driver for I2C host controller in multifunction endpoint of pci1xxxx switch docs: i2c: slave-interface: return errno when handle I2C_SLAVE_WRITE_REQUESTED i2c: mlxbf: remove device tree support i2c: mlxbf: support BlueField-3 SoC i2c: cadence: Add standard bus recovery support i2c: mlxbf: add multi slave functionality i2c: mlxbf: support lock mechanism macintosh/ams: Adapt declaration of ams_i2c_remove() to earlier change i2c: riic: Use devm_platform_ioremap_resource() i2c: mlxbf: remove IRQF_ONESHOT dt-bindings: i2c: rockchip: add rockchip,rk3128-i2c dt-bindings: i2c: renesas,rcar-i2c: Add r8a779g0 support i2c: tegra: Add GPCDMA support i2c: scmi: Convert to be a platform driver i2c: rk3x: Add rv1126 support ...
2022-10-04Merge tag 'thermal-6.1-rc1' of ↵Linus Torvalds1-5/+5
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull thermal control updates from Rafael Wysocki: "The most significant part of this update is the thermal control DT initialization rework from Daniel Lezcano and the following conversion of drivers to use the new API introduced by it Apart from that, the maximum number of trip points in a thermal zone is increased and there are some fixes and code cleanups Specifics: - Rework the device tree initialization, convert the drivers to the new API and remove the old OF code (Daniel Lezcano) - Fix return value to -ENODEV when searching for a specific thermal zone which does not exist (Daniel Lezcano) - Fix the return value inspection in of_thermal_zone_find() (Dan Carpenter) - Fix kernel panic when KASAN is enabled as it detects use after free when unregistering a thermal zone (Daniel Lezcano) - Move the set_trip ops inside the therma sysfs code (Daniel Lezcano) - Remove unnecessary error message as it is already shown in the underlying function (Jiapeng Chong) - Rework the monitoring path and move the locks upper in the call stack to fix some potentials race windows (Daniel Lezcano) - Fix lockdep_assert() warning introduced by the lock rework (Daniel Lezcano) - Do not lock thermal zone mutex in the user space governor (Rafael Wysocki) - Revert the Mellanox 'hotter thermal zone' feature because it is already handled in the thermal framework core code (Daniel Lezcano) - Increase maximum number of trip points in the thermal core (Sumeet Pawnikar) - Replace strlcpy() with unused retval with strscpy() in the core thermal control code (Wolfram Sang) - Use module_pci_driver() macro in the int340x processor_thermal driver (Shang XiaoJing) - Use get_cpu() instead of smp_processor_id() in the intel_powerclamp thermal driver to prevent it from crashing and remove unused accounting for IRQ wakes from it (Srinivas Pandruvada) - Consolidate priv->data_vault checks in int340x_thermal (Rafael Wysocki) - Check the policy first in cpufreq_cooling_register() (Xuewen Yan) - Drop redundant error message from da9062-thermal (zhaoxiao) - Drop of_match_ptr() from thermal_mmio (Jean Delvare)" * tag 'thermal-6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (55 commits) thermal: core: Increase maximum number of trip points thermal: int340x: processor_thermal: Use module_pci_driver() macro thermal: intel_powerclamp: Remove accounting for IRQ wakes thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash thermal: int340x_thermal: Consolidate priv->data_vault checks thermal: cpufreq_cooling: Check the policy first in cpufreq_cooling_register() thermal: Drop duplicate words from comments thermal: move from strlcpy() with unused retval to strscpy() thermal: da9062-thermal: Drop redundant error message thermal/drivers/thermal_mmio: Drop of_match_ptr() thermal: gov_user_space: Do not lock thermal zone mutex Revert "mlxsw: core: Add the hottest thermal zone detection" thermal/core: Fix lockdep_assert() warning thermal/core: Move the mutex inside the thermal_zone_device_update() function thermal/core: Move the thermal zone lock out of the governors thermal/governors: Group the thermal zone lock inside the throttle function thermal/core: Rework the monitoring a bit thermal/core: Rearm the monitoring only one time thermal/drivers/qcom/spmi-adc-tm5: Remove unnecessary print function dev_err() thermal/of: Remove old OF code ...
2022-09-29regulator: gpio: Add input_supply support in gpio_regulator_configJerome Neanne1-0/+15
This is simillar as fixed-regulator. Used to extract regulator parent from the device tree. Without that property used, the parent regulator can be shut down (if not an always on). Thus leading to inappropriate behavior: On am62-SP-SK this fix is required to avoid tps65219 ldo1 (SDMMC rail) to be shut down after boot completion. Signed-off-by: Jerome Neanne <jneanne@baylibre.com> Link: https://lore.kernel.org/r/20220929132526.29427-2-jneanne@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-28mfd: silergy,sy7636a: Add config option MFD_SY7636AAlistair Francis1-0/+1
Add a specific MFD_SY7636A config option. As part of this change we can use MFD_SY7636A as a dependency for all SY7636a components and also remove the name from MFD_SIMPLE_MFD_I2C as it no longer needs to be selectable. Signed-off-by: Alistair Francis <alistair@alistair23.me> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20220525115554.430971-2-alistair@alistair23.me
2022-09-26regulator: tps65219: Fix is_enabled checking in tps65219_set_bypassAxel Lin1-4/+2
Testing .enable cannot tell if a regulator is enabled or not, check return value of .is_enabled() instead. Also remove unneeded ret variable. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20220919122353.384171-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-23regulator: qcom-rpmh: add pm660 and pm660l pmicsRichard Acayan1-0/+54
The SDM630 and SDM660 both use RPM (not RPMh) for managing the PM660 and PM660L. The SDM670 uses RPMh to manage them as PMIC 4s. To support the SDM670, add the PM660 and PM660L to the RPMh regulator driver. Link: https://android.googlesource.com/kernel/msm/+/58064f13c0a436a82c35f2e3b5a122d874ae5846%5E%21/#F0 Link: https://android.googlesource.com/kernel/msm/+/f676d3d24f9d802bfe63369167c4a8cc162b8950%5E%21/#F3 Signed-off-by: Richard Acayan <mailingradian@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220920223331.150635-3-mailingradian@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-19regulator: of: Fix kernel-docJiapeng Chong1-1/+1
drivers/regulator/ti-abb-regulator.c:161: warning: expecting prototype for ti_abb_wait_tranx(). Prototype was for ti_abb_wait_txdone() instead. Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2206 Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Link: https://lore.kernel.org/r/20220919024830.111874-2-jiapeng.chong@linux.alibaba.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-19regulator: of: Fix kernel-docJiapeng Chong1-1/+1
drivers/regulator/of_regulator.c:689: warning: expecting prototype for of_parse_coupled regulator(). Prototype was for of_parse_coupled_regulator() instead. Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2205#c0 Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Link: https://lore.kernel.org/r/20220919024830.111874-1-jiapeng.chong@linux.alibaba.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-16Merge tag 'v6.0-rc5' into i2c/for-mergewindowWolfram Sang2-4/+9
Linux 6.0-rc5
2022-09-13MediaTek Helio X10 MT6795 - MT6331/6332 RegulatorsMark Brown4-0/+949
Merge series from AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>: In an effort to give some love to the apparently forgotten MT6795 SoC, I am upstreaming more components that are necessary to support platforms powered by this one apart from a simple boot to serial console. This series adds support for the regulators found in MT6331 and MT6332 main/companion PMICs. Adding support to each driver in each subsystem is done in different patch series as to avoid spamming uninteresting patches to maintainers. Tested on a MT6795 Sony Xperia M5 (codename "Holly") smartphone.
2022-09-13regulator: Add driver for MT6332 PMIC regulatorsAngeloGioacchino Del Regno3-0/+432
Add a driver for the regulators found in the MT6332 PMICs, including six buck and four LDO regulators. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220913123456.384513-5-angelogioacchino.delregno@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-13regulator: Add driver for MT6331 PMIC regulatorsAngeloGioacchino Del Regno3-0/+517
Add a driver for the regulators found in the MT6331 PMIC. This PMIC features six buck and 21 Low DropOut (LDO) regulators. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220913123456.384513-3-angelogioacchino.delregno@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-10regulator: tps65219: Fix .bypass_val_on settingAxel Lin1-1/+0
The .bypass_val_on setting does not match the .bypass_mask setting, so the .bypass_mask bit will never get set. Fix it by removing .bypass_val_on setting, the regulator_set_bypass_regmap and regulator_get_bypass_regmap helpers will use rdev->desc->bypass_mask as val_on if the val_on is 0. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20220828120153.1512508-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-10regulator: qcom_rpm: Fix circular deferral regressionLinus Walleij1-12/+12
On recent kernels, the PM8058 L16 (or any other PM8058 LDO-regulator) does not come up if they are supplied by an SMPS-regulator. This is not very strange since the regulators are registered in a long array and the L-regulators are registered before the S-regulators, and if an L-regulator defers, it will never get around to registering the S-regulator that it needs. See arch/arm/boot/dts/qcom-apq8060-dragonboard.dts: pm8058-regulators { (...) vdd_l13_l16-supply = <&pm8058_s4>; (...) Ooops. Fix this by moving the PM8058 S-regulators first in the array. Do the same for the PM8901 S-regulators (though this is currently not causing any problems with out device trees) so that the pattern of registration order is the same on all PMnnnn chips. Fixes: 087a1b5cdd55 ("regulator: qcom: Rework to single platform device") Cc: stable@vger.kernel.org Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <andersson@kernel.org> Cc: Konrad Dybcio <konrad.dybcio@somainline.org> Cc: linux-arm-msm@vger.kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20220909112529.239143-1-linus.walleij@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
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 Torvalds2-3/+8
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-09-05regulator: bd9576: switch to using devm_fwnode_gpiod_get()Dmitry Torokhov1-8/+9
I would like to stop exporting OF-specific devm_gpiod_get_from_of_node() so that gpiolib can be cleaned a bit, so let's switch to the generic fwnode property API. While at it switch the rest of the calls to read properties in bd957x_probe() to the generic device property API as well. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/20220903-gpiod_get_from_of_node-remove-v1-9-b29adfb27a6c@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-05regulator: bd71815: switch to using devm_fwnode_gpiod_get()Dmitry Torokhov1-4/+3
I would like to stop exporting OF-specific devm_gpiod_get_from_of_node() so that gpiolib can be cleaned a bit, so let's switch to the generic fwnode property API. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/20220903-gpiod_get_from_of_node-remove-v1-8-b29adfb27a6c@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
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-29regulator: tps65219: change tps65219_regulator_irq_types to staticYang Yingliang1-1/+1
tps65219_regulator_irq_types is only used in tps65219-regulator.c now, change it to static. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20220826061941.1814723-1-yangyingliang@huawei.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-25regulator: drivers: Remove unnecessary print function dev_err()Yang Li1-4/+2
The print function dev_err() is redundant because platform_get_irq_byname() already prints an error. Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=1986 Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Link: https://lore.kernel.org/r/20220825070438.128093-1-yang.lee@linux.alibaba.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-25regulator: pfuze100: Fix the global-out-of-bounds access in ↵Xiaolei Wang1-1/+1
pfuze100_regulator_probe() The pfuze_chip::regulator_descs is an array of size PFUZE100_MAX_REGULATOR, the pfuze_chip::pfuze_regulators is the pointer to the real regulators of a specific device. The number of real regulator is supposed to be less than the PFUZE100_MAX_REGULATOR, so we should use the size of 'regulator_num * sizeof(struct pfuze_regulator)' in memcpy(). This fixes the out of bounds access bug reported by KASAN. Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com> Link: https://lore.kernel.org/r/20220825111922.1368055-1-xiaolei.wang@windriver.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-24Merge tag 'thermal-v6.1-rc1' of ↵Rafael J. Wysocki1-5/+5
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/thermal/linux Pull thermal control changes for v6.1-rc1 from Daniel Lezcano: "- Rework the device tree initialization, convert the drivers to the new API and remove the old OF code (Daniel Lezcano) - Fix return value to -ENODEV when searching for a specific thermal zone which does not exist (Daniel Lezcano) - Fix the return value inspection in of_thermal_zone_find() (Dan Carpenter) - Fix kernel panic when KASAN is enabled as it detects use after free when unregistering a thermal zone (Daniel Lezcano) - Move the set_trip ops inside the therma sysfs code (Daniel Lezcano) - Remove unnecessary error message as it is already showed in the underlying function (Jiapeng Chong) - Rework the monitoring path and move the locks upper in the call stack to fix some potentials race windows (Daniel Lezcano) - Fix lockdep_assert() warning introduced by the lock rework (Daniel Lezcano) - Revert the Mellanox 'hotter thermal zone' feature because it is already handled in the thermal framework core code (Daniel Lezcano)" * tag 'thermal-v6.1-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/thermal/linux: (46 commits) Revert "mlxsw: core: Add the hottest thermal zone detection" thermal/core: Fix lockdep_assert() warning thermal/core: Move the mutex inside the thermal_zone_device_update() function thermal/core: Move the thermal zone lock out of the governors thermal/governors: Group the thermal zone lock inside the throttle function thermal/core: Rework the monitoring a bit thermal/core: Rearm the monitoring only one time thermal/drivers/qcom/spmi-adc-tm5: Remove unnecessary print function dev_err() thermal/of: Remove old OF code thermal/core: Move set_trip_temp ops to the sysfs code thermal/drivers/samsung: Switch to new of thermal API regulator/drivers/max8976: Switch to new of thermal API Input: sun4i-ts - switch to new of thermal API iio/drivers/sun4i_gpadc: Switch to new of thermal API hwmon/drivers/core: Switch to new of thermal API hwmon: pm_bus: core: Switch to new of thermal API ata/drivers/ahci_imx: Switch to new of thermal API thermal/drivers/ti-soc: Switch to new of API thermal/drivers/hisilicon: Switch to new of API thermal/drivers/maxim: Switch to new of API ...
generated by cgit v1.2.3 (git 2.39.0) at 2025-01-24 15:34:11 +0300