summaryrefslogtreecommitdiffstats
path: root/drivers/regulator
AgeCommit message (Collapse)AuthorFilesLines
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-11regulator: 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-11regulator: 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-11regulator: 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-11regulator: 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-11regulator: 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-11regulator: 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-11regulator: 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-11regulator: 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-11regulator: 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-11regulator: 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-11regulator: 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-11regulator: 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-11Merge existing fixes from regulator/for-5.14Mark Brown4-12/+13
2021-07-11regulator: 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 ...
2021-07-01regulator: bd9576: Fix testing wrong flag in check_temp_flag_mismatchAxel Lin1-2/+2
Fix trivial copy-paste typo. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/20210623153443.623856-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-06-30regulator: hi6421v600: Fix getting wrong drvdata that causes boot failureAxel Lin1-7/+9
Since config.dev = pdev->dev.parent in current code, so dev_get_drvdata(rdev->dev.parent) actually returns the drvdata of the mfd device rather than the regulator. Fix it. Fixes: 9bc146acc331 ("regulator: hi6421v600: Fix setting wrong driver_data") Reported-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Axel Lin <axel.lin@ingics.com> Tested-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210630074246.2305166-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-06-28regulator: rtmv20: Fix wrong mask for strobe-polarity-highChiYuan Huang1-1/+1
Fix wrong mask for strobe-polarity-high. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> In-reply-to: <CAFRkauB=0KwrJW19nJTTagdHhBR=V2R8YFWG3R3oVXt=rBRsqw@mail.gmail.com> Reviewed-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/1624723112-26653-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-06-23Merge remote-tracking branch 'regulator/for-5.14' into regulator-nextMark Brown42-1110/+4148
2021-06-23Merge remote-tracking branch 'regulator/for-5.13' into regulator-linusMark Brown2-12/+6
2021-06-23regulator: bd9576: Fix uninitializes variable may_have_irqsColin Ian King1-1/+1
The boolean variable may_have_irqs is not ininitialized and is only being set to true in the case where chip is ROHM_CHIP_TYPE_BD9576. Fix this by ininitialized may_have_irqs to false. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: e7bf1fa58c46 ("regulator: bd9576: Support error reporting") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/20210622144730.22821-1-colin.king@canonical.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-06-23regulator: max8893: Select REGMAP_I2C to fix build errorAxel Lin1-0/+1
Fix build error if REGMAP_I2C is not set. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210622141526.472175-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-06-23regulator: da9052: Ensure enough delay time for .set_voltage_time_selAxel Lin1-1/+2
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>
2021-06-23regulator: mt6358: Fix vdram2 .vsel_maskHsin-Hsiung Wang1-1/+1
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>
2021-06-22regulator: hi6421v600: Fix setting wrong driver_dataAxel Lin1-11/+15
Current code set "config.driver_data = sreg" but sreg only init the mutex, the othere fields are just zero. Fix it by pass *info to config.driver_data so each regulator can get corresponding data by rdev_get_drvdata(). Separate enable_mutex from struct hi6421_spmi_reg_info since only need one mutex for the driver. Fixes: d2dfd50a0b57 ("staging: hikey9xx: hi6421v600-regulator: move LDO config from DT") Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210622043329.392072-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-12 10:25:40 +0000