summaryrefslogtreecommitdiffstats
path: root/drivers/regulator
Commit message (Collapse)AuthorAgeFilesLines
* regulator: vctrl: Avoid lockdep warning in enable/disable opsChen-Yu Tsai2021-09-151-30/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 21e39809fd7c4b8ff3662f23e0168e87594c8ca8 ] vctrl_enable() and vctrl_disable() call regulator_enable() and regulator_disable(), respectively. However, vctrl_* are regulator ops and should not be calling the locked regulator APIs. Doing so results in a lockdep warning. Instead of exporting more internal regulator ops, model the ctrl supply as an actual supply to vctrl-regulator. At probe time this driver still needs to use the consumer API to fetch its constraints, but otherwise lets the regulator core handle the upstream supply for it. The enable/disable/is_enabled ops are not removed, but now only track state internally. This preserves the original behavior with the ops being available, but one could argue that the original behavior was already incorrect: the internal state would not match the upstream supply if that supply had another consumer that enabled the supply, while vctrl-regulator was not enabled. The lockdep warning is as follows: WARNING: possible circular locking dependency detected 5.14.0-rc6 #2 Not tainted ------------------------------------------------------ swapper/0/1 is trying to acquire lock: ffffffc011306d00 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent (arch/arm64/include/asm/current.h:19 include/linux/ww_mutex.h:111 drivers/regulator/core.c:329) but task is already holding lock: ffffff8004a77160 (regulator_ww_class_mutex){+.+.}-{3:3}, at: regulator_lock_recursive (drivers/regulator/core.c:156 drivers/regulator/core.c:263) which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (regulator_ww_class_mutex){+.+.}-{3:3}: __mutex_lock_common (include/asm-generic/atomic-instrumented.h:606 include/asm-generic/atomic-long.h:29 kernel/locking/mutex.c:103 kernel/locking/mutex.c:144 kernel/locking/mutex.c:963) ww_mutex_lock (kernel/locking/mutex.c:1199) regulator_lock_recursive (drivers/regulator/core.c:156 drivers/regulator/core.c:263) regulator_lock_dependent (drivers/regulator/core.c:343) regulator_enable (drivers/regulator/core.c:2808) set_machine_constraints (drivers/regulator/core.c:1536) regulator_register (drivers/regulator/core.c:5486) devm_regulator_register (drivers/regulator/devres.c:196) reg_fixed_voltage_probe (drivers/regulator/fixed.c:289) platform_probe (drivers/base/platform.c:1427) [...] -> #1 (regulator_ww_class_acquire){+.+.}-{0:0}: regulator_lock_dependent (include/linux/ww_mutex.h:129 drivers/regulator/core.c:329) regulator_enable (drivers/regulator/core.c:2808) set_machine_constraints (drivers/regulator/core.c:1536) regulator_register (drivers/regulator/core.c:5486) devm_regulator_register (drivers/regulator/devres.c:196) reg_fixed_voltage_probe (drivers/regulator/fixed.c:289) [...] -> #0 (regulator_list_mutex){+.+.}-{3:3}: __lock_acquire (kernel/locking/lockdep.c:3052 (discriminator 4) kernel/locking/lockdep.c:3174 (discriminator 4) kernel/locking/lockdep.c:3789 (discriminator 4) kernel/locking/lockdep.c:5015 (discriminator 4)) lock_acquire (arch/arm64/include/asm/percpu.h:39 kernel/locking/lockdep.c:438 kernel/locking/lockdep.c:5627) __mutex_lock_common (include/asm-generic/atomic-instrumented.h:606 include/asm-generic/atomic-long.h:29 kernel/locking/mutex.c:103 kernel/locking/mutex.c:144 kernel/locking/mutex.c:963) mutex_lock_nested (kernel/locking/mutex.c:1125) regulator_lock_dependent (arch/arm64/include/asm/current.h:19 include/linux/ww_mutex.h:111 drivers/regulator/core.c:329) regulator_enable (drivers/regulator/core.c:2808) vctrl_enable (drivers/regulator/vctrl-regulator.c:400) _regulator_do_enable (drivers/regulator/core.c:2617) _regulator_enable (drivers/regulator/core.c:2764) regulator_enable (drivers/regulator/core.c:308 drivers/regulator/core.c:2809) _set_opp (drivers/opp/core.c:819 drivers/opp/core.c:1072) dev_pm_opp_set_rate (drivers/opp/core.c:1164) set_target (drivers/cpufreq/cpufreq-dt.c:62) __cpufreq_driver_target (drivers/cpufreq/cpufreq.c:2216 drivers/cpufreq/cpufreq.c:2271) cpufreq_online (drivers/cpufreq/cpufreq.c:1488 (discriminator 2)) cpufreq_add_dev (drivers/cpufreq/cpufreq.c:1563) subsys_interface_register (drivers/base/bus.c:?) cpufreq_register_driver (drivers/cpufreq/cpufreq.c:2819) dt_cpufreq_probe (drivers/cpufreq/cpufreq-dt.c:344) [...] other info that might help us debug this: Chain exists of: regulator_list_mutex --> regulator_ww_class_acquire --> regulator_ww_class_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(regulator_ww_class_mutex); lock(regulator_ww_class_acquire); lock(regulator_ww_class_mutex); lock(regulator_list_mutex); *** DEADLOCK *** 6 locks held by swapper/0/1: #0: ffffff8002d32188 (&dev->mutex){....}-{3:3}, at: __device_driver_lock (drivers/base/dd.c:1030) #1: ffffffc0111a0520 (cpu_hotplug_lock){++++}-{0:0}, at: cpufreq_register_driver (drivers/cpufreq/cpufreq.c:2792 (discriminator 2)) #2: ffffff8002a8d918 (subsys mutex#9){+.+.}-{3:3}, at: subsys_interface_register (drivers/base/bus.c:1033) #3: ffffff800341bb90 (&policy->rwsem){+.+.}-{3:3}, at: cpufreq_online (include/linux/bitmap.h:285 include/linux/cpumask.h:405 drivers/cpufreq/cpufreq.c:1399) #4: ffffffc011f0b7b8 (regulator_ww_class_acquire){+.+.}-{0:0}, at: regulator_enable (drivers/regulator/core.c:2808) #5: ffffff8004a77160 (regulator_ww_class_mutex){+.+.}-{3:3}, at: regulator_lock_recursive (drivers/regulator/core.c:156 drivers/regulator/core.c:263) stack backtrace: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc6 #2 7c8f8996d021ed0f65271e6aeebf7999de74a9fa Hardware name: Google Scarlet (DT) Call trace: dump_backtrace (arch/arm64/kernel/stacktrace.c:161) show_stack (arch/arm64/kernel/stacktrace.c:218) dump_stack_lvl (lib/dump_stack.c:106 (discriminator 2)) dump_stack (lib/dump_stack.c:113) print_circular_bug (kernel/locking/lockdep.c:?) check_noncircular (kernel/locking/lockdep.c:?) __lock_acquire (kernel/locking/lockdep.c:3052 (discriminator 4) kernel/locking/lockdep.c:3174 (discriminator 4) kernel/locking/lockdep.c:3789 (discriminator 4) kernel/locking/lockdep.c:5015 (discriminator 4)) lock_acquire (arch/arm64/include/asm/percpu.h:39 kernel/locking/lockdep.c:438 kernel/locking/lockdep.c:5627) __mutex_lock_common (include/asm-generic/atomic-instrumented.h:606 include/asm-generic/atomic-long.h:29 kernel/locking/mutex.c:103 kernel/locking/mutex.c:144 kernel/locking/mutex.c:963) mutex_lock_nested (kernel/locking/mutex.c:1125) regulator_lock_dependent (arch/arm64/include/asm/current.h:19 include/linux/ww_mutex.h:111 drivers/regulator/core.c:329) regulator_enable (drivers/regulator/core.c:2808) vctrl_enable (drivers/regulator/vctrl-regulator.c:400) _regulator_do_enable (drivers/regulator/core.c:2617) _regulator_enable (drivers/regulator/core.c:2764) regulator_enable (drivers/regulator/core.c:308 drivers/regulator/core.c:2809) _set_opp (drivers/opp/core.c:819 drivers/opp/core.c:1072) dev_pm_opp_set_rate (drivers/opp/core.c:1164) set_target (drivers/cpufreq/cpufreq-dt.c:62) __cpufreq_driver_target (drivers/cpufreq/cpufreq.c:2216 drivers/cpufreq/cpufreq.c:2271) cpufreq_online (drivers/cpufreq/cpufreq.c:1488 (discriminator 2)) cpufreq_add_dev (drivers/cpufreq/cpufreq.c:1563) subsys_interface_register (drivers/base/bus.c:?) cpufreq_register_driver (drivers/cpufreq/cpufreq.c:2819) dt_cpufreq_probe (drivers/cpufreq/cpufreq-dt.c:344) [...] Reported-by: Brian Norris <briannorris@chromium.org> Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") Fixes: e9153311491d ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20210825033704.3307263-3-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: vctrl: Use locked regulator_get_voltage in probe pathChen-Yu Tsai2021-09-151-1/+2
| | | | | | | | | | | | | | | | | | | [ Upstream commit 98e47570ba985f2310586c80409238200fa3170f ] In commit e9153311491d ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage"), all calls to get/set the voltage of the control regulator were switched to unlocked versions to avoid deadlocks. However, the call in the probe path is done without regulator locks held. In this case the locked version should be used. Switch back to the locked regulator_get_voltage() in the probe path to avoid any mishaps. Fixes: e9153311491d ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20210825033704.3307263-2-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: hi6421: Fix getting wrong drvdataAxel Lin2021-07-281-9/+13
| | | | | | | | | | | | | | | | | | [ Upstream commit 1c73daee4bf30ccdff5e86dc400daa6f74735da5 ] Since config.dev = pdev->dev.parent in current code, so dev_get_drvdata(rdev->dev.parent) call in hi6421_regulator_enable returns the drvdata of the mfd device rather than the regulator. Fix it. This was broken while converting to use simplified DT parsing because the config.dev changed from pdev->dev to pdev->dev.parent for parsing the parent's of_node. Fixes: 29dc269a85ef ("regulator: hi6421: Convert to use simplified DT parsing") Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210630095959.2411543-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: hi6421: Use correct variable type for regmap api val argumentAxel Lin2021-07-281-4/+4
| | | | | | | | | | | | [ Upstream commit ae60e6a9d24e89a74e2512204ad04de94921bdd2 ] Use unsigned int instead of u32 for regmap_read/regmap_update_bits val argument. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210619124133.4096683-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: hi655x: Fix pass wrong pointer to config.driver_dataAxel Lin2021-07-141-11/+5
| | | | | | | | | | | | | [ Upstream commit 61eb1b24f9e4f4e0725aa5f8164a932c933f3339 ] Current code sets config.driver_data to a zero initialized regulator which is obviously wrong. Fix it. Fixes: 4618119b9be5 ("regulator: hi655x: enable regulator for hi655x PMIC") Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210620132715.60215-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: da9052: Ensure enough delay time for .set_voltage_time_selAxel Lin2021-07-141-1/+2
| | | | | | | | | | | | | | [ Upstream commit a336dc8f683e5be794186b5643cd34cb28dd2c53 ] Use DIV_ROUND_UP to prevent truncation by integer division issue. This ensures we return enough delay time. Also fix returning negative value when new_sel < old_sel. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210618141412.4014912-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: mt6358: Fix vdram2 .vsel_maskHsin-Hsiung Wang2021-07-141-1/+1
| | | | | | | | | | | | [ Upstream commit 50c9462edcbf900f3d5097ca3ad60171346124de ] The valid vsel value are 0 and 12, so the .vsel_mask should be 0xf. Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com> Reviewed-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/1624424169-510-1-git-send-email-hsin-hsiung.wang@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: uniphier: Add missing MODULE_DEVICE_TABLEZou Wei2021-07-141-0/+1
| | | | | | | | | | | | | | [ Upstream commit d019f38a1af3c6015cde6a47951a3ec43beeed80 ] This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Link: https://lore.kernel.org/r/1620705198-104566-1-git-send-email-zou_wei@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: max77620: Use device_set_of_node_from_dev()Dmitry Osipenko2021-06-161-0/+7
| | | | | | | | | | | | | | | | commit 6f55c5dd1118b3076d11d9cb17f5c5f4bc3a1162 upstream. The MAX77620 driver fails to re-probe on deferred probe because driver core tries to claim resources that are already claimed by the PINCTRL device. Use device_set_of_node_from_dev() helper which marks OF node as reused, skipping erroneous execution of pinctrl_bind_pins() for the PMIC device on the re-probe. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20210523224243.13219-2-digetx@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: core: resolve supply for boot-on/always-on regulatorsDmitry Baryshkov2021-06-161-0/+6
| | | | | | | | | | | | | | | commit 98e48cd9283dbac0e1445ee780889f10b3d1db6a upstream. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: bd9571mwv: Fix AVS and DVFS voltage rangeGeert Uytterhoeven2021-04-141-2/+2
| | | | | | | | | | | | | | | | | [ Upstream commit 3b6e7088afc919f5b52e4d2de8501ad34d35b09b ] According to Table 30 ("DVFS_MoniVDAC [6:0] Setting Table") in the BD9571MWV-M Datasheet Rev. 002, the valid voltage range is 600..1100 mV (settings 0x3c..0x6e). While the lower limit is taken into account (by setting regulator_desc.linear_min_sel to 0x3c), the upper limit is not. Fix this by reducing regulator_desc.n_voltages from 0x80 to 0x6f. Fixes: e85c5a153fe237f2 ("regulator: Add ROHM BD9571MWV-M PMIC regulator driver") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210312130242.3390038-2-geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: qcom-rpmh: Correct the pmic5_hfsmps515 bucksatya priya2021-03-301-2/+2
| | | | | | | | | | | | [ Upstream commit e610e072c87a30658479a7b4c51e1801cb3f450c ] Correct the REGULATOR_LINEAR_RANGE and n_voltges for pmic5_hfsmps515 buck. Signed-off-by: satya priya <skakit@codeaurora.org> Link: https://lore.kernel.org/r/1614155592-14060-4-git-send-email-skakit@codeaurora.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: qcom-rpmh: fix pm8009 ldo7Jonathan Marek2021-03-041-1/+1
| | | | | | | | | | | | | [ Upstream commit 20ccc362c3d20da734af896e075b74222589f2c0 ] Use the correct name to avoid ldo7 commands being sent to ldo6's address. Fixes: 06369bcc15a1 ("regulator: qcom-rpmh: Add support for SM8150") Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20210211034935.5622-1-jonathan@marek.ca Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: core: Avoid debugfs: Directory ... already present! errorHans de Goede2021-03-041-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit dbe954d8f1635f949a1d9a5d6e6fb749ae022b47 ] Sometimes regulator_get() gets called twice for the same supply on the same device. This may happen e.g. when a framework / library is used which uses the regulator; and the driver itself also needs to enable the regulator in some cases where the framework will not enable it. Commit ff268b56ce8c ("regulator: core: Don't spew backtraces on duplicate sysfs") already takes care of the backtrace which would trigger when creating a duplicate consumer symlink under /sys/class/regulator/regulator.%d in this scenario. Commit c33d442328f5 ("debugfs: make error message a bit more verbose") causes a new error to get logged in this scenario: [ 26.938425] debugfs: Directory 'wm5102-codec-MICVDD' with parent 'spi-WM510204:00-MICVDD' already present! There is no _nowarn variant of debugfs_create_dir(), but we can detect and avoid this problem by checking the return value of the earlier sysfs_create_link_nowarn() call. Add a check for the earlier sysfs_create_link_nowarn() failing with -EEXIST and skip the debugfs_create_dir() call in that case, avoiding this error getting logged. Fixes: c33d442328f5 ("debugfs: make error message a bit more verbose") Cc: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20210122183250.370571-1-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: s5m8767: Drop regulators OF node referenceKrzysztof Kozlowski2021-03-041-2/+6
| | | | | | | | | | | | | [ Upstream commit a5872bd3398d0ff2ce4c77794bc7837899c69024 ] The device node reference obtained with of_get_child_by_name() should be dropped on error paths. Fixes: 26aec009f6b6 ("regulator: add device tree support for s5m8767") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20210121155914.48034-1-krzk@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: s5m8767: Fix reference count leakPan Bian2021-03-041-2/+5
| | | | | | | | | | | | | | [ Upstream commit dea6dd2ba63f8c8532addb8f32daf7b89a368a42 ] Call of_node_put() to drop references of regulators_np and reg_np before returning error code. Fixes: 9ae5cc75ceaa ("regulator: s5m8767: Pass descriptor instead of GPIO number") Signed-off-by: Pan Bian <bianpan2016@163.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20210121032756.49501-1-bianpan2016@163.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: axp20x: Fix reference cout leakPan Bian2021-03-041-4/+3
| | | | | | | | | | | | [ Upstream commit e78bf6be7edaacb39778f3a89416caddfc6c6d70 ] Decrements the reference count of device node and its child node. Fixes: dfe7a1b058bb ("regulator: AXP20x: Add support for regulators subsystem") Signed-off-by: Pan Bian <bianpan2016@163.com> Link: https://lore.kernel.org/r/20210120123313.107640-1-bianpan2016@163.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: Fix lockdep warning resolving suppliesMark Brown2021-02-131-12/+17
| | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 14a71d509ac809dcf56d7e3ca376b15d17bd0ddd ] With commit eaa7995c529b54 (regulator: core: avoid regulator_resolve_supply() race condition) we started holding the rdev lock while resolving supplies, an operation that requires holding the regulator_list_mutex. This results in lockdep warnings since in other places we take the list mutex then the mutex on an individual rdev. Since the goal is to make sure that we don't call set_supply() twice rather than a concern about the cost of resolution pull the rdev lock and check for duplicate resolution down to immediately before we do the set_supply() and drop it again once the allocation is done. Fixes: eaa7995c529b54 (regulator: core: avoid regulator_resolve_supply() race condition) Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210122132042.10306-1-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: core: avoid regulator_resolve_supply() race conditionDavid Collins2021-02-131-11/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit eaa7995c529b54d68d97a30f6344cc6ca2f214a7 ] The final step in regulator_register() is to call regulator_resolve_supply() for each registered regulator (including the one in the process of being registered). The regulator_resolve_supply() function first checks if rdev->supply is NULL, then it performs various steps to try to find the supply. If successful, rdev->supply is set inside of set_supply(). This procedure can encounter a race condition if two concurrent tasks call regulator_register() near to each other on separate CPUs and one of the regulators has rdev->supply_name specified. There is currently nothing guaranteeing atomicity between the rdev->supply check and set steps. Thus, both tasks can observe rdev->supply==NULL in their regulator_resolve_supply() calls. This then results in both creating a struct regulator for the supply. One ends up actually stored in rdev->supply and the other is lost (though still present in the supply's consumer_list). Here is a kernel log snippet showing the issue: [ 12.421768] gpu_cc_gx_gdsc: supplied by pm8350_s5_level [ 12.425854] gpu_cc_gx_gdsc: supplied by pm8350_s5_level [ 12.429064] debugfs: Directory 'regulator.4-SUPPLY' with parent '17a00000.rsc:rpmh-regulator-gfxlvl-pm8350_s5_level' already present! Avoid this race condition by holding the rdev->mutex lock inside of regulator_resolve_supply() while checking and setting rdev->supply. Signed-off-by: David Collins <collinsd@codeaurora.org> Link: https://lore.kernel.org/r/1610068562-4410-1-git-send-email-collinsd@codeaurora.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: bd718x7: Add enable timesGuido Günther2021-01-191-0/+57
| | | | | | | | | | | | | | | | | | | [ Upstream commit 3b66e4a8e58a85af3212c7117d7a29c9ef6679a2 ] Use the typical startup times from the data sheet so boards get a reasonable default. Not setting any enable time can lead to board hangs when e.g. clocks are enabled too soon afterwards. This fixes gpu power domain resume on the Librem 5. [Moved #defines into driver, seems to be general agreement and avoids any cross tree issues -- broonie] Signed-off-by: Guido Günther <agx@sigxcpu.org> Reviewed-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/41fb2ed19f584f138336344e2297ae7301f72b75.1608316658.git.agx@sigxcpu.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: qcom-rpmh-regulator: correct hfsmps515 definitionDmitry Baryshkov2021-01-171-1/+1
| | | | | | | | | | | | | | | commit df6b92fa40050e59ea89784294bf6d04c0c47705 upstream. According to the datasheet pm8009's HFS515 regulators have 16mV resolution rather than declared 1.6 mV. Correct the resolution. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Fixes: 06369bcc15a1 ("regulator: qcom-rpmh: Add support for SM8150") Reviewed-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20201231122348.637917-3-dmitry.baryshkov@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: axp20x: Fix DLDO2 voltage control register mask for AXP22xDingHua Ma2020-12-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | commit 291de1d102fafef0798cdad9666cd4f8da7da7cc upstream. When I use the axp20x chip to power my SDIO device on the 5.4 kernel, the output voltage of DLDO2 is wrong. After comparing the register manual and source code of the chip, I found that the mask bit of the driver register of the port was wrong. I fixed this error by modifying the mask register of the source code. This error seems to be a copy error of the macro when writing the code. Now the voltage output of the DLDO2 port of axp20x is correct. My development environment is Allwinner A40I of arm architecture, and the kernel version is 5.4. Signed-off-by: DingHua Ma <dinghua.ma.sz@gmail.com> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Cc: <stable@vger.kernel.org> Fixes: db4a555f7c4c ("regulator: axp20x: use defines for masks") Link: https://lore.kernel.org/r/20201201001000.22302-1-dinghua.ma.sz@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: workaround self-referent regulatorsMichał Mirosław2020-11-241-1/+4
| | | | | | | | | | | | | | | | | | | commit f5c042b23f7429e5c2ac987b01a31c69059a978b upstream. Workaround regulators whose supply name happens to be the same as its own name. This fixes boards that used to work before the early supply resolving was removed. The error message is left in place so that offending drivers can be detected. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable@vger.kernel.org Reported-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # stpmic1 Link: https://lore.kernel.org/r/d703acde2a93100c3c7a81059d716c50ad1b1f52.1605226675.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: avoid resolve_supply() infinite recursionMichał Mirosław2020-11-241-0/+6
| | | | | | | | | | | | | | | | | | | commit 4b639e254d3d4f15ee4ff2b890a447204cfbeea9 upstream. When a regulator's name equals its supply's name the regulator_resolve_supply() recurses indefinitely. Add a check so that debugging the problem is easier. The "fixed" commit just exposed the problem. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable@vger.kernel.org Reported-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # stpmic1 Link: https://lore.kernel.org/r/c6171057cfc0896f950c4d8cb82df0f9f1b89ad9.1605226675.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: fix memory leak with repeated set_machine_constraints()Michał Mirosław2020-11-241-16/+13
| | | | | | | | | | | | | | | | | | commit 57a6ad482af256b2a13de14194fb8f67c1a65f10 upstream. Fixed commit introduced a possible second call to set_machine_constraints() and that allocates memory for rdev->constraints. Move the allocation to the caller so it's easier to manage and done once. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable@vger.kernel.org Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # stpmic1 Link: https://lore.kernel.org/r/78c3d4016cebc08d441aad18cb924b4e4d9cf9df.1605226675.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: pfuze100: limit pfuze-support-disable-sw to pfuze{100,200}Sean Nyekjaer2020-11-241-5/+8
| | | | | | | | | | | | | | | | | | commit 365ec8b61689bd64d6a61e129e0319bf71336407 upstream. Limit the fsl,pfuze-support-disable-sw to the pfuze100 and pfuze200 variants. When enabling fsl,pfuze-support-disable-sw and using a pfuze3000 or pfuze3001, the driver would choose pfuze100_sw_disable_regulator_ops instead of the newly introduced and correct pfuze3000_sw_regulator_ops. Signed-off-by: Sean Nyekjaer <sean@geanix.com> Fixes: 6f1cf5257acc ("regualtor: pfuze100: correct sw1a/sw2 on pfuze3000") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20201110174113.2066534-1-sean@geanix.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: ti-abb: Fix array out of bound read access on the first transitionNishanth Menon2020-11-241-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 2ba546ebe0ce2af47833d8912ced9b4a579f13cb ] At the start of driver initialization, we do not know what bias setting the bootloader has configured the system for and we only know for certain the very first time we do a transition. However, since the initial value of the comparison index is -EINVAL, this negative value results in an array out of bound access on the very first transition. Since we don't know what the setting is, we just set the bias configuration as there is nothing to compare against. This prevents the array out of bound access. NOTE: Even though we could use a more relaxed check of "< 0" the only valid values(ignoring cosmic ray induced bitflips) are -EINVAL, 0+. Fixes: 40b1936efebd ("regulator: Introduce TI Adaptive Body Bias(ABB) on-chip LDO driver") Link: https://lore.kernel.org/linux-mm/CA+G9fYuk4imvhyCN7D7T6PMDH6oNp6HDCRiTUKMQ6QXXjBa4ag@mail.gmail.com/ Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20201118145009.10492-1-nm@ti.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: defer probe when trying to get voltage from unresolved supplyMichał Mirosław2020-11-101-0/+2
| | | | | | | | | | | | | | | | | | | | | commit cf1ad559a20d1930aa7b47a52f54e1f8718de301 upstream. regulator_get_voltage_rdev() is called in regulator probe() when applying machine constraints. The "fixed" commit exposed the problem that non-bypassed regulators can forward the request to its parent (like bypassed ones) supply. Return -EPROBE_DEFER when the supply is expected but not resolved yet. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable@vger.kernel.org Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Reported-by: Ondřej Jirman <megous@megous.com> Reported-by: Corentin Labbe <clabbe.montjoie@gmail.com> Tested-by: Ondřej Jirman <megous@megous.com> Link: https://lore.kernel.org/r/a9041d68b4d35e4a2dd71629c8a6422662acb5ee.1604351936.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: resolve supply after creating regulatorMichał Mirosław2020-10-291-8/+13
| | | | | | | | | | | | | | | | | | | | [ Upstream commit aea6cb99703e17019e025aa71643b4d3e0a24413 ] When creating a new regulator its supply cannot create the sysfs link because the device is not yet published. Remove early supply resolving since it will be done later anyway. This makes the following error disappear and the symlinks get created instead. DCDC_REG1: supplied by VSYS VSYS: could not add device link regulator.3 err -2 Note: It doesn't fix the problem for bypassed regulators, though. Fixes: 45389c47526d ("regulator: core: Add early supply resolution for regulators") Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/ba09e0a8617ffeeb25cb4affffe6f3149319cef8.1601155770.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: axp20x: fix LDO2/4 descriptionIcenowy Zheng2020-10-011-3/+4
| | | | | | | | | | | | | | | | [ Upstream commit fbb5a79d2fe7b01c6424fbbc04368373b1672d61 ] Currently we wrongly set the mask of value of LDO2/4 both to the mask of LDO2, and the LDO4 voltage configuration is left untouched. This leads to conflict when LDO2/4 are both in use. Fix this issue by setting different vsel_mask to both regulators. Fixes: db4a555f7c4c ("regulator: axp20x: use defines for masks") Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Link: https://lore.kernel.org/r/20200923005142.147135-1-icenowy@aosc.io Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: pwm: Fix machine constraints applicationVincent Whitchurch2020-09-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 59ae97a7a9e1499c2070e29841d1c4be4ae2994a ] If the zero duty cycle doesn't correspond to any voltage in the voltage table, the PWM regulator returns an -EINVAL from get_voltage_sel() which results in the core erroring out with a "failed to get the current voltage" and ending up not applying the machine constraints. Instead, return -ENOTRECOVERABLE which makes the core set the voltage since it's at an unknown value. For example, with this device tree: fooregulator { compatible = "pwm-regulator"; pwms = <&foopwm 0 100000>; regulator-min-microvolt = <2250000>; regulator-max-microvolt = <2250000>; regulator-name = "fooregulator"; regulator-always-on; regulator-boot-on; voltage-table = <2250000 30>; }; Before this patch: fooregulator: failed to get the current voltage(-22) After this patch: fooregulator: Setting 2250000-2250000uV fooregulator: 2250 mV Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Link: https://lore.kernel.org/r/20200902130952.24880-1-vincent.whitchurch@axis.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: core: Fix slab-out-of-bounds in regulator_unlock_recursive()Dmitry Osipenko2020-09-171-6/+9
| | | | | | | | | | | | | | | | | | | | commit 0a7416f94707c60b9f66b01c0a505b7e41375f3a upstream. The recent commit 7d8196641ee1 ("regulator: Remove pointer table overallocation") changed the size of coupled_rdevs and now KASAN is able to detect slab-out-of-bounds problem in regulator_unlock_recursive(), which is a legit problem caused by a typo in the code. The recursive unlock function uses n_coupled value of a parent regulator for unlocking supply regulator, while supply's n_coupled should be used. In practice problem may only affect platforms that use coupled regulators. Cc: stable@vger.kernel.org # 5.0+ Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20200831204335.19489-1-digetx@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: plug of_node leak in regulator_register()'s error pathMichał Mirosław2020-09-171-9/+4
| | | | | | | | | | | | | | | | | | commit d3c731564e09b6c2ebefcd1344743a91a237d6dc upstream. By calling device_initialize() earlier and noting that kfree(NULL) is ok, we can save a bit of code in error handling and plug of_node leak. Fixed commit already did part of the work. Fixes: 9177514ce349 ("regulator: fix memory leak on error path of regulator_register()") Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com> Acked-by: Vladimir Zapolskiy <vz@mleia.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/f5035b1b4d40745e66bacd571bbbb5e4644d21a1.1597195321.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: push allocation in set_consumer_device_supply() out of lockMichał Mirosław2020-09-171-20/+26
| | | | | | | | | | | | | | | commit 5c06540165d443c6455123eb48e7f1a9b618ab34 upstream. Pull regulator_list_mutex into set_consumer_device_supply() and keep allocations outside of it. Fourth of the fs_reclaim deadlock case. Fixes: 45389c47526d ("regulator: core: Add early supply resolution for regulators") Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/f0380bdb3d60aeefa9693c4e234d2dcda7e56747.1597195321.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: push allocations in create_regulator() outside of lockMichał Mirosław2020-09-171-25/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 87fe29b61f9522a3d7b60a4580851f548558186f upstream. Move all allocations outside of the regulator_lock()ed section. ====================================================== WARNING: possible circular locking dependency detected 5.7.13+ #535 Not tainted ------------------------------------------------------ f2fs_discard-179:7/702 is trying to acquire lock: c0e5d920 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x2c0 but task is already holding lock: cb95b080 (&dcc->cmd_lock){+.+.}-{3:3}, at: __issue_discard_cmd+0xec/0x5f8 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: [...] -> #3 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire.part.11+0x40/0x50 fs_reclaim_acquire+0x24/0x28 __kmalloc_track_caller+0x54/0x218 kstrdup+0x40/0x5c create_regulator+0xf4/0x368 regulator_resolve_supply+0x1a0/0x200 regulator_register+0x9c8/0x163c [...] other info that might help us debug this: Chain exists of: regulator_list_mutex --> &sit_i->sentry_lock --> &dcc->cmd_lock [...] Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/6eebc99b2474f4ffaa0405b15178ece0e7e4f608.1597195321.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: push allocation in regulator_init_coupling() outside of lockMichał Mirosław2020-09-171-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 73a32129f8ccb556704a26b422f54e048bf14bd0 upstream. Allocating memory with regulator_list_mutex held makes lockdep unhappy when memory pressure makes the system do fs_reclaim on eg. eMMC using a regulator. Push the lock inside regulator_init_coupling() after the allocation. ====================================================== WARNING: possible circular locking dependency detected 5.7.13+ #533 Not tainted ------------------------------------------------------ kswapd0/383 is trying to acquire lock: cca78ca4 (&sbi->write_io[i][j].io_rwsem){++++}-{3:3}, at: __submit_merged_write_cond+0x104/0x154 but task is already holding lock: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire.part.11+0x40/0x50 fs_reclaim_acquire+0x24/0x28 __kmalloc+0x54/0x218 regulator_register+0x860/0x1584 dummy_regulator_probe+0x60/0xa8 [...] other info that might help us debug this: Chain exists of: &sbi->write_io[i][j].io_rwsem --> regulator_list_mutex --> fs_reclaim Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(regulator_list_mutex); lock(fs_reclaim); lock(&sbi->write_io[i][j].io_rwsem); *** DEADLOCK *** 1 lock held by kswapd0/383: #0: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50 [...] Fixes: d8ca7d184b33 ("regulator: core: Introduce API for regulators coupling customization") Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1a889cf7f61c6429c9e6b34ddcdde99be77a26b6.1597195321.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: remove superfluous lock in regulator_resolve_coupling()Michał Mirosław2020-09-171-4/+0
| | | | | | | | | | | | | | [ Upstream commit a577f3456c0a2fac3dee037c483753e6e68f3e49 ] The code modifies rdev, but locks c_rdev instead. Remove the lock as this is held together by regulator_list_mutex taken in the caller. Fixes: f9503385b187 ("regulator: core: Mutually resolve regulators coupling") Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/25eb81cefb37a646f3e44eaaf1d8ae8881cfde52.1597195321.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: push allocation in regulator_ena_gpio_request() out of lockMichał Mirosław2020-09-171-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 467bf30142c64f2eb64e2ac67fa4595126230efd ] Move another allocation out of regulator_list_mutex-protected region, as reclaim might want to take the same lock. WARNING: possible circular locking dependency detected 5.7.13+ #534 Not tainted ------------------------------------------------------ kswapd0/383 is trying to acquire lock: c0e5d920 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x2c0 but task is already holding lock: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire.part.11+0x40/0x50 fs_reclaim_acquire+0x24/0x28 kmem_cache_alloc_trace+0x40/0x1e8 regulator_register+0x384/0x1630 devm_regulator_register+0x50/0x84 reg_fixed_voltage_probe+0x248/0x35c [...] other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(regulator_list_mutex); lock(fs_reclaim); lock(regulator_list_mutex); *** DEADLOCK *** [...] 2 locks held by kswapd0/383: #0: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50 #1: cb70e5e0 (hctx->srcu){....}-{0:0}, at: hctx_lock+0x60/0xb8 [...] Fixes: 541d052d7215 ("regulator: core: Only support passing enable GPIO descriptors") [this commit only changes context] Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") [this is when the regulator_list_mutex was introduced in reclaim locking path] Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/41fe6a9670335721b48e8f5195038c3d67a3bf92.1597195321.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: fix memory leak on error path of regulator_register()Vladimir Zapolskiy2020-08-191-11/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 9177514ce34902b3adb2abd490b6ad05d1cfcb43 ] The change corrects registration and deregistration on error path of a regulator, the problem was manifested by a reported memory leak on deferred probe: as3722-regulator as3722-regulator: regulator 13 register failed -517 # cat /sys/kernel/debug/kmemleak unreferenced object 0xecc43740 (size 64): comm "swapper/0", pid 1, jiffies 4294937640 (age 712.880s) hex dump (first 32 bytes): 72 65 67 75 6c 61 74 6f 72 2e 32 34 00 5a 5a 5a regulator.24.ZZZ 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ backtrace: [<0c4c3d1c>] __kmalloc_track_caller+0x15c/0x2c0 [<40c0ad48>] kvasprintf+0x64/0xd4 [<109abd29>] kvasprintf_const+0x70/0x84 [<c4215946>] kobject_set_name_vargs+0x34/0xa8 [<62282ea2>] dev_set_name+0x40/0x64 [<a39b6757>] regulator_register+0x3a4/0x1344 [<16a9543f>] devm_regulator_register+0x4c/0x84 [<51a4c6a1>] as3722_regulator_probe+0x294/0x754 ... The memory leak problem was introduced as a side ef another fix in regulator_register() error path, I believe that the proper fix is to decouple device_register() function into its two compounds and initialize a struct device before assigning any values to its fields and then using it before actual registration of a device happens. This lets to call put_device() safely after initialization, and, since now a release callback is called, kfree(rdev->constraints) shall be removed to exclude a double free condition. Fixes: a3cde9534ebd ("regulator: core: fix regulator_register() error paths to properly release rdev") Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Cc: Wen Yang <wenyang@linux.alibaba.com> Link: https://lore.kernel.org/r/20200724005013.23278-1-vz@mleia.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regualtor: pfuze100: correct sw1a/sw2 on pfuze3000Robin Gong2020-06-301-21/+39
| | | | | | | | | | | | | | | | | [ Upstream commit 6f1cf5257acc6e6242ddf2f52bc7912aed77b79f ] PFUZE100_SWB_REG is not proper for sw1a/sw2, because enable_mask/enable_reg is not correct. On PFUZE3000, sw1a/sw2 should be the same as sw1a/sw2 on pfuze100 except that voltages are not linear, so add new PFUZE3000_SW_REG and pfuze3000_sw_regulator_ops which like the non-linear PFUZE100_SW_REG and pfuze100_sw_regulator_ops. Fixes: 1dced996ee70 ("regulator: pfuze100: update voltage setting for pfuze3000 sw1a") Reported-by: Christophe Meynard <Christophe.Meynard@ign.fr> Signed-off-by: Robin Gong <yibin.gong@nxp.com> Link: https://lore.kernel.org/r/1592171648-8752-1-git-send-email-yibin.gong@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: qcom-rpmh: Fix typos in pm8150 and pm8150lBjorn Andersson2020-06-221-4/+4
| | | | | | | | | | | | | | [ Upstream commit 906746ba26d0b45688f4c3b730c35f765dc958ba ] Fix typos in pm8150 l13/l16/l17 and pm8150l ldo8 supplies. Fixes: 06369bcc15a1 ("regulator: qcom-rpmh: Add support for SM8150") Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by: Vinod Koul <vkoul@kernel.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20200415053708.717623-1-bjorn.andersson@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: stm32-vrefbuf: fix a possible overshoot when re-enablingFabrice Gasnier2020-03-121-1/+2
| | | | | | | | | | | | | | | | | | | | commit 02fbabd5f4ed182d2c616e49309f5a3efd9ec671 upstream. There maybe an overshoot, when disabling, then re-enabling vrefbuf too quickly. VREFBUF is used by ADC/DAC on some boards. When re-enabling too quickly, an overshoot on the reference voltage make the conversions inaccurate for a short period of time. - Don't put the VREFBUF in HiZ when disabling, to force an active discharge. - Enforce a 1ms OFF/ON delay Fixes: 0cdbf481e927 ("regulator: Add support for stm32-vrefbuf") Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Message-Id: <1583312132-20932-1-git-send-email-fabrice.gasnier@st.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: core: Fix exported symbols to the exported GPL versionEnric Balletbo i Serra2020-02-241-2/+2
| | | | | | | | | | | | | | | | [ Upstream commit 3d7610e8da993539346dce6f7c909fd3d56bf4d5 ] Change the exported symbols introduced by commit e9153311491da ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage") from EXPORT_SYMBOL() to EXPORT_SYMBOL_GPL(), like is used for all the core parts. Fixes: e9153311491da ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage") Reported-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20200120123921.1204339-1-enric.balletbo@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: vctrl-regulator: Avoid deadlock getting and setting the voltageEnric Balletbo i Serra2020-02-242-15/+25
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit e9153311491da9d9863ead9888a1613531cb4a1b ] `cat /sys/kernel/debug/regulator/regulator_summary` ends on a deadlock when you have a voltage controlled regulator (vctrl). The problem is that the vctrl_get_voltage() and vctrl_set_voltage() calls the regulator_get_voltage() and regulator_set_voltage() and that will try to lock again the dependent regulators (the regulator supplying the control voltage). Fix the issue by exporting the unlocked version of the regulator_get_voltage() and regulator_set_voltage() API so drivers that need it, like the voltage controlled regulator driver can use it. Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") Reported-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20200116094543.2847321-1-enric.balletbo@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: rk808: Lower log level on optional GPIOs being not availableMiquel Raynal2020-02-241-1/+1
| | | | | | | | | | | | | | | | | | | | [ Upstream commit b8a039d37792067c1a380dc710361905724b9b2f ] RK808 can leverage a couple of GPIOs to tweak the ramp rate during DVS (Dynamic Voltage Scaling). These GPIOs are entirely optional but a dev_warn() appeared when cleaning this driver to use a more up-to-date gpiod API. At least reduce the log level to 'info' as it is totally fine to not populate these GPIO on a hardware design. This change is trivial but it is worth not polluting the logs during bringup phase by having real warnings and errors sorted out correctly. Fixes: a13eaf02e2d6 ("regulator: rk808: make better use of the gpiod API") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20191203164709.11127-1-miquel.raynal@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: core: Add regulator_is_equal() helperMarek Vasut2020-02-111-0/+14
| | | | | | | | | | | | | | | | | | | | commit b059b7e0ec3208ff1e17cff6387d75a9fbab4e02 upstream. Add regulator_is_equal() helper to compare whether two regulators are the same. This is useful for checking whether two separate regulators in a driver are actually the same supply. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: Igor Opaniuk <igor.opaniuk@toradex.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Marcel Ziswiler <marcel.ziswiler@toradex.com> Cc: Mark Brown <broonie@kernel.org> Cc: Oleksandr Suvorov <oleksandr.suvorov@toradex.com> Link: https://lore.kernel.org/r/20191220164450.1395038-1-marex@denx.de Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* regulator: bd70528: Add MODULE_ALIAS to allow module auto loadingMatti Vaittinen2020-01-261-0/+1
| | | | | | | | | | | | | | [ Upstream commit 55d5f62c3fa005a6a8010363d7d1855909ceefbc ] The bd70528 regulator driver is probed by MFD driver. Add MODULE_ALIAS in order to allow udev to load the module when MFD sub-device cell for regulators is added. Fixes: 99ea37bd1e7d7 ("regulator: bd70528: Support ROHM BD70528 regulator block") Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/20191023121452.GA1812@localhost.localdomain Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: rn5t618: fix module aliasesAndreas Kemnade2020-01-121-0/+1
| | | | | | | | | | | | | [ Upstream commit 62a1923cc8fe095912e6213ed5de27abbf1de77e ] platform device aliases were missing, preventing autoloading of module. Fixes: 811b700630ff ("regulator: rn5t618: add driver for Ricoh RN5T618 regulators") Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Link: https://lore.kernel.org/r/20191211221600.29438-1-andreas@kemnade.info Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: core: fix regulator_register() error paths to properly release rdevWen Yang2020-01-121-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit a3cde9534ebdafe18a9bbab208df724c57e6c8e8 ] There are several issues with the error handling code of the regulator_register() function: ret = device_register(&rdev->dev); if (ret != 0) { put_device(&rdev->dev); --> rdev released goto unset_supplies; } ... unset_supplies: ... unset_regulator_supplies(rdev); --> use-after-free ... clean: if (dangling_of_gpiod) gpiod_put(config->ena_gpiod); kfree(rdev); --> double free We add a variable to record the failure of device_register() and move put_device() down a bit to avoid the above issues. Fixes: c438b9d01736 ("regulator: core: Move registration of regulator device") Signed-off-by: Wen Yang <wenyang@linux.alibaba.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20191201030250.38074-1-wenyang@linux.alibaba.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: fix use after free issueWen Yang2020-01-121-2/+2
| | | | | | | | | | | | | | | | | [ Upstream commit 4affd79a125ac91e6a53be843ea3960a8fc00cbb ] This is caused by dereferencing 'rdev' after put_device() in the _regulator_get()/_regulator_put() functions. This patch just moves the put_device() down a bit to avoid the issue. Signed-off-by: Wen Yang <wenyang@linux.alibaba.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20191124145835.25999-1-wenyang@linux.alibaba.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-12 21:32:25 +0000