linux-stable.git/drivers/regulator, branch v6.14

regulator: rtq2208: Fix the LDO DVS capability

2025-03-17T12:45:37+00:00

Use the hidden bank register to identify whether the LDO voltage is
fixed or variable. Remove the read of 'richtek,fixed-microvolt'
property.

Fixes: af1296d15d89 ("regulator: rtq2208: Add fixed LDO VOUT property and check that matches the constraints")
Signed-off-by: ChiYuan Huang 
Link: https://patch.msgid.link/dae0321b710518ce32260336e3cc9caf2ba84215.1742204502.git.cy_huang@richtek.com
Signed-off-by: Mark Brown

regulator: rtq2208: Fix incorrect buck converter phase mapping

2025-03-17T12:45:36+00:00

Use the hidden bank RG to get the correct buck converter phase mapping.

Fixes: 85a11f55621a ("regulator: rtq2208: Add Richtek RTQ2208 SubPMIC")
Signed-off-by: ChiYuan Huang 
Link: https://patch.msgid.link/ae3245aa713f76000dbd20b4ad6f66d30611d3b8.1742204502.git.cy_huang@richtek.com
Signed-off-by: Mark Brown

regulator: check that dummy regulator has been probed before using it

2025-03-13T12:46:17+00:00

Due to asynchronous driver probing there is a chance that the dummy
regulator hasn't already been probed when first accessing it.

Cc: stable@vger.kernel.org
Signed-off-by: Christian Eggers 
Link: https://patch.msgid.link/20250313103051.32430-3-ceggers@arri.de
Signed-off-by: Mark Brown

regulator: dummy: force synchronous probing

2025-03-11T13:11:11+00:00

Sometimes I get a NULL pointer dereference at boot time in kobject_get()
with the following call stack:

anatop_regulator_probe()
 devm_regulator_register()
  regulator_register()
   regulator_resolve_supply()
    kobject_get()

By placing some extra BUG_ON() statements I could verify that this is
raised because probing of the 'dummy' regulator driver is not completed
('dummy_regulator_rdev' is still NULL).

In the JTAG debugger I can see that dummy_regulator_probe() and
anatop_regulator_probe() can be run by different kernel threads
(kworker/u4:*).  I haven't further investigated whether this can be
changed or if there are other possibilities to force synchronization
between these two probe routines.  On the other hand I don't expect much
boot time penalty by probing the 'dummy' regulator synchronously.

Cc: stable@vger.kernel.org
Fixes: 259b93b21a9f ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14")
Signed-off-by: Christian Eggers 
Link: https://patch.msgid.link/20250311091803.31026-1-ceggers@arri.de
Signed-off-by: Mark Brown

regulator: core: Fix deadlock in create_regulator()

2025-03-05T16:35:11+00:00

Currently, we are unnecessarily holding a regulator_ww_class_mutex lock
when creating debugfs entries for a newly created regulator. This was
brought up as a concern in the discussion in commit cba6cfdc7c3f
("regulator: core: Avoid lockdep reports when resolving supplies").

This causes the following lockdep splat after executing
`ls /sys/kernel/debug` on my platform:

  ======================================================
  WARNING: possible circular locking dependency detected
  5.15.167-axis9-devel #1 Tainted: G           O
  ------------------------------------------------------
  ls/2146 is trying to acquire lock:
  ffffff803a562918 (&mm->mmap_lock){++++}-{3:3}, at: __might_fault+0x40/0x88

  but task is already holding lock:
  ffffff80014497f8 (&sb->s_type->i_mutex_key#3){++++}-{3:3}, at: iterate_dir+0x50/0x1f4

  which lock already depends on the new lock.

  [...]

  Chain exists of:
    &mm->mmap_lock --> regulator_ww_class_mutex --> &sb->s_type->i_mutex_key#3

   Possible unsafe locking scenario:

         CPU0                    CPU1
         ----                    ----
    lock(&sb->s_type->i_mutex_key#3);
                                 lock(regulator_ww_class_mutex);
                                 lock(&sb->s_type->i_mutex_key#3);
    lock(&mm->mmap_lock);

   *** DEADLOCK ***

This lock dependency still exists on the latest kernel and using a newer
non-tainted kernel would still cause this problem.

Fix by moving sysfs symlinking and creation of debugfs entries to after
the release of the regulator lock.

Fixes: cba6cfdc7c3f ("regulator: core: Avoid lockdep reports when resolving supplies")
Fixes: eaa7995c529b ("regulator: core: avoid regulator_resolve_supply() race condition")
Signed-off-by: Ludvig Pärsson 
Link: https://patch.msgid.link/20250305-regulator_lockdep_fix-v1-1-ab938b12e790@axis.com
Signed-off-by: Mark Brown

regulator: core: let dt properties override driver init_data

2025-02-11T16:29:01+00:00

This reverts commit cd7a38c40b231350a3cd0fd774f4e6bb68c4b411.

When submitting the change above, it was thought that the origin of the
init_data should be a clear choice, from the driver or from DT but not
both.

It turns out some devices, such as qcom-msm8974-lge-nexus5-hammerhead,
relied on the old behaviour to override the init_data provided by the
driver, making it some kind of default if none is provided by the platform.

Using the init_data provided by the driver when it is present broke these
devices so revert the change to fixup the situation and add a comment
to make things a bit more clear

Reported-by: Luca Weiss 
Closes: https://lore.kernel.org/lkml/5857103.DvuYhMxLoT@lucaweiss.eu
Fixes: cd7a38c40b23 ("regulator: core: do not silently ignore provided init_data")
Signed-off-by: Jerome Brunet 
Link: https://patch.msgid.link/20250211-regulator-init-data-fixup-v1-1-5ce1c6cff990@baylibre.com
Signed-off-by: Mark Brown

Merge tag 'regulator-fix-v6.14-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator

2025-01-29T19:56:55+00:00

Pull regulator fixes from Mark Brown:
 "A couple of fixes that have come in during the merge window: one that
  operates the TPS6287x devices more within the design spec and can
  prevent current surges when changing voltages and another more trivial
  one for error message formatting"

* tag 'regulator-fix-v6.14-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
  regulator: core: Add missing newline character
  regulator: TPS6287X: Use min/max uV to get VRANGE

Merge tag 'regulator-v6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator

2025-01-22T17:03:41+00:00

Pull regulator updates from Mark Brown:
 "This was a very quiet release, aside from some smaller improvements we
  have:

   - Support for power budgeting on regulators, initially targeted at
     some still in review support for PSE controllers but generally
     useful

   - Support for error interrupts from ROHM BD96801 devices

   - Support for NXP PCA9452"

* tag 'regulator-v6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
  regulator: dt-bindings: Add regulator-power-budget-milliwatt property
  regulator: Add support for power budget
  regulator: core: Resolve supply using of_node from regulator_config
  regulator: of: Implement the unwind path of of_regulator_match()
  regulator: tps65219: Remove debugging helper function
  regulator: tps65219: Remove MODULE_ALIAS
  regulator: tps65219: Update driver name
  regulator: tps65219: Use dev_err_probe() instead of dev_err()
  regulator: dt-bindings: mt6315: Drop regulator-compatible property
  regulator: pca9450: Add PMIC pca9452 support
  regulator: dt-bindings: pca9450: Add pca9452 support
  regulator: pca9450: Use dev_err_probe() to simplify code
  regulator: pca9450: add enable_value for all bucks
  regulator: bd96801: Add ERRB IRQ

regulator: core: Add missing newline character

2025-01-22T14:29:29+00:00

dev_err_probe() error messages need newline character.

Fixes: 6eabfc018e8d ("regulator: core: Allow specifying an initial load w/ the bulk API")
Signed-off-by: Alexander Stein 
Link: https://patch.msgid.link/20250122072019.1926093-1-alexander.stein@ew.tq-group.com
Signed-off-by: Mark Brown

regulator: TPS6287X: Use min/max uV to get VRANGE

2025-01-21T15:21:56+00:00

Changing voltage might ignore slew rate and cause a current surge.

With current implementation the driver will get the regulator to change
the voltage range used during run time. According to communication I
have had with Texas Instruments, this is not intended, since the
Dynamic Voltage Scaling in the hardware is only designed to work
within a voltage range. The current implementation will therefore
ignore the slew rate that is defined in devicetree when the voltage
range is changed during use.

The current implementation will always select a voltage in the most
accurate range that can reach that voltage even though multiple ranges
are able to reach that voltage. There are 4 Voltage ranges with the
following reach:
0b00: 0.4-0.71875V      (1.25mV step size)
0b01: 0.4-1.0375V       (2.5mV)
0b10: 0.4-1.675V        (5mV)
0b11: 0.8-3.3V          (10mV)
This in practice means that a change from below to above 0.71875V will
use the smallest range(0b00) for the values below and the second
smallest range(0b01) for the voltages above (Up to 1.675V). I have
timed how long it takes to go from below 0.71875V to above. The
increase was 100mV which, with the slew rate set to 1250µV/µs. This
in theory should take 80µs to do. With the current implementation, it
takes 10µs on my hardware. Doing the same test with the slew rate set
to 5000µV/µs, which should take 20µs, also only takes 10µs to do on
my hardware. Not only is this not in line with the technical
specification for the regulator. It also causes a current surge. Which
when calculating the output current, as described in the technical
specification, compared to what I could observe on my hardware the real
output is ~1A higher (~1.2A) than what I calculated it to be(~0.2A).

I tested also transitioning from a bigger to a smaller range, and the
results were the same.

Instead, let's limit the voltage range to a single one, which is in
line with the intended use of the regulator. This is done by looking
up the minimum and maximum requested voltage specified in devicetree.

Signed-off-by: Jonas Andreasson 
Link: https://patch.msgid.link/20250121-tps-fix-v2-1-50cc4d0f1635@axis.com
Signed-off-by: Mark Brown