linux-stable.git/drivers/regulator, branch linux-6.16.y

regulator: sy7636a: fix lifecycle of power good gpio

2025-09-19T14:37:38+00:00

[ Upstream commit c05d0b32eebadc8be6e53196e99c64cf2bed1d99 ]

Attach the power good gpio to the regulator device devres instead of the
parent device to fix problems if probe is run multiple times
(rmmod/insmod or some deferral).

Fixes: 8c485bedfb785 ("regulator: sy7636a: Initial commit")
Signed-off-by: Andreas Kemnade 
Reviewed-by: Alistair Francis 
Reviewed-by: Peng Fan 
Message-ID: <20250906-sy7636-rsrc-v1-2-e2886a9763a7@kernel.org>
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

regulator: tps65219: regulator: tps65219: Fix error codes in probe()

2025-08-28T14:34:47+00:00

[ Upstream commit 11cd7a5c21db020b8001aedcae27bd3fa9e1e901 ]

There is a copy and paste error and we accidentally use "PTR_ERR(rdev)"
instead of "error".  The "rdev" pointer is valid at this point.

Also there is no need to print the error code in the error message
because dev_err_probe() already prints that.  So clean up the error
message a bit.

Fixes: 38c9f98db20a ("regulator: tps65219: Add support for TPS65215 Regulator IRQs")
Signed-off-by: Dan Carpenter 
Link: https://patch.msgid.link/aKRGmVdbvT1HBvm8@stanley.mountain
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

regulator: pca9450: Use devm_register_sys_off_handler

2025-08-28T14:34:46+00:00

[ Upstream commit 447be50598c05499f7ccc2b1f6ddb3da30f8099a ]

With module test, there is error dump:
------------[ cut here ]------------
  notifier callback pca9450_i2c_restart_handler already registered
  WARNING: kernel/notifier.c:23 at notifier_chain_register+0x5c/0x88,
  CPU#0: kworker/u16:3/50
  Call trace:
  notifier_chain_register+0x5c/0x88 (P)
  atomic_notifier_chain_register+0x30/0x58
  register_restart_handler+0x1c/0x28
  pca9450_i2c_probe+0x418/0x538
  i2c_device_probe+0x220/0x3d0
  really_probe+0x114/0x410
  __driver_probe_device+0xa0/0x150
  driver_probe_device+0x40/0x114
  __device_attach_driver+0xd4/0x12c

So use devm_register_sys_off_handler to let kernel handle the resource
free to avoid kernel dump.

Fixes: 6157e62b07d9 ("regulator: pca9450: Add restart handler")
Signed-off-by: Peng Fan 
Link: https://patch.msgid.link/20250815-pca9450-v1-1-7748e362dc97@nxp.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

regulator: gpio: Fix the out-of-bounds access to drvdata::gpiods

2025-07-03T11:22:35+00:00

drvdata::gpiods is supposed to hold an array of 'gpio_desc' pointers. But
the memory is allocated for only one pointer. This will lead to
out-of-bounds access later in the code if 'config::ngpios' is > 1. So
fix the code to allocate enough memory to hold 'config::ngpios' of GPIO
descriptors.

While at it, also move the check for memory allocation failure to be below
the allocation to make it more readable.

Cc: stable@vger.kernel.org # 5.0
Fixes: d6cd33ad7102 ("regulator: gpio: Convert to use descriptors")
Signed-off-by: Manivannan Sadhasivam 
Link: https://patch.msgid.link/20250703103549.16558-1-mani@kernel.org
Signed-off-by: Mark Brown

regulator: mp886x: Fix ID table driver_data

2025-06-30T15:06:40+00:00

Currently, the driver_data of the i2c ID table is wrong, so it won't
work if any mp886x user makes use of the ID table. Fortunately, there's
no such user in upstream source code, we can fix the issue by using
different ID table entry for mp8867 and mp8869.

Signed-off-by: Jisheng Zhang 
Link: https://patch.msgid.link/20250629095918.912-1-jszhang@kernel.org
Signed-off-by: Mark Brown

regulator: sy8824x: Fix ID table driver_data

2025-06-30T15:06:39+00:00

Currently, the driver_data of the i2c ID table is wrong, so it won't
work if any sy8824x user makes use of the ID table. Fortunately, there's
no such user in upstream source code, we can fix the issue by using
different ID table entry for sy8824c, sy8824e, sy20276 and sy20278.

Signed-off-by: Jisheng Zhang 
Link: https://patch.msgid.link/20250629095905.898-1-jszhang@kernel.org
Signed-off-by: Mark Brown

regulator: tps65219: Fix devm_kmalloc size allocation

2025-06-29T21:10:41+00:00

In probe(), two arrays of structs are allocated with the devm_kmalloc()
function, but the memory size of the allocations were given as the arrays'
length (pmic->common_irq_size for the first call and pmic->dev_irq_size for
the second devm_kmalloc call). The memory size should have been the total
memory needed.

This led to a heap overflow when the struct array was used. The issue was
first discovered with the PocketBeagle2 and BeaglePlay. The common and
device-specific structs are now allocated one at a time within the loop.

Fixes: 38c9f98db20a ("regulator: tps65219: Add support for TPS65215 Regulator IRQs")
Reported-by: Dhruva Gole 
Closes: https://lore.kernel.org/all/20250619153526.297398-1-d-gole@ti.com/
Tested-by: Robert Nelson 
Acked-by: Andrew Davis 
Signed-off-by: Shree Ramamoorthy 
Reviewed-by: Nishanth Menon 
Link: https://patch.msgid.link/20250620154541.2713036-1-s-ramamoorthy@ti.com
Signed-off-by: Mark Brown

regulator: core: fix NULL dereference on unbind due to stale coupling data

2025-06-29T21:10:41+00:00

Failing to reset coupling_desc.n_coupled after freeing coupled_rdevs can
lead to NULL pointer dereference when regulators are accessed post-unbind.

This can happen during runtime PM or other regulator operations that rely
on coupling metadata.

For example, on ridesx4, unbinding the 'reg-dummy' platform device triggers
a panic in regulator_lock_recursive() due to stale coupling state.

Ensure n_coupled is set to 0 to prevent access to invalid pointers.

Signed-off-by: Alessandro Carminati 
Link: https://patch.msgid.link/20250626083809.314842-1-acarmina@redhat.com
Signed-off-by: Mark Brown

regulator: fan53555: add enable_time support and soft-start times

2025-06-16T12:26:23+00:00

The datasheets for all the fan53555 variants (and clones using the same
interface) define so called soft start times, from enabling the regulator
until at least some percentage of the output (i.e. 92% for the rk860x
types) are available.

The regulator framework supports this with the enable_time property
but currently the fan53555 driver does not define enable_times for any
variant.

I ran into a problem with this while testing the new driver for the
Rockchip NPUs (rocket), which does runtime-pm including disabling and
enabling a rk8602 as needed. When reenabling the regulator while running
a load, fatal hangs could be observed while enabling the associated
power-domain, which the regulator supplies.

Experimentally setting the regulator to always-on, made the issue
disappear, leading to the missing delay to let power stabilize.
And as expected, setting the enable-time to a non-zero value
according to the datasheet also resolved the regulator-issue.

The datasheets in nearly all cases only specify "typical" values,
except for the fan53555 type 08. There both a typical and maximum
value are listed - 40uS apart.

For all typical values I've added 100uS to be on the safe side.
Individual details for the relevant regulators below:

- fan53526:
  The datasheet for all variants lists a typical value of 150uS, so
  make that 250uS with safety margin.
- fan53555:
  types 08 and 18 (unsupported) are given a typical enable time of 135uS
  but also a maximum of 175uS so use that value. All the other types only
  have a typical time in the datasheet of 300uS, so give a bit margin by
  setting it to 400uS.
- rk8600 + rk8602:
  Datasheet reports a typical value of 260us, so use 360uS to be safe.
- syr82x + syr83x:
  All datasheets report typical soft-start values of 300uS for these
  regulators, so use 400uS.
- tcs452x:
  Datasheet sadly does not report a soft-start time, so I've not set
  an enable-time

Signed-off-by: Heiko Stuebner 
Link: https://patch.msgid.link/20250606190418.478633-1-heiko@sntech.de
Signed-off-by: Mark Brown

regulator: max20086: Fix refcount leak in max20086_parse_regulators_dt()

2025-06-08T22:29:48+00:00

There is a missing call to of_node_put() if devm_kcalloc() fails.
Fix this by changing the code to use cleanup.h magic to drop the
refcount.

Fixes: 6b0cd72757c6 ("regulator: max20086: fix invalid memory access")
Signed-off-by: Dan Carpenter 
Link: https://patch.msgid.link/aDVRLqgJWMxYU03G@stanley.mountain
Reviewed-by: Laurent Pinchart 
Signed-off-by: Mark Brown