summaryrefslogtreecommitdiff
path: root/drivers/regulator
AgeCommit message (Collapse)AuthorFilesLines
2022-04-20regulator: wm8994: Add an off-on delay for WM8994 variantJonathan Bakker1-3/+39
[ Upstream commit 92d96b603738ec4f35cde7198c303ae264dd47cb ] As per Table 130 of the wm8994 datasheet at [1], there is an off-on delay for LDO1 and LDO2. In the wm8958 datasheet [2], I could not find any reference to it. I could not find a wm1811 datasheet to double-check there, but as no one has complained presumably it works without it. This solves the issue on Samsung Aries boards with a wm8994 where register writes fail when the device is powered off and back-on quickly. [1] https://statics.cirrus.com/pubs/proDatasheet/WM8994_Rev4.6.pdf [2] https://statics.cirrus.com/pubs/proDatasheet/WM8958_v3.5.pdf Signed-off-by: Jonathan Bakker <xc-racer2@live.ca> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/CY4PR04MB056771CFB80DC447C30D5A31CB1D9@CY4PR04MB0567.namprd04.prod.outlook.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-13regulator: atc260x: Fix missing active_discharge_on settingAxel Lin1-0/+1
[ Upstream commit 2316f0fc0ad2aa87a568ceaf3d76be983ee555c3 ] Without active_discharge_on setting, the SWITCH1 discharge enable control is always disabled. Fix it. Fixes: 3b15ccac161a ("regulator: Add regulator driver for ATC260x PMICs") Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20220403132235.123727-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-13regulator: rtq2134: Fix missing active_discharge_on settingAxel Lin1-0/+1
[ Upstream commit 17049bf9de55a42ee96fd34520aff8a484677675 ] The active_discharge_on setting was missed, so output discharge resistor is always disabled. Fix it. Fixes: 0555d41497de ("regulator: rtq2134: Add support for Richtek RTQ2134 SubPMIC") Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20220404022514.449231-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08regulator: rpi-panel: Handle I2C errors/timing to the AtmelDave Stevenson1-10/+46
[ Upstream commit 5665eee7a3800430e7dc3ef6f25722476b603186 ] The Atmel is doing some things in the I2C ISR, during which period it will not respond to further commands. This is particularly true of the POWERON command. Increase delays appropriately, and retry should I2C errors be reported. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Link: https://lore.kernel.org/r/20220124220129.158891-3-detlev.casanova@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08regulator: qcom_smd: fix for_each_child.cocci warningskernel test robot1-1/+3
[ Upstream commit 6390d42c21efff0b4c10956a38e341f4e84ecd3d ] drivers/regulator/qcom_smd-regulator.c:1318:1-33: WARNING: Function "for_each_available_child_of_node" should have of_node_put() before return around line 1321. Semantic patch information: False positives can be due to function calls within the for_each loop that may encapsulate an of_node_put. Generated by: scripts/coccinelle/iterators/for_each_child.cocci Fixes: 14e2976fbabd ("regulator: qcom_smd: Align probe function with rpmh-regulator") CC: Konrad Dybcio <konrad.dybcio@somainline.org> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: kernel test robot <lkp@intel.com> Signed-off-by: Julia Lawall <julia.lawall@inria.fr> Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2201151210170.3051@hadrien Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-03-08regulator: core: fix false positive in regulator_late_cleanup()Oliver Barta1-10/+3
[ Upstream commit 4e2a354e3775870ca823f1fb29bbbffbe11059a6 ] The check done by regulator_late_cleanup() to detect whether a regulator is on was inconsistent with the check done by _regulator_is_enabled(). While _regulator_is_enabled() takes the enable GPIO into account, regulator_late_cleanup() was not doing that. This resulted in a false positive, e.g. when a GPIO-controlled fixed regulator was used, which was not enabled at boot time, e.g. reg_disp_1v2: reg_disp_1v2 { compatible = "regulator-fixed"; regulator-name = "display_1v2"; regulator-min-microvolt = <1200000>; regulator-max-microvolt = <1200000>; gpio = <&tlmm 148 0>; enable-active-high; }; Such regulator doesn't have an is_enabled() operation. Nevertheless it's state can be determined based on the enable GPIO. The check in regulator_late_cleanup() wrongly assumed that the regulator is on and tried to disable it. Signed-off-by: Oliver Barta <oliver.barta@aptiv.com> Link: https://lore.kernel.org/r/20220208084645.8686-1-oliver.barta@aptiv.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27regulator: qcom_smd: Align probe function with rpmh-regulatorKonrad Dybcio1-30/+70
[ Upstream commit 14e2976fbabdacb01335d7f91eeebbc89c67ddb1 ] The RPMh regulator driver is much newer and gets more attention, which in consequence makes it do a few things better. Update qcom_smd-regulator's probe function to mimic what rpmh-regulator does to address a couple of issues: - Probe defer now works correctly, before it used to, well, kinda just die.. This fixes reliable probing on (at least) PM8994, because Linux apparently cannot deal with supply map dependencies yet.. - Regulator data is now matched more sanely: regulator data is matched against each individual regulator node name and throwing an -EINVAL if data is missing, instead of just assuming everything is fine and iterating over all subsequent array members. - status = "disabled" will now work for disabling individual regulators in DT. Previously it didn't seem to do much if anything at all. Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Link: https://lore.kernel.org/r/20211230023442.1123424-1-konrad.dybcio@somainline.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27regulator: da9121: Prevent current limit change when enabledAdam Ward1-0/+5
[ Upstream commit 24f0853228f3b98f1ef08d5824376c69bb8124d2 ] Prevent changing current limit when enabled as a precaution against possibile instability due to tight integration with switching cycle Signed-off-by: Adam Ward <Adam.Ward.opensource@diasemi.com> Link: https://lore.kernel.org/r/52ee682476004a1736c1e0293358987319c1c415.1638223185.git.Adam.Ward.opensource@diasemi.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27regulator: qcom-labibb: OCP interrupts are not a failure while disabledMarijn Suijten1-1/+1
[ Upstream commit d27bb69dc83f00f86a830298c967052cded6e784 ] Receiving the Over-Current Protection interrupt while the regulator is disabled does not count as unhandled/failure (IRQ_NONE, or 0 as it were) but a "fake event", usually due to inrush as the is regulator about to be enabled. Fixes: 390af53e0411 ("regulator: qcom-labibb: Implement short-circuit and over-current IRQs") Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Link: https://lore.kernel.org/r/20211224113450.107958-1-marijn.suijten@somainline.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18regulator: s5m8767: do not use reset value as DVS voltage if GPIO DVS is ↵Krzysztof Kozlowski1-12/+9
disabled commit b16bef60a9112b1e6daf3afd16484eb06e7ce792 upstream. The driver and its bindings, before commit 04f9f068a619 ("regulator: s5m8767: Modify parsing method of the voltage table of buck2/3/4") were requiring to provide at least one safe/default voltage for DVS registers if DVS GPIO is not being enabled. IOW, if s5m8767,pmic-buck2-uses-gpio-dvs is missing, the s5m8767,pmic-buck2-dvs-voltage should still be present and contain one voltage. This requirement was coming from driver behavior matching this condition (none of DVS GPIO is enabled): it was always initializing the DVS selector pins to 0 and keeping the DVS enable setting at reset value (enabled). Therefore if none of DVS GPIO is enabled in devicetree, driver was configuring the first DVS voltage for buck[234]. Mentioned commit 04f9f068a619 ("regulator: s5m8767: Modify parsing method of the voltage table of buck2/3/4") broke it because DVS voltage won't be parsed from devicetree if DVS GPIO is not enabled. After the change, driver will configure bucks to use the register reset value as voltage which might have unpleasant effects. Fix this by relaxing the bindings constrain: if DVS GPIO is not enabled in devicetree (therefore DVS voltage is also not parsed), explicitly disable it. Cc: <stable@vger.kernel.org> Fixes: 04f9f068a619 ("regulator: s5m8767: Modify parsing method of the voltage table of buck2/3/4") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Acked-by: Rob Herring <robh@kernel.org> Message-Id: <20211008113723.134648-2-krzysztof.kozlowski@canonical.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-17regulator: max14577: Revert "regulator: max14577: Add proper module aliases ↵Krzysztof Kozlowski1-2/+0
strings" This reverts commit 0da6736ecd10b45e535b100acd58df2db4c099d8. The MODULE_DEVICE_TABLE already creates proper alias. Having another MODULE_ALIAS causes the alias to be duplicated: $ modinfo max14577-regulator.ko alias: platform:max77836-regulator alias: platform:max14577-regulator description: Maxim 14577/77836 regulator driver alias: platform:max77836-regulator alias: platform:max14577-regulator Cc: Marek Szyprowski <m.szyprowski@samsung.com> Fixes: 0da6736ecd10 ("regulator: max14577: Add proper module aliases strings") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20210916144102.120980-1-krzysztof.kozlowski@canonical.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-01regulator: qcom-rpmh-regulator: fix pm8009-1 ldo7 resource nameDmitry Baryshkov1-1/+1
Fix a typo in the pm8009 LDO7 declaration, it uses resource name ldo%s6 instead of ldo%s7. Fixes: 951384cabc5d ("regulator: qcom-rpmh-regulator: add pm8009-1 chip revision") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210901114350.1106073-1-dmitry.baryshkov@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-08-25regulator: vctrl: Avoid lockdep warning in enable/disable opsChen-Yu Tsai1-30/+42
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>
2021-08-25regulator: vctrl: Use locked regulator_get_voltage in probe pathChen-Yu Tsai1-1/+2
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>
2021-08-23regulator: Documentation fix for regulator error notification helperMatti Vaittinen1-1/+1
The helper to send IRQ notification for regulator errors had still old description mentioning calling BUG() as a last resort when error status reading has kept failing for more times than a given threshold. The impementation calling BUG() did never end-up in-tree but was replaced by hopefully more sophisticated handler trying to power-off the system. Fix the documentation to reflect actual behaviour. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/20210823075651.GA3717293@localhost.localdomain Signed-off-by: Mark Brown <broonie@kernel.org>
2021-08-09regulator: sy7636a: Use the regmap directlyAlistair Francis1-7/+6
Signed-off-by: Alistair Francis <alistair@alistair23.me> Link: https://lore.kernel.org/r/20210806091058.141-6-alistair@alistair23.me Signed-off-by: Mark Brown <broonie@kernel.org>
2021-08-03regulator: sy7636a: Store the epd-pwr-good GPIO locallyAlistair Francis1-5/+16
Instead of storing the GPIO state in the mfd (where it isn't used) store it in the regulator. Signed-off-by: Alistair Francis <alistair@alistair23.me> Link: https://lore.kernel.org/r/20210803084456.198-7-alistair@alistair23.me Signed-off-by: Mark Brown <broonie@kernel.org>
2021-08-03regulator: sy7636a: Use the parent driver dataAlistair Francis1-6/+6
Use the parent's MFD data instead of our data. Signed-off-by: Alistair Francis <alistair@alistair23.me> Link: https://lore.kernel.org/r/20210803084456.198-6-alistair@alistair23.me Signed-off-by: Mark Brown <broonie@kernel.org>
2021-08-03regulator: sy7636a: Remove the poll_enable_timeAlistair Francis1-3/+0
From testing on hardware the poll_enable_time isn't required and sometimes causes the driver probe to fail so let's remove it. Signed-off-by: Alistair Francis <alistair@alistair23.me> Link: https://lore.kernel.org/r/20210803084456.198-5-alistair@alistair23.me Signed-off-by: Mark Brown <broonie@kernel.org>
2021-08-03regulator: sy8827n: Enable REGCACHE_FLATJisheng Zhang1-0/+14
Enable regmap cache to reduce i2c transactions and corresponding interrupts if regulator is accessed frequently. Since the register map is small, we use a FLAT regmap cache. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20210803165211.3b00db29@xhacker.debian Signed-off-by: Mark Brown <broonie@kernel.org>
2021-08-03regulator: sy8824x: Enable REGCACHE_FLATJisheng Zhang1-1/+15
Enable regmap cache to reduce i2c transactions and corresponding interrupts if regulator is accessed frequently. Since the register map is small -- there's only one register in sy8824c and sy8824e, there are only two registers in sy20276 and sy20278, so we use a FLAT regmap cache. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20210803165043.042ec24d@xhacker.debian Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-30regulator: rtq2134: Fix coding styleChiYuan Huang1-2/+2
Add empty space and put constant number to the right side for 'if' judgement. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1627648326-5026-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-26regulator: hi6421v600: rename voltage range arraysMauro Carvalho Chehab1-14/+14
The arrays containing the regulator's voltage ranges are currently named after the first ldo which uses such range. However, it sounds a lot clearer if those are named with the voltage range instead. No functional changes. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/1bdff1d1f23753b69c8044160decfad1e8553d08.1627121912.git.mchehab+huawei@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-26Merge branch 'regulator-5.14' into regulator-5.15Mark Brown2-27/+31
2021-07-26regulator: hi6421v600: use lowercase for ldoMauro Carvalho Chehab1-18/+18
As lowercase is generally preferred for node names, while it is not too late, change the LDO DT properties to lower case. Suggested-by: Rob Herring <robh@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/395510cffeb39aebd1763cc5de1cb00a2c40e461.1627121912.git.mchehab+huawei@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-22regulator: fixed: use dev_err_probe for registerChris Morgan1-2/+3
Instead of returning error directly, use dev_err_probe. This avoids messages in the dmesg log for devices which will be probed again later. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://lore.kernel.org/r/20210721165716.19915-1-macroalpha82@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-20regulator: rtq2134: Add support for Richtek RTQ2134 SubPMICChiYuan Huang3-0/+385
This adds support for Richtek RTQ2134 SubPMIC. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1626422636-29458-2-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-19regulator: Fix a couple of spelling mistakes in KconfigColin Ian King1-2/+2
There are a couple of spelling mistakes in the Kconfig text. Fix them. Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20210719103429.15544-1-colin.king@canonical.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-16regulator: rtq6752: fix reg reset behaviorChiYuan Huang1-3/+7
Reg will be reset in below two conditions. 1. 'Enable' pin from H to L. 2. Both PAVDD and NAVDD are all disabled. And 'Enable' pin also control i2c communication capability. This patch is to Seperate the if condition in enable/disable callback for reg cache manipulation. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1626407746-23156-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-15regulator: da9063: Add support for full-current mode.Vincent Pelletier1-2/+130
In addition to the ability of merging some power outputs, this chip has an overdrive mode. BCORE1, BCORE2 and BPRO have this ability, in which case the legal current draw is increased from 2 amps to 2.5 amps (at the expense of a quiescent current increase), and the configurable current limits are doubled. If a current higher than maximum half-current mode is requested, enable overdrive, and scale the current limit down. Symmetrically, scale the current limit up when querying a overdrive-enabled regulator. Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com> Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Link: https://lore.kernel.org/r/824518e6391b783a12eba9ff0527f06607a34bfb.1626160826.git.plr.vincent@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-15regulator: rt6245: make a const array func_base static, makes object smallerColin Ian King1-1/+1
Don't populate the const array func_base on the stack but instead it static. Makes the object code smaller by 55 bytes: Before: text data bss dec hex filename 6422 3216 64 9702 25e6 drivers/regulator/rt6245-regulator.o After: text data bss dec hex filename 6303 3280 64 9647 25af drivers/regulator/rt6245-regulator.o Reduction of 55 bytes (gcc version 10.3.0) Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20210715141531.27672-1-colin.king@canonical.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-14regulator: rtq6752: Fix the typo for reg define and author nameChiYuan Huang1-2/+2
Fix the typo for reg define and author name. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Reported-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/1626230170-13648-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-12Merge series "regulator: devres: remove unused device-managed unregister ↵Mark Brown1-67/+2
APIs" from Alexandru Ardelean <aardelean@deviqon.com>: These APIs aren't used anywhere and most-likely exist because of the general principle of C APIs, where if an API function does an allocation/registration, it must also have an equivalent deallocation/deregistration counterpart. For devm_ functions this isn't all that true (for all cases), as the idea of these function is to provide an auto-cleanup logic on drivers/system de-init. Removing these discourages any weird logic that could be created with such an API functions. Alexandru Ardelean (4): regulator: devres: remove devm_regulator_unregister_notifier() function regulator: devres: remove devm_regulator_unregister() function regulator: devres: remove devm_regulator_bulk_unregister_supply_alias() regulator: devres: unexport devm_regulator_unregister_supply_alias() drivers/regulator/devres.c | 105 +---------------------------- include/linux/regulator/consumer.h | 23 ------- include/linux/regulator/driver.h | 1 - 3 files changed, 2 insertions(+), 127 deletions(-) -- 2.31.1
2021-07-12Merge series "Move Hisilicon 6421v600 SPMI and USB drivers out of staging" ↵Mark Brown1-1/+1
from Mauro Carvalho Chehab <mchehab+huawei@kernel.org>: Hi Greg, As promised, that's the version 11, meant to be applied after -rc1. It depends on a regression fix patch merged via the regulator's tree: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git/commit/?h=for-5.14&id=5db5dd5be70eaf808d9fd90174b957fc5c2912cb (the dependence is just because of a trivial merge conflict) This series contain the final bits needed for the USB3 bus to work without staging drivers on Hikey 970. Mauro Carvalho Chehab (8): staging: hi6421-spmi-pmic: add a missing dot at copyright regulator: hi6421v600-regulator: add a missing dot at copyright staging: hikey9xx: split hi6421v600 irq into a separate driver staging: hi6421-spmi-pmic: cleanup drvdata staging: hi6421-spmi-pmic: rename spmi_device struct mfd: hi6421-spmi-pmic: move driver from staging dts: hisilicon: add support for the PMIC found on Hikey 970 dts: hisilicon: add support for USB3 on Hikey 970 .../mfd/hisilicon,hi6421-spmi-pmic.yaml | 134 ++++++++ MAINTAINERS | 7 + .../boot/dts/hisilicon/hi3670-hikey970.dts | 129 ++++++-- arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 56 ++++ .../boot/dts/hisilicon/hikey970-pmic.dtsi | 87 +++++ drivers/mfd/Kconfig | 16 + drivers/mfd/Makefile | 1 + drivers/mfd/hi6421-spmi-pmic.c | 66 ++++ drivers/misc/Kconfig | 10 + drivers/misc/Makefile | 1 + drivers/misc/hi6421v600-irq.c | 313 ++++++++++++++++++ drivers/regulator/hi6421v600-regulator.c | 12 +- drivers/staging/Kconfig | 2 - drivers/staging/Makefile | 1 - drivers/staging/hikey9xx/Kconfig | 19 -- drivers/staging/hikey9xx/Makefile | 3 - drivers/staging/hikey9xx/TODO | 5 - drivers/staging/hikey9xx/hi6421-spmi-pmic.c | 311 ----------------- .../hikey9xx/hisilicon,hi6421-spmi-pmic.yaml | 134 -------- include/linux/mfd/hi6421-spmi-pmic.h | 30 -- 20 files changed, 807 insertions(+), 530 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml create mode 100644 arch/arm64/boot/dts/hisilicon/hikey970-pmic.dtsi create mode 100644 drivers/mfd/hi6421-spmi-pmic.c create mode 100644 drivers/misc/hi6421v600-irq.c delete mode 100644 drivers/staging/hikey9xx/Kconfig delete mode 100644 drivers/staging/hikey9xx/Makefile delete mode 100644 drivers/staging/hikey9xx/TODO delete mode 100644 drivers/staging/hikey9xx/hi6421-spmi-pmic.c delete mode 100644 drivers/staging/hikey9xx/hisilicon,hi6421-spmi-pmic.yaml delete mode 100644 include/linux/mfd/hi6421-spmi-pmic.h -- 2.31.1
2021-07-12regulator: bd718x7: Suopport configuring UVP/OVP stateMatti Vaittinen1-109/+260
The ROHM BD71837/47/50/78 do support enabling/disabling the under/over voltage protection. Add support for enabling/disabling the protection according to the device-tree information. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/20210705105416.GA1189560@localhost.localdomain Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-12regulator: Replace symbolic permissions with octal permissionsJinchao Wang1-2/+2
Resolve following checkpatch issue, Replace symbolic permissions with octal permissions Signed-off-by: Jinchao Wang <wjc@cdjrlc.com> Link: https://lore.kernel.org/r/20210626102454.54931-1-wjc@cdjrlc.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-12regulator: rt6752: Add support for Richtek RTQ6752ChiYuan Huang3-0/+295
Add suport for Richtek RTQ6752. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1625845236-30285-2-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-12regulator: rt5033: Use linear ranges to map all voltage selectionChiYuan Huang1-6/+15
Instead of linear mapping, Use linear range to map all voltage selection. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Reviewed-by: Axel Lin <axel.lin@ingics.com> Acked-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/1625553939-9109-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-12regulator: tps65910: Silence deferred probe errorDmitry Osipenko1-6/+4
The TPS65910 regulator now gets a deferred probe until supply regulator is registered. Silence noisy error message about the deferred probe. Reported-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30 Tested-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30 Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20210705201211.16082-1-digetx@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-12regulator: mt6397: Remove modeset_shift from struct mt6397_regulator_infoAxel Lin1-7/+8
The shift setting can be calculated via the corresponding mask field, so remove modeset_shift. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210629130503.2183574-3-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-12regulator: mt6359: Remove shift fields from struct mt6359_regulator_infoAxel Lin1-11/+8
The shift setting can be calculated via the corresponding mask field, so remove these shift fields. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210629130503.2183574-2-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-12regulator: mt6358: Remove shift fields from struct mt6358_regulator_infoAxel Lin1-47/+40
The shift setting can be calculated via the corresponding mask field, so remove these shift fields. The usage of da_vsel_mask is different from other mask defines because current code does shift regval before mask with the da_vsel_mask. Do proper shit to da_vsel_mask setting so we can calculate the shift. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210629130503.2183574-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-12regulator: devres: unexport devm_regulator_unregister_supply_alias()Alexandru Ardelean1-14/+2
This API hook isn't used anywhere outside of the regulator devres code. This function is needed for the devm_regulator_bulk_register_supply_alias() function on the error path, to cleanup any previously registered supply aliases. This change makes the devm_regulator_unregister_supply_alias() local to the regulator core framework, to avoid it being used in any weird logic. It's also removing the doc-string for devm_regulator_unregister_supply_alias(), since it doesn't need to be documented anymore, as no other external consumer should use it. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210625122324.327585-5-aardelean@deviqon.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-12regulator: devres: remove devm_regulator_bulk_unregister_supply_alias()Alexandru Ardelean1-24/+0
This API hook isn't used anywhere and most-likely exists because of the general principle of C APIs, where if an API function does an allocation/registration, it must also have an equivalent deallocation/deregistration counterpart. For devm_ functions this isn't all that true (for all cases), as the idea of these function is to provide an auto-cleanup logic on drivers/system de-init. Removing this also discourages any weird logic that could be created with such an API function. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210625122324.327585-4-aardelean@deviqon.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-12regulator: devres: remove devm_regulator_unregister() functionAlexandru Ardelean1-29/+0
This API hook isn't used anywhere and most-likely exists because of the general principle of C APIs, where if an API function does an allocation/registration, it must also have an equivalent deallocation/deregistration counterpart. For devm_ functions this isn't all that true (for all cases), as the idea of these function is to provide an auto-cleanup logic on drivers/system de-init. Removing this also discourages any weird logic that could be created with such an API function. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210625122324.327585-3-aardelean@deviqon.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-12regulator: hi6421v600-regulator: add a missing dot at copyrightMauro Carvalho Chehab1-1/+1
The Huawei's copyright is missing a dot at the end. Add it, in order to make it similar to the other two copyrights. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/e9c0f27688d7be75652800e67c913878fd772cbe.1625211021.git.mchehab+huawei@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-12Merge existing fixes from regulator/for-5.14Mark Brown4-12/+13
2021-07-12regulator: hi6421: Fix getting wrong drvdataAxel Lin1-9/+13
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>
2021-07-07regulator: mtk-dvfsrc: Fix wrong dev pointer for devm_regulator_registerAxel Lin1-2/+1
If use dev->parent, the regulator_unregister will not be called when this driver is unloaded. Fix it by using dev instead. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210702142140.2678130-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-05Merge tag 'mfd-next-5.14' of ↵Linus Torvalds1-0/+11
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd Pull mfd updates from Lee Jones: "Core Frameworks: - Fix Software Node clean-up code New Drivers: - Add support for MediaTek MT6359 PMIC - Add support for Qualcomm PM8008 PMIC - Add support for Richtek RT4831 New Device Support: - Add support for Audio CODECs to Rockchip RK817 - Add support for Alder Lake-M to Intel LPSS PCI - Add support for Periph Device Charge to ChromeOS EC New Functionality: - Provide additional IRQs for wcd934x - Add optional Reset functionality to lp87565 Fix-ups: - Namespacing & visibility fixes to lp87565 - Differentiate between Power and Home key IRQs in mt6358 - Export I2C device tables in da9052-i2c, stmpe-i2c - Adapt IRQ flags in max8907, rn5t61, max8907 - Make some functions/devices optional in axp20x, cros_ec_dev - Explicitly include used header files in ioc3 - Remove superfluous lines in MAINTAINERS, sec-core, st,stm32-timers - Resolve Kerneldoc issues in omap-usb-host, omap-usb-tll, si476x-cmd, si476x-i2c - Convert arizona-core to a module - Copyright changes in hi655x-pmic - Drop support for board file initialisation in sec-core - Trivial spelling, whitespace etc updates in lp87565, si476x-cmd, mt6360-core, wm831x-core, twl-core, db8500-prcmu - Simplify various implementations of wcd934x, mt6360-core, max8997, max8998, da9052-i2c, da9062-core, sec-core, - Device Tree binding changes in google,cros-ec, richtek,rt4831-backlight, db8500-prcmu, qcom,pm8008, qcom,spmi-pmic - Use provided APIs to simplify t7l66xb, as3722, da9055-core, tps80031, 88pm800, 88pm805, asic3, sun6i-prcm, wm831x-core, wm831x-otp, ucb1x00-assabet, timberdale, sm501, pcf50633-core, kempld-core, janz-cmodio, intel_soc_pmic_bxtwc, ab8500-core Bug Fixes: - Fix unused variable warning in rk817_codec - Fix regulator voltage configuration in rohm-bd71828 - Fix ongoing freeing of regmap_config 'name' issue in syscon - Fix error handling path in da9063-i2c - Fix Kconfig issues in MFD_MP2629 - Fix DMA mask warnings in motorola-cpcap" * tag 'mfd-next-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (83 commits) mfd: cros_ec: Add peripheral device charger mfd: max8907: Remove IRQF_NO_AUTOEN flag mfd: ab8500-core: Use DEVICE_ATTR_RO/RW macro mfd: intel_soc_pmic_bxtwc: Use DEVICE_ATTR_ADMIN_RW macro mfd: janz-cmodio: Use DEVICE_ATTR_RO macro mfd: kempld-core: Use DEVICE_ATTR_RO macro mfd: pcf50633: Use DEVICE_ATTR_ADMIN_RO macro mfd: sm501: Use DEVICE_ATTR_RO macro mfd: timberdale: Use DEVICE_ATTR_RO macro mfd: ucb1x00-assabet: Use DEVICE_ATTR_RO macro mfd: wm831x: Use DEVICE_ATTR_RO macro mfd: wm831x: Use DEFINE_RES_IRQ_NAMED() and DEFINE_RES_IRQ() to simplify code dt-bindings: mfd: stm32-timers: Remove #address/size cells from required properties mfd: sun6i-prcm: Use DEFINE_RES_MEM() to simplify code mfd: asic3: Use DEFINE_RES_MEM() and DEFINE_RES_IRQ() to simplify code mfd: 88pm805: Use DEFINE_RES_IRQ_NAMED() to simplify code mfd: 88pm800: Use DEFINE_RES_IRQ_NAMED() to simplify code mfd: tps80031: Use DEFINE_RES_IRQ() to simplify code mfd: da9055: Use DEFINE_RES_IRQ_NAMED() to simplify code mfd: as3722: Use DEFINE_RES_IRQ_NAMED() to simplify code ...
generated by cgit v1.2.3 (git 2.39.0) at 2024-06-02 21:04:58 +0300