- 25 Aug, 2021 2 commits
-
-
Chen-Yu Tsai authored
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: f8702f9e ("regulator: core: Use ww_mutex for regulators locking") Fixes: e9153311 ("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.orgSigned-off-by:
Mark Brown <broonie@kernel.org>
-
Chen-Yu Tsai authored
In commit e9153311 ("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: e9153311 ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage") Signed-off-by:
-
- 23 Aug, 2021 1 commit
-
-
Matti Vaittinen authored
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.localdomainSigned-off-by:
-
- 18 Aug, 2021 1 commit
-
-
Matti Vaittinen authored
The newly added regulator ramp-delay specifiers in regulator desc lacked the documentation. Add some. Also fix a typo. Signed-off-by:
-
- 09 Aug, 2021 1 commit
-
-
Alistair Francis authored
Signed-off-by:
Alistair Francis <alistair@alistair23.me> Link: https://lore.kernel.org/r/20210806091058.141-6-alistair@alistair23.meSigned-off-by:
-
- 03 Aug, 2021 5 commits
-
-
Alistair Francis authored
Instead of storing the GPIO state in the mfd (where it isn't used) store it in the regulator. Signed-off-by:
-
Alistair Francis authored
Use the parent's MFD data instead of our data. Signed-off-by:
-
Alistair Francis authored
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:
-
Jisheng Zhang authored
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.debianSigned-off-by:
-
Jisheng Zhang authored
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:
-
- 30 Jul, 2021 1 commit
-
-
ChiYuan Huang authored
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.comSigned-off-by:
-
- 26 Jul, 2021 3 commits
-
-
Mauro Carvalho Chehab authored
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.orgSigned-off-by:
-
Mark Brown authored
-
Mauro Carvalho Chehab authored
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:
-
- 22 Jul, 2021 1 commit
-
-
Chris Morgan authored
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.comSigned-off-by:
-
- 20 Jul, 2021 2 commits
-
-
ChiYuan Huang authored
This adds support for Richtek RTQ2134 SubPMIC. Signed-off-by:
-
ChiYuan Huang authored
Add binding document for Richtek RTQ2134 SubPMIC. Signed-off-by:
-
- 19 Jul, 2021 1 commit
-
-
Colin Ian King authored
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.comSigned-off-by:
-
- 16 Jul, 2021 1 commit
-
-
ChiYuan Huang authored
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:
-
- 15 Jul, 2021 3 commits
-
-
Vincent Pelletier authored
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.comSigned-off-by:
-
Colin Ian King authored
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:
-
Kunihiko Hayashi authored
Convert the UniPhier regulator binding to DT schema format. Signed-off-by:
Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Reviewed-by:
-
- 14 Jul, 2021 2 commits
-
-
ChiYuan Huang authored
Fix the typo for reg define and author name. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/1626230170-13648-1-git-send-email-u0084500@gmail.comSigned-off-by:
-
ChiYuan Huang authored
Drop regulators property reference and remove the status in example dts. Signed-off-by:
-
- 12 Jul, 2021 2 commits
-
-
Mark Brown authored
Merge series "regulator: devres: remove unused device-managed unregister 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 -
Mark Brown authored
Merge series "Move Hisilicon 6421v600 SPMI and USB drivers out of staging" 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
-
- 11 Jul, 2021 14 commits
-
-
Matti Vaittinen authored
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:
-
Jinchao Wang authored
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.comSigned-off-by:
-
ChiYuan Huang authored
Add suport for Richtek RTQ6752. Signed-off-by:
-
ChiYuan Huang authored
Add binding document for Richtek RTQ6752. Signed-off-by:
-
Randy Dunlap authored
Fix warning caused by a blank/empty line: ../include/linux/regulator/machine.h:115: warning: bad line: Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20210628015422.8845-1-rdunlap@infradead.orgSigned-off-by:
-
ChiYuan Huang authored
Instead of linear mapping, Use linear range to map all voltage selection. Signed-off-by:
Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/1625553939-9109-1-git-send-email-u0084500@gmail.comSigned-off-by:
-
Dmitry Osipenko authored
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.comSigned-off-by:
-
Axel Lin authored
The shift setting can be calculated via the corresponding mask field, so remove modeset_shift. Signed-off-by:
-
Axel Lin authored
The shift setting can be calculated via the corresponding mask field, so remove these shift fields. Signed-off-by:
-
Axel Lin authored
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:
-
Alexandru Ardelean authored
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.comSigned-off-by:
-
Alexandru Ardelean authored
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 authored
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:
-
Mauro Carvalho Chehab authored
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:
-
