linux-stable.git/drivers/regulator, branch v7.2.6

regulator: tps65185: wait for the IC to wake before the first I2C access

2026-09-14T11:40:53+00:00

[ Upstream commit 44f7b876b7c6c7b3a219b7a810d3d9548df21540 ]

The probe drives WAKEUP high with GPIOD_OUT_HIGH, enables the input
supply, and then issues a regmap_update_bits() on INT_EN2 with no wait
anywhere in between. The TPS65185 data sheet (TI SLVSAQ8G, February
2011, revised September 2017), section 7.6 "Timing Requirements: Data
Transmission", Figure 2 "Power-Up and Power-Down Timing Diagram",
footnote 1, requires 1.8 ms minimum between the WAKEUP rising edge and
the IC being ready to accept an I2C transaction. The driver calls no
delay function anywhere, and nothing on that path is guaranteed to take
that long.

On an RK3026 board the first transfer was NAKed:

  tps65185 0-0068: error -ENXIO: failed to enable temp irq

-ENXIO here is rk3x_i2c reporting REG_INT_NAKRCV. Probe failed, so
vposneg never registered and its consumer deferred indefinitely.

Wait after the supply rather than at the gpiod_get(). Figure 2 times
that 1.8 ms from a WAKEUP edge with VIN already up, whereas this driver
asserts WAKEUP before enabling vin-supply; the data sheet does not
describe that order, so on a board whose vin-supply is a switched
regulator that was off, a wait placed at the gpiod_get() could elapse
before the part had power. Waiting from whichever of the two comes last
satisfies the specified case and is the conservative choice in the
other.

It also goes above the interrupt request rather than immediately before
the INT_EN2 write, because that write is not necessarily the first
transfer: tps65185_irq_thread() reads INT1 and INT2, and it is
requested with IRQF_TRIGGER_LOW, so it can run as soon as the handler
is installed.

Tested on an ONYX BOOX C67ML (RK3026): the chip now probes, all three
regulators register and the EPD controller comes up.

Fixes: b0fc1e770194 ("regulator: Add TPS65185 driver")
Signed-off-by: Mario Rugiero 
Link: https://patch.msgid.link/20260815232229.68474-1-mrugiero@gmail.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

regulator: qcom-rpmh: Fix PMIC5 BOB bypass mode handling

2026-09-14T11:40:28+00:00

[ Upstream commit abd14bebb87e0fa2749371272c8b31d6ee5f0a36 ]

Currently, when `rpmh_regulator_set_mode_bypass()` helper function
is called to set bypass mode, it sends PMIC4's BOB bypass mode
value for even if its a PMIC5 BOB.

To fix this, introduce new hw_data parameter`pmic_bypass_mode`
to store bypass mode value. Use it to send correct PMIC bypass
mode value that corresponds to PMIC4/5 BOB regulators from the
helper function.

Fixes: 610f29e5cc0e8d58 ("regulator: qcom-rpmh: Update PMIC modes for PMIC5")
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Konrad Dybcio 
Signed-off-by: Kamal Wadhwa 
Link: https://patch.msgid.link/20260801-b4-read-rpmh-v5-v6-2-9fcb54928523@oss.qualcomm.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

regulator: core: use system_freezable_wq for init complete work

2026-09-14T11:40:07+00:00

[ Upstream commit 03eab318cedd6ae34ecd34533cd986edf5237164 ]

schedule_delayed_work() uses system_wq, which is non-freezable, allowing
regulator_init_complete_work to run concurrently with system suspend. This
work fires ~30s after boot to disable unused regulators via I2C. When it
races with PM suspend, the I2C adapter may already be suspended, triggering
a -ESHUTDOWN warning in __i2c_transfer():

  WARNING: ... at __i2c_transfer+0x36c/0x3c8
  Call trace:
   __i2c_transfer
   i2c_transfer
   regmap_i2c_write
   _regmap_update_bits
   regulator_disable_regmap
   _regulator_do_disable
   regulator_late_cleanup
   regulator_init_complete_work_function
   process_one_work

Switch to system_freezable_wq so the work is frozen before any device
is suspended, eliminating the race.

Fixes: 55576cf18537 ("regulator: Defer init completion for a while after late_initcall")
Signed-off-by: Joy Zou 
Reviewed-by: Frank Li 
Link: https://patch.msgid.link/20260731-b4-regulator-pf01-v2-1-a406c8737fdb@oss.nxp.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

regulator: tps65185: handle gpiod_get_value_cansleep() error returns

2026-09-14T11:39:55+00:00

[ Upstream commit 623d9a55685c52b10b995d8dbde9da6283170220 ]

tps65185_vposneg_enable() evaluated:
  if (gpiod_get_value_cansleep(data->pgood_gpio) != 1)
      return -ETIMEDOUT;

gpiod_get_value_cansleep() returns 1 if active, 0 if inactive, and a
negative error code (e.g. -EIO or -EINVAL) on failure. Evaluating != 1
treats a negative error code as non-equal, swallowing GPIO read errors and
masking them as -ETIMEDOUT.

Fix this by capturing the return value of gpiod_get_value_cansleep(). If
it returns a negative error code, propagate that error immediately; if
it returns 0 (inactive), return -ETIMEDOUT.

Fixes: b0fc1e770194 ("regulator: Add TPS65185 driver")
Signed-off-by: Surendra Singh Chouhan 
Reviewed-by: Andreas Kemnade 
Link: https://patch.msgid.link/20260724125858.75635-1-kr494167@gmail.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

regulator: adp5055: Fix error code in adp5055_of_parse_cb()

2026-09-14T11:39:30+00:00

[ Upstream commit 153bc959ce0f91b4446fb6fb805b8c1d2ca20c75 ]

This code accidentally returned the wrong variable instead of a negative
error code.  Return -EINVAL.

Fixes: 147b2a96f24e ("regulator: adp5055: Add driver for adp5055")
Signed-off-by: Dan Carpenter 
Link: https://patch.msgid.link/alFJVBbiFNxhqa_1@stanley.mountain
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

regulator: tps6594: Fix device node reference leaks in multiphase loop

2026-09-14T11:39:10+00:00

[ Upstream commit 7fd28093b3effc4f92566466df364622830ec608 ]

In tps6594_regulator_probe(), the multi-phase configuration loop calls
of_find_node_by_name() to find buck nodes by name, and of_get_parent()
twice to navigate to the PMIC parent node. None of the acquired node
references (np, intermediate parent, np_pmic_parent) are ever released
via of_node_put(), causing a reference leak on every loop iteration.

Additionally, of_find_node_by_name() can return NULL, but the result was
immediately passed to of_node_full_name() and of_get_parent() without a
NULL check, which could lead to a NULL pointer dereference.

Fix this by:
- Adding a NULL check for np after of_find_node_by_name()
- Storing the intermediate parent node in a local variable np_parent
- Calling of_node_put() on np, np_parent and np_pmic_parent at the
  end of each loop iteration

Fixes: f17ccc5deb4d ("regulator: tps6594-regulator: Add driver for TI TPS6594 regulators")
Signed-off-by: Uday Khare 
Link: https://patch.msgid.link/20260618132327.11529-1-udaykhare77@gmail.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

regulator: qcom-refgen: correct the regulator type to CURRENT

2026-09-07T15:37:06+00:00

commit 05dfeb2d0ccf87a7b92cd149a393b8423a26a04e upstream.

As per the REFGEN IP team, this block supplies the reference current to
the PHYs in the SoC. So, correct the regulator type to REGULATOR_CURRENT
to match with the HW behavior.

Fixes: 7cbfbe237960 ("regulator: Introduce Qualcomm REFGEN regulator driver")
Cc: stable@vger.kernel.org
Reviewed-by: Konrad Dybcio 
Signed-off-by: Kathiravan Thirumoorthy 
Link: https://patch.msgid.link/20260617-ipq9650_refgen-v4-1-c505ea6c6661@oss.qualcomm.com
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regulator: max8998_pmic_dt_parse_pdata: of_node_put on reg_np after ownership transferred to rdata

2026-09-07T15:37:06+00:00

commit 7c8cc25d8d86f9eb3979255935cfdc7d062ad746 upstream.

In max8998_pmic_dt_parse_pdata(), of_get_child_by_name() acquires a
reference on reg_np which is then stored in rdata->reg_node, transferring
ownership to the regulator data array. The subsequent of_node_put(reg_np)
at the end of the function releases the last matched regulator node's
reference, leaving rdata->reg_node as a dangling pointer for the last
entry.

Remove the spurious of_node_put(reg_np) call.

Cc: stable@vger.kernel.org
Fixes: 156f252857df ("drivers: regulator: add Maxim 8998 driver")
Signed-off-by: WenTao Liang 
Link: https://patch.msgid.link/20260626160326.54457-1-vulab@iscas.ac.cn
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regulator: as3722_get_regulator_dt_data: fix premature of_node_put leaving dangling of_node pointer

2026-09-07T15:37:06+00:00

commit f9324d670ae0b88cbfb0aa48fcaefa5baeb8da4c upstream.

In as3722_get_regulator_dt_data(), of_get_child_by_name() acquires a
reference on np, which is then assigned to pdev->dev.of_node. The
function immediately calls of_node_put(np), releasing the reference and
leaving pdev->dev.of_node as a dangling pointer.

Remove the of_node_put(np) call to let the device hold the reference.

Cc: stable@vger.kernel.org
Fixes: bc407334e9a6 ("regulator: as3722: add regulator driver for AMS AS3722")
Signed-off-by: WenTao Liang 
Link: https://patch.msgid.link/20260626160150.54291-1-vulab@iscas.ac.cn
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regulator: fp9931: Fix VPOS/VNEG voltage selector table

2026-07-31T17:40:28+00:00

The VPOSNEG_table[] mapping does not match the FP9931 datasheet.

The datasheet defines the VPOS/VNEG voltage mapping as:

  00h-04h ->  7.04V (-7.04V)
  05h     ->  7.26V (-7.26V)
  06h     ->  7.49V (-7.49V)
  ...
  28h-3Fh -> 15.06V (-15.06V)

However, VPOSNEG_table[] has two issues:

1. Selector 0x00~0x04 should all map to 7.04V (5 entries), but the
   table has 6 entries of 7.04V, causing all subsequent entries to be
   shifted by one position.

2. Selectors 0x29~0x3F should all clamp to 15.06V (23 entries), but
   the table has only 41 entries. Any selector value above 0x28
   would result in an out-of-bounds table access.

Fix both issues by removing the duplicate 7.04V entry and appending
the missing 23 clamped 15.06V entries, bringing the table to the
correct size of 64 entries (0x00~0x3F).

Fixes: 12d821bd13d4 ("regulator: Add FP9931/JD9930 driver")
Signed-off-by: Robby Cai 
Link: https://patch.msgid.link/20260724103441.800522-2-robby.cai@oss.nxp.com
Signed-off-by: Mark Brown