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: NKonrad Dybcio <konrad.dybcio@somainline.org>
Link: https://lore.kernel.org/r/20211230023442.1123424-1-konrad.dybcio@somainline.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Return value from regmap_update_bits() directly instead
of taking this in another redundant variable.
Reported-by: NZeal Robot <zealci@zte.com.cn>
Signed-off-by: NMinghao Chi <chi.minghao@zte.com.cn>
Signed-off-by: NCGEL ZTE <cgel.zte@gmail.com>
Link: https://lore.kernel.org/r/20220104104139.601031-1-chi.minghao@zte.com.cnSigned-off-by: NMark Brown <broonie@kernel.org>

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: 390af53e ("regulator: qcom-labibb: Implement short-circuit and over-current IRQs")
Signed-off-by: NMarijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: NAngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Link: https://lore.kernel.org/r/20211224113450.107958-1-marijn.suijten@somainline.orgSigned-off-by: NMark Brown <broonie@kernel.org>

The TPS68470 PMIC provides Clocks, GPIOs and Regulators. At present in
the kernel the Regulators and Clocks are controlled by an OpRegion
driver designed to work with power control methods defined in ACPI, but
some platforms lack those methods, meaning drivers need to be able to
consume the resources of these chips through the usual frameworks.

This commit adds a driver for the regulators provided by the tps68470,
and is designed to bind to the platform_device registered by the
intel_skl_int3472 module.

This is based on this out of tree driver written by Intel:
https://github.com/intel/linux-intel-lts/blob/4.14/base/drivers/regulator/tps68470-regulator.c
with various cleanups added.
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211203102857.44539-6-hdegoede@redhat.comSigned-off-by: NMark Brown <broonie@kernel.org>

Return value from twlreg_write() directly instead
of taking this in another redundant variable.
Reported-by: NZeal Robot <zealci@zte.com.cn>
Signed-off-by: NMinghao Chi <chi.minghao@zte.com.cn>
Link: https://lore.kernel.org/r/20211213021655.435423-1-chi.minghao@zte.com.cnSigned-off-by: NMark Brown <broonie@kernel.org>

Add the rpmh regulators found in PM8450 PMIC
Signed-off-by: NVinod Koul <vkoul@kernel.org>
Tested-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20211201072515.3968843-3-vkoul@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Add the DA9141 and DA9142 regulators device recognition data and
operational parameters.
Signed-off-by: NAdam Ward <Adam.Ward.opensource@diasemi.com>
Link: https://lore.kernel.org/r/5f5b9b02f07578cd36c6bc266349a56efc9b08d1.1638223185.git.Adam.Ward.opensource@diasemi.comSigned-off-by: NMark Brown <broonie@kernel.org>

Prevent changing current limit when enabled as a precaution against
possibile instability due to tight integration with switching cycle
Signed-off-by: NAdam Ward <Adam.Ward.opensource@diasemi.com>
Link: https://lore.kernel.org/r/52ee682476004a1736c1e0293358987319c1c415.1638223185.git.Adam.Ward.opensource@diasemi.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add support for PMG1110 regulators.
Signed-off-by: NSatya Priya <quic_c_skakit@quicinc.com>
Link: https://lore.kernel.org/r/1637668167-31325-3-git-send-email-quic_c_skakit@quicinc.comSigned-off-by: NMark Brown <broonie@kernel.org>

The PM8226 PMIC is very often seen on
MSM8x26 boards.
Suggested-by: NIvaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
Signed-off-by: NDominik Kobinski <dominikkobinski314@gmail.com>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20211123181119.2897-1-dominikkobinski314@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Provide a generic map_event helper for regulators which have a notification
IRQ with single, well defined purpose. Eg, IRQ always indicates exactly one
event for exactly one regulator device. For such IRQs the mapping is
trivial.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/603b7ed1938013a00371c1e7ccc63dfb16982b87.1637736436.git.matti.vaittinen@fi.rohmeurope.comSigned-off-by: NMark Brown <broonie@kernel.org>

Use common restricted voltage setting instead of implementing own.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/5a0ee14852802690241568a29ed19ff9550b0b08.1637233864.git.matti.vaittinen@fi.rohmeurope.comSigned-off-by: NMark Brown <broonie@kernel.org>

Few ROHM PMICs have regulators where voltage setting can be done only
when regulator is disabled. Add helper for those PMICs.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/6f51871e9fea611d133b5dd2560f4a7ee1ede9cd.1637233864.git.matti.vaittinen@fi.rohmeurope.comSigned-off-by: NMark Brown <broonie@kernel.org>

When an i2c remove callback fails, the i2c core emits a generic error
message and still removes the device. Apart from the message there the
return value isn't further used.

So don't return an error code after having already emitted a driver
specific warning about the problem to prevent two messages about the
same issue.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20211116110951.1213566-1-u.kleine-koenig@pengutronix.deSigned-off-by: NMark Brown <broonie@kernel.org>

Fixed regulator can't change voltage and regulator_sync_voltage()
returns -EINVAL in this case. Make regulator_sync_voltage() to succeed
for regulators that are incapable to change voltage.

On NVIDIA Tegra power management driver needs to sync voltage and we have
one device (Trimslice) that uses fixed regulator which is getting synced.
The syncing error isn't treated as fatal, but produces a noisy error
message. This patch silences that error.
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20211021183308.27786-1-digetx@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Driver was upstreamed in 2013 and never got a user, remove it.
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20211021192258.21968-3-digetx@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The MFD for SY7636A still isn't merged so we need a dependency even if
it ends up not having a real driver due to the header file.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add basic support for UniPhier NX1 SoC. This includes a compatible string
and the same SoC-dependent data as PXs2 SoC.
Signed-off-by: NKunihiko Hayashi <hayashi.kunihiko@socionext.com>
Link: https://lore.kernel.org/r/1634520605-16583-3-git-send-email-hayashi.kunihiko@socionext.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add the configuration for pm6350 regulators. The supplies are not known
so leave them out for now.

Additionally leave out configuration of smps3 - smps5 and ldo17 as these
are not configured in the downstream kernel and the type of them is not
known.
Signed-off-by: NLuca Weiss <luca@z3ntu.xyz>
Link: https://lore.kernel.org/r/20211007212444.328034-4-luca@z3ntu.xyzSigned-off-by: NMark Brown <broonie@kernel.org>

Signed-off-by: NAlistair Francis <alistair@alistair23.me>
Link: https://lore.kernel.org/r/20211015122551.38951-5-alistair@alistair23.meSigned-off-by: NMark Brown <broonie@kernel.org>

Removing all linux/gpio.h and linux/of_gpio.h dependencies and replacing
them with the gpiod interface.
Signed-off-by: NMaíra Canal <maira.canal@usp.br>
Link: https://lore.kernel.org/r/YWxmL2baF5AdzyHv@fedoraSigned-off-by: NMark Brown <broonie@kernel.org>

After this driver was converted to gpiod, clang started warning:

vers/regulator/lp872x.c:689:57: error: implicit conversion from
enumeration type 'enum lp872x_dvs_state' to different enumeration type
'enum gpiod_flags' [-Werror,-Wenum-conversion]
        dvs->gpio = devm_gpiod_get_optional(lp->dev, "ti,dvs", pinstate);
                    ~~~~~~~~~~~~~~~~~~~~~~~                    ^~~~~~~~
1 error generated.

lp872x_dvs_state was updated to have values from gpiod_flags but this is
not enough to avoid an implicit conversion warning from either GCC or
clang (although GCC enables this warning under -Wextra instead of -Wall
like clang so it is not seen under normal builds).

Eliminate lp872x_dvs_state in favor of using gpiod_flags everywhere so
that there is no more warning about an implicit conversion.

Fixes: 72bf80cf ("regulator: lp872x: replacing legacy gpio interface for gpiod")
Link: https://github.com/ClangBuiltLinux/linux/issues/1481Signed-off-by: NNathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20211019004335.193492-1-nathan@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Removing all linux/gpio.h and linux/of_gpio.h dependencies and replacing
them with the gpiod interface
Signed-off-by: NMaíra Canal <maira.canal@usp.br>
Message-Id: <YWma2yTyuwS5XwhY@fedora>
Signed-off-by: NMark Brown <broonie@kernel.org>

The driver and its bindings, before commit 04f9f068 ("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 04f9f068 ("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: 04f9f068 ("regulator: s5m8767: Modify parsing method of the voltage table of buck2/3/4")
Signed-off-by: NKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Acked-by: NRob Herring <robh@kernel.org>
Message-Id: <20211008113723.134648-2-krzysztof.kozlowski@canonical.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

There are lots of fields in struct hi6421_spmi_pmic that aren't
used. As a matter of fact, only regmap is needed.

So, drop the struct as a whole, and set regmap as the drvdata.
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Acked-by: NMark Brown <broonie@kernel.org>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/1828cb783b1ebca0b98bf0b3077d8701adb228f7.1630586862.git.mchehab+huawei@kernel.org

Consistently use the defines for buck control mask values.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/YVqpujZLZmaiqwe8@fedoraSigned-off-by: NMark Brown <broonie@kernel.org>

PM2250 is commonly used with QCM2290/QCS2290 SoCs, and provides 4 SMPS
and 22 LDO regulators.  The LDO regulators are the same types found on
PM660.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Link: https://lore.kernel.org/r/20210926084549.29880-3-shawn.guo@linaro.orgSigned-off-by: NMark Brown <broonie@kernel.org>

We lowered all the other constraint related log messages to debug level so
lower the logging of what supplies we're configuring to debug level too.
Signed-off-by: NMark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210929140717.3769-1-broonie@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

debugfs code complained at boot time that

  debugfs: Directory 'reg-dummy-regulator-dummy' with parent 'regulator'
  already present!

if we compile kernel with DEBUG_TEST_DRIVER_REMOVE. The problem is that we
don't provide .remove() method for dummy_regulator_driver, which should
invoke regulator_unregister() on device teardown to properly free things.

Though it's harmless as dummy_pdev never gets unbound in practice, let's
use devm_regulator_register() to get rid of the inconsistency.
Signed-off-by: NZenghui Yu <yuzenghui@huawei.com>
Link: https://lore.kernel.org/r/20210925035507.1904-1-yuzenghui@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>

devm_pwm_get() can return -EPROBE_DEFER if the pwm regulator is not
ready yet. Use dev_err_probe() for pwm regulator resources
to indicate the deferral reason when waiting for the
resource to come up.

Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: NAnand Moon <linux.amoon@gmail.com>
Link: https://lore.kernel.org/r/20210925173413.1019-1-linux.amoon@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

MAX8973 is supposed to be MAX8973A. Kconfig and the
initial comment of max8973-regulator.c were modified
accordingly.
Signed-off-by: NRamona Alexandra Nechita <ramona.nechita@analog.com>
Link: https://lore.kernel.org/r/20210920061137.10884-1-ramona.nechita@analog.comSigned-off-by: NMark Brown <broonie@kernel.org>

i915 will soon gain an eviction path that trylock a whole lot of locks
for eviction, getting dmesg failures like below:

  BUG: MAX_LOCK_DEPTH too low!
  turning off the locking correctness validator.
  depth: 48  max: 48!
  48 locks held by i915_selftest/5776:
   #0: ffff888101a79240 (&dev->mutex){....}-{3:3}, at: __driver_attach+0x88/0x160
   #1: ffffc900009778c0 (reservation_ww_class_acquire){+.+.}-{0:0}, at: i915_vma_pin.constprop.63+0x39/0x1b0 [i915]
   #2: ffff88800cf74de8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.63+0x5f/0x1b0 [i915]
   #3: ffff88810c7f9e38 (&vm->mutex/1){+.+.}-{3:3}, at: i915_vma_pin_ww+0x1c4/0x9d0 [i915]
   #4: ffff88810bad5768 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915]
   #5: ffff88810bad60e8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915]
  ...
   #46: ffff88811964d768 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915]
   #47: ffff88811964e0e8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915]
  INFO: lockdep is turned off.

Fixing eviction to nest into ww_class_acquire is a high priority, but
it requires a rework of the entire driver, which can only be done one
step at a time.

As an intermediate solution, add an acquire context to
ww_mutex_trylock, which allows us to do proper nesting annotations on
the trylocks, making the above lockdep splat disappear.

This is also useful in regulator_lock_nested, which may avoid dropping
regulator_nesting_mutex in the uncontended path, so use it there.

TTM may be another user for this, where we could lock a buffer in a
fastpath with list locks held, without dropping all locks we hold.

[peterz: rework actual ww_mutex_trylock() implementations]
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/YUBGPdDDjKlxAuXJ@hirez.programming.kicks-ass.net

This reverts commit 0da6736e.

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: 0da6736e ("regulator: max14577: Add proper module aliases strings")
Signed-off-by: NKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20210916144102.120980-1-krzysztof.kozlowski@canonical.comSigned-off-by: NMark Brown <broonie@kernel.org>

Fix 'enable' gpio control logic from the below cases if it's specified.

1. All off and both are sequentially controlled to be on.
The 'enable' gpio control block to be called twice including the delay time.

2. Both are on and one is preparing to be off.
The 'enable' gpio control low before register cache is configured to be true.
Signed-off-by: NChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1631629249-9998-1-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Voltage-controlled regulators depend on their supply regulator for
retrieving their voltage, and so they might return -EPROBE_DEFER at this
stage. Our caller already attempts to resolve supplies and retry, so we
shouldn't be printing this error to logs.

Quiets log messages like this, on Rockchip RK3399 Gru/Kevin boards:

[    1.033057] ppvar_bigcpu: failed to get the current voltage: -EPROBE_DEFER
...
[    1.036735] ppvar_litcpu: failed to get the current voltage: -EPROBE_DEFER
...
[    1.040366] ppvar_gpu: failed to get the current voltage: -EPROBE_DEFER
...
[    1.044086] ppvar_centerlogic: failed to get the current voltage: -EPROBE_DEFER

Cc: Chen-Yu Tsai <wenst@chromium.org>
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Link: https://lore.kernel.org/r/20210826124015.1.Iab79c6dd374ec48beac44be2fcddd165dd26476b@changeidSigned-off-by: NMark Brown <broonie@kernel.org>

Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: NCai Huoqing <caihuoqing@baidu.com>
Link: https://lore.kernel.org/r/20210908105752.2035-1-caihuoqing@baidu.comSigned-off-by: NMark Brown <broonie@kernel.org>

COMPILE_TEST is helpful to find compilation errors in other platform(e.g.X86).
In this case, the support of COMPILE_TEST is added, so this module could
be compiled in other platform(e.g.X86), without ARCH_SYNQUACER configuration.
Signed-off-by: NCai Huoqing <caihuoqing@baidu.com>
Link: https://lore.kernel.org/r/20210908105738.1933-1-caihuoqing@baidu.comSigned-off-by: NMark Brown <broonie@kernel.org>

Use the devm_platform_ioremap_resource_byname() helper instead of
calling platform_get_resource_byname() and devm_ioremap/devm_ioremap_resource()
separately
Signed-off-by: NCai Huoqing <caihuoqing@baidu.com>
Link: https://lore.kernel.org/r/20210908105745.1984-1-caihuoqing@baidu.comSigned-off-by: NMark Brown <broonie@kernel.org>

Fix a typo in the pm8009 LDO7 declaration, it uses resource name ldo%s6
instead of ldo%s7.

Fixes: 951384ca ("regulator: qcom-rpmh-regulator: add pm8009-1 chip revision")
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210901114350.1106073-1-dmitry.baryshkov@linaro.orgSigned-off-by: NMark 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: NBrian 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: NChen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20210825033704.3307263-3-wenst@chromium.orgSigned-off-by: NMark Brown <broonie@kernel.org>