summaryrefslogtreecommitdiff
path: root/drivers/regulator
AgeCommit message (Collapse)AuthorFilesLines
2020-10-29regulator: resolve supply after creating regulatorMichał Mirosław1-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>
2020-10-01regulator: axp20x: fix LDO2/4 descriptionIcenowy Zheng1-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>
2020-09-23regulator: pwm: Fix machine constraints applicationVincent Whitchurch1-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>
2020-09-17regulator: core: Fix slab-out-of-bounds in regulator_unlock_recursive()Dmitry Osipenko1-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>
2020-09-17regulator: plug of_node leak in regulator_register()'s error pathMichał Mirosław1-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>
2020-09-17regulator: push allocation in set_consumer_device_supply() out of lockMichał Mirosław1-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>
2020-09-17regulator: push allocations in create_regulator() outside of lockMichał Mirosław1-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>
2020-09-17regulator: push allocation in regulator_init_coupling() outside of lockMichał Mirosław1-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>
2020-09-17regulator: remove superfluous lock in regulator_resolve_coupling()Michał Mirosław1-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>
2020-09-17regulator: push allocation in regulator_ena_gpio_request() out of lockMichał Mirosław1-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>
2020-08-19regulator: fix memory leak on error path of regulator_register()Vladimir Zapolskiy1-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>
2020-06-25regulator: rename da903x to da903x-regulatorSeth Forshee2-1/+1
This module shares the same name as its parent PMIC driver, which confuses tools like kmod. Rename the regulator driver to avoid such problems. Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Link: https://lore.kernel.org/r/20200624171010.845271-1-seth.forshee@canonical.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-23regulator: qcom_smd: Fix pmi8994 labelKonrad Dybcio1-1/+1
s3 was mislabeled as s2. Fix it. Signed-off-by: Konrad Dybcio <konradybcio@gmail.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200620144639.335093-19-konradybcio@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-17regulator: mt6358: Remove BROKEN dependencyAxel Lin1-1/+1
The MFD part is merged into v5.8-rc1, thus remove BROKEN dependency. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20200616135030.1163660-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-17Merge tag 'v5.8-rc1' into regulator-5.8Mark Brown1-4/+4
Linux 5.8-rc1
2020-06-15regualtor: pfuze100: correct sw1a/sw2 on pfuze3000Robin Gong1-21/+39
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>
2020-06-12regulator: Fix pickable ranges mappingMatti Vaittinen1-1/+1
Pickable ranges mapping function never used range min selector. Thus existing drivers broke when proper linear_ranges functionality was taken in use. Fix this for now just by ignoring the minimum selector. Fixes: 60ab7f4153b6 ("regulator: use linear_ranges helper") Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/20200612090225.GA3243@localhost.localdomain Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-12regulator: da9063: fix LDO9 suspend and warning.Martin Fuzzey1-1/+0
Commit 99f75ce66619 ("regulator: da9063: fix suspend") converted the regulators to use a common (corrected) suspend bit setting but one of regulators (LDO9) slipped through the crack. This means that the original problem was not fixed for LDO9 and also leads to a warning found by the test robot. da9063-regulator.c:515:3: warning: initialized field overwritten Fix this by converting that regulator too like the others. Fixes: 99f75ce66619 ("regulator: da9063: fix suspend") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group> Link: https://lore.kernel.org/r/1591959073-16792-1-git-send-email-martin.fuzzey@flowbird.group Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-01Merge remote-tracking branch 'regulator/for-5.8' into regulator-linusMark Brown53-310/+882
2020-06-01Merge remote-tracking branch 'regulator/for-5.7' into regulator-linusMark Brown1-4/+4
2020-06-01regulator: max8998: max8998_set_current_limit() can be statickbuild test robot1-2/+2
Fixes: 4ffea5e083f8 ("regulator: max8998: Add charger regulator") Signed-off-by: kbuild test robot <lkp@intel.com> Link: https://lore.kernel.org/r/20200530130314.GA73557@d7d8dbfb64ff Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-29regulator: core: Add regulator bypass trace pointsCharles Keepax1-0/+9
Add new trace points for the start and end of enabling bypass on a regulator, to allow monitoring of when regulators are moved into bypass and how long that takes. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200529152216.9671-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-29Merge series "Fix regulators coupling for Exynos5800" from Marek Szyprowski ↵Mark Brown1-20/+29
<m.szyprowski@samsung.com>: Hi! This patchset is another attempt to fix the regulator coupling on Exynos5800/5422 SoCs. Here are links to the previous attempts: https://lore.kernel.org/linux-samsung-soc/20191008101709.qVNy8eijBi0LynOteWFMnTg4GUwKG599n6OyYoX1Abs@z/ https://lore.kernel.org/lkml/20191017102758.8104-1-m.szyprowski@samsung.com/ https://lore.kernel.org/linux-pm/cover.1589528491.git.viresh.kumar@linaro.org/ https://lore.kernel.org/linux-pm/20200528131130.17984-1-m.szyprowski@samsung.com/ The problem is with "vdd_int" regulator coupled with "vdd_arm" on Odroid XU3/XU4 boards family. "vdd_arm" is handled by CPUfreq. "vdd_int" is handled by devfreq. CPUfreq initialized quite early during boot and it starts changing OPPs and "vdd_arm" value. Sometimes CPU activity during boot goes down and some low-frequency OPPs are selected, what in turn causes lowering "vdd_arm". This happens before devfreq applies its requirements on "vdd_int". Regulator balancing code reduces "vdd_arm" voltage value, what in turn causes lowering "vdd_int" value to the lowest possible value. This is much below the operation point of the wcore bus, which still runs at the highest frequency. The issue was hard to notice because in the most cases the board managed to boot properly, even when the regulator was set to lowest value allowed by the regulator constraints. However, it caused some random issues, which can be observed as "Unhandled prefetch abort" or low USB stability. Adding more and more special cases to the generic code has been rejected, so the only way to ensure the desired behavior on Exynos5800-based SoCs is to make a custom regulator coupler driver. Best regards, Marek Szyprowski Patch summary: Marek Szyprowski (2): regulator: extract voltage balancing code to separate function soc: samsung: Add simple voltage coupler for Exynos5800 arch/arm/mach-exynos/Kconfig | 1 + drivers/regulator/core.c | 49 ++++++++------- drivers/soc/samsung/Kconfig | 3 + drivers/soc/samsung/Makefile | 1 + .../soc/samsung/exynos-regulator-coupler.c | 59 +++++++++++++++++++ include/linux/regulator/coupler.h | 8 +++ 6 files changed, 101 insertions(+), 20 deletions(-) create mode 100644 drivers/soc/samsung/exynos-regulator-coupler.c -- 2.17.1 base-commit: 8f3d9f354286745c751374f5f1fcafee6b3f3136
2020-05-29regulator: extract voltage balancing code to the separate functionMarek Szyprowski1-20/+29
Move the coupled regulators voltage balancing code to the separate function and allow to call it from the custom regulator couplers. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20200529124940.10675-2-m.szyprowski@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-22regulator: max8998: Add charger regulatorJonathan Bakker1-0/+105
The max8998 has a current regulator for charging control. The charger driver in drivers/power/supply/max8998_charger.c has a comment in it stating that 'charger control is done by a current regulator "CHARGER"', but this regulator was never added until now. The current values have been extracted from a downstream driver for the SGH-T959V. Signed-off-by: Jonathan Bakker <xc-racer2@live.ca> Link: https://lore.kernel.org/r/BN6PR04MB0660E1F4A3D5A348BE88311CA3BA0@BN6PR04MB0660.namprd04.prod.outlook.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-20Merge series "MAINTAINER entries for few ROHM power devices" from Matti ↵Mark Brown1-14/+11
Vaittinen <matti.vaittinen@fi.rohmeurope.com>: Add maintainer entries to a few ROHM devices and Linear Ranges Linear Ranges helpers were refactored out of regulator core to lib so that other drivers could utilize them too. (I guess power/supply drivers and possibly clk drivers can benefit from them). As regulators is currently the main user it makes sense the changes to linear_ranges go through Mark's tree. During past two years few ROHM PMIC drivers have been added to mainstream. They deserve a supporter from ROHM side too :) Patch 1: Maintainer entries for few ROHM IC drivers Patch 2: Maintainer entry for linear ranges helpers --- Matti Vaittinen (2): MAINTAINERS: Add entry for ROHM power management ICs MAINTAINERS: Add maintainer entry for linear ranges helper MAINTAINERS | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) base-commit: b9bbe6ed63b2b9f2c9ee5cbd0f2c946a2723f4ce -- 2.21.0 -- Matti Vaittinen, Linux device drivers ROHM Semiconductors, Finland SWDC Kiviharjunlenkki 1E 90220 OULU FINLAND ~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~ Simon says - in Latin please. ~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~ Thanks to Simon Glass for the translation =]
2020-05-14regulator: bd718x7: remove voltage change restriction from BD71847 LDOsMatti Vaittinen1-12/+158
The BD71837 had a HW "feature" where changing the regulator output voltages of other regulators but bucks 1-4 might cause spikes if regulators were enabled. Thus SW prohibit voltage changes for other regulators except for bucks 1-4 when regulator is enabled. The HW colleagues did inadvertly fix this issue for BD71847 and BD71850. The power-good detection for LDOs can still cause false alarms if LDO voltage is changed upwards when LDO is enabled. Allow LDO voltage changes and disabe the power-good monioring for the duration of the LDO voltage change and enable it after LDO voltage has stabilized. ROHM HW colleagues measured the safety limit of 1000uS for guaranteeing the voltage has stabilized. Let's use that for starters and add confiurable stabilization wait-time later if needed. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/20200513143921.GA22143@localhost.localdomain Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-08Merge tag 'linear-ranges-lib' of ↵Mark Brown46-239/+224
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-5.8 lib: Add linear ranges helper library and start using it Series extracts a "linear ranges" helper out of the regulator framework. Linear ranges helper is intended to help converting real-world values to register values when conversion is linear. I suspect this is useful also for power subsystem and possibly for clk.
2020-05-08regulator: use linear_ranges helperMatti Vaittinen46-239/+224
Change the regulator helpers to use common linear_ranges code. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by: Mark Brown <broonie@kernel.org> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Link: https://lore.kernel.org/r/64f01d5e381b8631a271616b7790f9d5640974fb.1588944082.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-06regulator: db8500-prcmu: Use true,false for bool variableJason Yan1-1/+1
Fix the following coccicheck warning: drivers/regulator/db8500-prcmu.c:184:1-17: WARNING: Assignment of 0/1 to bool variable Signed-off-by: Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20200506061726.19289-1-yanaijie@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-29regulator: Revert "Use driver_deferred_probe_timeout for ↵John Stultz1-14/+11
regulator_init_complete_work" This reverts commit dca0b44957e5 ("regulator: Use driver_deferred_probe_timeout for regulator_init_complete_work"), as we ended up reverting the default deferred_probe_timeout value back to zero, to preserve behavior with 5.6 we need to decouple the regulator timeout which was previously 30 seconds. This avoids breaking some systems that depend on the regulator timeout but don't require the deferred probe timeout. Cc: linux-pm@vger.kernel.org Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Saravana Kannan <saravanak@google.com> Cc: Todd Kjos <tkjos@google.com> Cc: Len Brown <len.brown@intel.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Kevin Hilman <khilman@kernel.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Rob Herring <robh@kernel.org> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Suggested-by: Mark Brown <broonie@kernel.org> Signed-off-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20200429172349.55979-1-john.stultz@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-28regulator: bd718x7: remove voltage change restriction from BD71847Matti Vaittinen1-5/+41
The BD71837 had a HW "feature" where changing the regulator output voltages of other regulators but bucks 1-4 might cause spikes if regulators were enabled. Thus SW prohibit voltage changes for other regulators except for bucks 1-4 when regulator is enabled. The HW colleagues did inadvertly fix this issue for BD71847 and BD71850. Remove voltage change restrictions from other PMICs but BD71837. The LDO voltage changing is still restricted. I did not yet receive answer whether there is voltage spikes to be expected for LDOs. I only know that the power-good detection for LDOs can cause false alarms if LDO voltage is changed when LDO is enabled. We might be able to work-around this by disabling the power-good monioring for the duration of the LDO voltage change - but as I said, I don't know yet. Let's fix it later if we can confirm that also LDO voltage changes are safe. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/20200428092930.GA9721@localhost.localdomain Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-15regulator: qcom-rpmh: Fix typos in pm8150 and pm8150lBjorn Andersson1-4/+4
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>
2020-04-14regulator: max77826: Add max77826 regulator driverIskren Chernev3-0/+312
Adding regulator driver for the Maxim max77826 device. The max77826 PMIC contains a high-efficiency BUCK regulator, a BUCK BOOST regulator and 15 LDOs. It is designed for smartphone and tablet applications and is accessed over I2C. Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20200414172250.2363235-2-iskren.chernev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14regulator: tps80031: remove redundant assignment to variables ret and valColin Ian King1-3/+4
The variables ret and val are being initialized with values that are never read and are being updated later with a new value. The initializations are redundant and can be removed. Signed-off-by: Colin Ian King <colin.king@canonical.com> Addresses-Coverity: ("Unused value") Link: https://lore.kernel.org/r/20200410133406.24458-1-colin.king@canonical.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14regulator: ab8500: remove some defined but not used variablesJason Yan1-22/+0
Fix the following gcc warning: drivers/regulator/ab8500.c:195:27: warning: ‘ldo_vdmic_voltages’ defined but not used [-Wunused-const-variable=] static const unsigned int ldo_vdmic_voltages[] = { ^~~~~~~~~~~~~~~~~~ drivers/regulator/ab8500.c:169:27: warning: ‘fixed_3300000_voltage’ defined but not used [-Wunused-const-variable=] static const unsigned int fixed_3300000_voltage[] = { ^~~~~~~~~~~~~~~~~~~~~ drivers/regulator/ab8500.c:142:27: warning: ‘ldo_sdio_voltages’ defined but not used [-Wunused-const-variable=] static const unsigned int ldo_sdio_voltages[] = { ^~~~~~~~~~~~~~~~~ Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20200410073343.39031-1-yanaijie@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14regulator: use consumer->supply_name in debugfs/regulator_summaryMichał Mirosław1-0/+1
Make it easier to identify regulator consumers when consumer device uses more than one supply. Before: regulator ena use open bypass voltage current min max ----------------------------------------------------------------------------------- regulator-dummy 1 0 2 0 0mV 0mA 0mV 0mV 1-0010 0mV 0mV 1-0010 0mV 0mV After: regulator ena use open bypass voltage current min max ----------------------------------------------------------------------------------- regulator-dummy 1 0 2 0 0mV 0mA 0mV 0mV 1-0010-vccio 0mV 0mV 1-0010-vcc33 0mV 0mV Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/731a4b299c6ae0ee9d8995157600a3477f21a36c.1585959068.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14regulator: qcom_rpm: remove defined but not used 'pm8921_ftsmps'Jason Yan1-10/+0
Fix the following gcc warning: drivers/regulator/qcom_rpm-regulator.c:607:34: warning: ‘pm8921_ftsmps’ defined but not used [-Wunused-const-variable=] static const struct qcom_rpm_reg pm8921_ftsmps = { ^~~~~~~~~~~~~ Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200409114026.38383-1-yanaijie@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-31Merge tag 'regulator-spi-v5.7' of ↵Linus Torvalds13-86/+669
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc Pull spi and regulator updates from Mark Brown: "At one point in the release cycle I managed to fat finger things and apply some SPI fixes onto a regulator branch and merge that into the SPI tree, then pull in a change shared with the MTD tree moving the Mediatek quadspi driver over to become the Mediatek spi-nor driver in the SPI tree. This has made a mess which I only just noticed while preparing this and I can't see a sensible way to unpick things due to other subsequent merge commits especially the pull from MTD so it looks like the most sensible thing to do is give up and combine the two pull requests. Fortunately both subsystems were fairly quiet this cycle, the highlights are: regulator: - Support for Monoloithic Power Systems MP5416, MP8867 and MPS8869 and Qualcomm PMI8994 and SMB208. SPI: - Lots of enhancements for spi-fsl-dspi, including XSPI mode support, from Vladimir Oltean. - Support for amlogic Meson G12A, IBM FSI, Mediatek spi-nor (moved from MTD), NXP i.MX8Mx, Rockchip PX30, RK3308 and RK3328, and Qualcomm Atheros AR934x/QCA95xx" * tag 'regulator-spi-v5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc: (118 commits) spi: efm32: Convert to use GPIO descriptors regulator: qcom_smd: Add pmi8994 regulator support regulator: da9063: Fix get_mode() functions to read sleep field spi: spi-fsl-lpspi: Replace zero-length array with flexible-array member spi: spi-s3c24xx: Replace zero-length array with flexible-array member spi: stm32: Fix comments compilation warnings spi: atmel-quadspi: Add verbose debug facilities to monitor register accesses spi: spi-fsl-dspi: Add support for LS1028A spi: spi-fsl-dspi: Move invariant configs out of dspi_transfer_one_message spi: spi-fsl-dspi: Fix interrupt-less DMA mode taking an XSPI code path spi: spi-fsl-dspi: Avoid NULL pointer in dspi_slave_abort for non-DMA mode spi: spi-fsl-dspi: Replace interruptible wait queue with a simple completion spi: spi-fsl-dspi: Protect against races on dspi->words_in_flight spi: spi-fsl-dspi: Avoid reading more data than written in EOQ mode spi: spi-fsl-dspi: Fix bits-per-word acceleration in DMA mode spi: spi-fsl-dspi: Fix little endian access to PUSHR CMD and TXDATA spi: spi-fsl-dspi: Don't access reserved fields in SPI_MCR regulator: driver.h: fix regulator_map_* function names regulator: da9063: fix suspend spi: mxs: Drop GPIO includes ...
2020-03-24Merge branch 'regulator-5.7' into regulator-nextMark Brown13-42/+665
2020-03-24Merge branch 'regulator-5.6' into regulator-linusMark Brown1-44/+4
2020-03-24regulator: qcom_smd: Add pmi8994 regulator supportBjorn Andersson1-0/+47
The pmi8994 is commonly found on MSM8996 based devices, such as the Dragonboard 820c, where it supplies power to a number of LDOs on the primary PMIC. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200324041424.518160-1-bjorn.andersson@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-24regulator: da9063: Fix get_mode() functions to read sleep fieldAdam Thomson1-26/+2
get_mode() is used to retrieve the active mode state. Settings-A config is used during active state, whilst Settings-B is for suspend. This means we only need to check the sleep field of each buck and LDO as that field solely relates to Settings-A config. This change is a clone of the get_mode() update which was committed as part of: - regulator: da9062: fix suspend_enable/disable preparation [a72865f057820ea9f57597915da4b651d65eb92f] Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Link: https://lore.kernel.org/r/20200324092516.60B5C3FB8D@swsrvapps-01.diasemi.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18regulator: da9063: fix suspendMartin Fuzzey1-18/+2
The .set_suspend_enable() and .set_suspend_disable() methods are not supposed to immediately change the regulator state but just indicated if the regulator should be enabled or disabled when standby mode is entered (by a hardware signal). However currently they set control the SEL bits in the DVC registers, which causes the voltage to change to immediately between the "A" (normal) and "B" (standby) values as programmed and does nothing for the enable state... This means that "regulator-on-in-suspend" does not work (the regulator is switched off when the PMIC enters standby mode on the hardware signal) and, potentially, depending on the A and B voltage configurations the voltage could be incorrectly changed *before* actually entering suspend. The right bit to use for the functionality is the "CONF" bit in the "CONT" register. The detailed register description says "Sequencer target state" for this bit which is not very clear but the functional description is clearer. >From 5.1.5 System Enable: De-asserting SYS_EN (changing from active to passive state) clears control SYSTEM_EN which triggers a power down sequence into hibernate/standby mode ... With the exception of supplies that have the xxxx_CONF control bit asserted, all regulators in power domains POWER1, POWER, and SYSTEM are sequentially disabled in reverse order. Regulators with the <x>_CONF bit set remain on but change the active voltage controlregisters from V<x>_A to V<x>_B (if V<x>_B is notalready selected). Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group> Link: https://lore.kernel.org/r/1584461691-14344-1-git-send-email-martin.fuzzey@flowbird.group Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-16regulator: mp886x: add MP8867 supportJisheng Zhang1-1/+61
MP8867 is an I2C-controlled adjustable voltage regulator made by Monolithic Power Systems. The difference between MP8867 and MP8869 are: 1.If V_BOOT, the vref of MP8869 is fixed at 600mv while vref of MP8867 is determined by the I2C control. 2.For MP8867, when setting voltage, if the step is within 5, we need to manually set the GO BIT to 0. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20200316223127.4b1ecc92@xhacker Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-16regulator: add support for MP8869 regulatorJisheng Zhang3-0/+238
The MP8869 from Monolithic Power Systems is a single output DC/DC converter. The voltage can be controlled via I2C. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20200316223020.1a6d92ae@xhacker Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-13regulator: core: Avoid device name duplication in NORMAL_GETAndy Shevchenko1-4/+1
With current code: st-gyro-i2c i2c-PRP0001:00: i2c-PRP0001:00 supply vdd not found, using dummy regulator which looks a bit oververbose. Replace this with simplified format string for the above case, and drop "deviceless" case since for all dev_*() macros used in _regulator_get() the "(null)" will be printed anyway. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200312183245.1612-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-09Merge 5.6-rc5 into driver-core-nextGreg Kroah-Hartman1-1/+2
We need the driver core and debugfs changes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-06Merge tag 'regulator-fix-v5.6-rc4' of ↵Linus Torvalds1-1/+2
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fixes from Mark Brown: "A couple of small fixes, one for a minor issue in the stm32-vrefbuf driver and a documentation fix in the Qualcomm code" * tag 'regulator-fix-v5.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: stm32-vrefbuf: fix a possible overshoot when re-enabling regulator: qcom_spmi: Fix docs for PM8004
2020-03-04regulator: Use driver_deferred_probe_timeout for regulator_init_complete_workJohn Stultz1-11/+14
The regulator_init_complete_work logic defers the cleanup for an arbitrary 30 seconds of time to allow modules loaded by userland to start. This arbitrary timeout is similar to the driver_deferred_probe_timeout value, and its been suggested we align these so users have a method to extend the timeouts as needed. So this patch changes the logic to use the driver_deferred_probe_timeout value for the delay value if it is set (using a delay of 0 if it is not). Cc: linux-pm@vger.kernel.org Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Mark Brown <broonie@kernel.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Saravana Kannan <saravanak@google.com> Cc: Todd Kjos <tkjos@google.com> Cc: Len Brown <len.brown@intel.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Kevin Hilman <khilman@kernel.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Rob Herring <robh@kernel.org> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: John Stultz <john.stultz@linaro.org> Link: https://lore.kernel.org/r/20200225050828.56458-7-john.stultz@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-10-07 10:12:48 +0300