IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
[ Upstream commit 8d8e16592022c9650df8aedfe6552ed478d7135b ]
By using a ratio of delay to poll_enabled_time that is not integer
time_remaining underflows and does not exit the loop as expected.
As delay could be derived from DT and poll_enabled_time is defined
in the driver this can easily happen.
Use a signed iterator to make sure that the loop exits once
the remaining time is negative.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Link: https://lore.kernel.org/r/20220909125954.577669-1-patrick.rudolph@9elements.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 8478ed5844588703a1a4c96a004b1525fbdbdd5e upstream.
On recent kernels, the PM8058 L16 (or any other PM8058 LDO-regulator)
does not come up if they are supplied by an SMPS-regulator. This
is not very strange since the regulators are registered in a long
array and the L-regulators are registered before the S-regulators,
and if an L-regulator defers, it will never get around to registering
the S-regulator that it needs.
See arch/arm/boot/dts/qcom-apq8060-dragonboard.dts:
pm8058-regulators {
(...)
vdd_l13_l16-supply = <&pm8058_s4>;
(...)
Ooops.
Fix this by moving the PM8058 S-regulators first in the array.
Do the same for the PM8901 S-regulators (though this is currently
not causing any problems with out device trees) so that the pattern
of registration order is the same on all PMnnnn chips.
Fixes: 087a1b5cdd55 ("regulator: qcom: Rework to single platform device")
Cc: stable@vger.kernel.org
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <andersson@kernel.org>
Cc: Konrad Dybcio <konrad.dybcio@somainline.org>
Cc: linux-arm-msm@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20220909112529.239143-1-linus.walleij@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 78e1e867f44e6bdc72c0e6a2609a3407642fb30b ]
The pfuze_chip::regulator_descs is an array of size
PFUZE100_MAX_REGULATOR, the pfuze_chip::pfuze_regulators
is the pointer to the real regulators of a specific device.
The number of real regulator is supposed to be less than
the PFUZE100_MAX_REGULATOR, so we should use the size of
'regulator_num * sizeof(struct pfuze_regulator)' in memcpy().
This fixes the out of bounds access bug reported by KASAN.
Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
Link: https://lore.kernel.org/r/20220825111922.1368055-1-xiaolei.wang@windriver.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit c32f1ebfd26bece77141257864ed7b4720da1557 ]
If regulator_enable() fails, enable_count is incremented still.
A consumer, assuming no matching regulator_disable() is necessary on
failure, will then get this error message upon regulator_put()
since enable_count is non-zero:
[ 1.277418] WARNING: CPU: 3 PID: 1 at drivers/regulator/core.c:2304 _regulator_put.part.0+0x168/0x170
The consumer could try to fix this in their driver by cleaning up on
error from regulator_enable() (i.e. call regulator_disable()), but that
results in the following since regulator_enable() failed and didn't
increment user_count:
[ 1.258112] unbalanced disables for vreg_l17c
[ 1.262606] WARNING: CPU: 4 PID: 1 at drivers/regulator/core.c:2899 _regulator_disable+0xd4/0x190
Fix this by decrementing enable_count upon failure to enable.
With this in place, just the reason for failure to enable is printed
as expected and developers can focus on the root cause of their issue
instead of thinking their usage of the regulator consumer api is
incorrect. For example, in my case:
[ 1.240426] vreg_l17c: invalid input voltage found
Fixes: 5451781dadf8 ("regulator: core: Only count load for enabled consumers")
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Link: https://lore.kernel.org/r/20220819194336.382740-1-ahalaney@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 66efb665cd5ad69b27dca8571bf89fc6b9c628a4 ]
We should call the of_node_put() for the reference returned by
of_get_child_by_name() which has increased the refcount.
Fixes: 40e20d68bb3f ("regulator: of: Add support for parsing regulator_state for suspend state")
Signed-off-by: Liang He <windhl@126.com>
Link: https://lore.kernel.org/r/20220715111027.391032-1-windhl@126.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit e8977917e116d1571dacb8e9864474551c1c12bd ]
The PM8916 device specification [1] documents a programmable range of
1.75V to 3.337V with 12.5mV steps for the PMOS LDOs in PM8916. This
range is also used when controlling the regulator directly using the
qcom_spmi-regulator driver ("ult_pldo" there).
However, for some reason the qcom_smd-regulator driver allows a much
larger range for the same hardware component. This could be simply a
typo, since the start of the range is essentially just missing a '1'.
In practice this does not cause any major problems, since the driver
just sends the actual voltage to the RPM firmware instead of making use
of the incorrect voltage selector. Still, having the wrong range there
is confusing and prevents the regulator core from validating requests
correctly.
[1]: https://developer.qualcomm.com/download/sd410/pm8916pm8916-1-power-management-ic-device-specification.pdf
Fixes: 57d6567680ed ("regulator: qcom-smd: Add PM8916 support")
Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
Link: https://lore.kernel.org/r/20220623094614.1410180-2-stephan.gerhold@kernkonzept.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 68d6c8476fd4f448e70e0ab31ff972838ac41dae ]
of_find_node_by_name() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak.
Fixes: 0fbeae70ee7c ("regulator: add SCMI driver")
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Link: https://lore.kernel.org/r/20220516074433.32433-1-linmq006@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit afaa7b933ef00a2d3262f4d1252087613fb5c06d ]
of_node_get() returns a node with refcount incremented.
Calling of_node_put() to drop the reference when not needed anymore.
Fixes: 3784b6d64dc5 ("regulator: pfuze100: add pfuze100 regulator driver")
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Link: https://lore.kernel.org/r/20220511113506.45185-1-linmq006@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit b11b3d21a94d66bc05d1142e0b210bfa316c62be ]
Following changes have been made:
- S5, L4, L18, L20 and L21 were removed (S5 is managed by
SPMI, whereas the rest seems not to exist [or at least it's blocked
by Sony Loire /MSM8956/ RPM firmware])
- Supply maps have were adjusted to reflect regulator changes.
Fixes: e44adca5fa25 ("regulator: qcom_smd: Add PM8950 regulators")
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Link: https://lore.kernel.org/r/20220430163753.609909-1-konrad.dybcio@somainline.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit c3e3ca05dae37f8f74bb80358efd540911cbc2c8 ]
Since the introduction of regulator->enable_count, a driver that did
an exclusive get on an already-enabled regulator would end up with
enable_count initialized to 0 but rdev->use_count initialized to 1.
With that starting point the regulator is effectively stuck enabled,
because if the driver attempted to disable it it would fail the
enable_count underflow check in _regulator_handle_consumer_disable().
The EXCLUSIVE_GET path in _regulator_get() now initializes
enable_count along with rdev->use_count so that the regulator can be
disabled without underflowing the former.
Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Fixes: 5451781dadf85 ("regulator: core: Only count load for enabled consumers")
Link: https://lore.kernel.org/r/20220505043152.12933-1-zev@bewilderbeest.net
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit bab76514aca36bc513224525d5598da676938218 ]
KASAN report slab-out-of-bounds in __regmap_init as follows:
BUG: KASAN: slab-out-of-bounds in __regmap_init drivers/base/regmap/regmap.c:841
Read of size 1 at addr ffff88803678cdf1 by task xrun/9137
CPU: 0 PID: 9137 Comm: xrun Tainted: G W 5.18.0-rc2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x15a lib/dump_stack.c:88
print_report.cold+0xcd/0x69b mm/kasan/report.c:313
kasan_report+0x8e/0xc0 mm/kasan/report.c:491
__regmap_init+0x4540/0x4ba0 drivers/base/regmap/regmap.c:841
__devm_regmap_init+0x7a/0x100 drivers/base/regmap/regmap.c:1266
__devm_regmap_init_i2c+0x65/0x80 drivers/base/regmap/regmap-i2c.c:394
da9121_i2c_probe+0x386/0x6d1 drivers/regulator/da9121-regulator.c:1039
i2c_device_probe+0x959/0xac0 drivers/i2c/i2c-core-base.c:563
This happend when da9121 device is probe by da9121_i2c_id, but with
invalid dts. Thus, chip->subvariant_id is set to -EINVAL, and later
da9121_assign_chip_model() will access 'regmap' without init it.
Fix it by return -EINVAL from da9121_assign_chip_model() if
'chip->subvariant_id' is invalid.
Fixes: f3fbd5566f6a ("regulator: da9121: Add device variants")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: Adam Ward <Adam.Ward.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/20220421090335.1876149-1-weiyongjun1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ 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>
[ 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>
[ 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>
[ 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>
[ 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>
[ 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>
[ 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>
[ 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>
[ 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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
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>
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>
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>
