kernel/git/stable/linux.git/drivers/regulator, branch linux-6.18.y

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

2026-09-14T11:35:41+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:35:23+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: adp5055: Fix error code in adp5055_of_parse_cb()

2026-09-14T11:34:41+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:34:26+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:22:44+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:22:43+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:22:43+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: mt6358: use regmap helper to read fixed LDO calibration

2026-08-03T09:21:40+00:00

[ Upstream commit 1d26f125501f3fbe6c259ab75bf6516299a0bf0e ] The "fixed" LDOs with output voltage calibration use mt6358_get_buck_voltage_sel as their get_voltage_sel op, but the MT6358_REG_FIXED and MT6366_REG_FIXED entries do not populate da_vsel_reg/da_vsel_mask. The op therefore reads register 0x0 with a zero mask and shifts the result by ffs(0) - 1 = -1, which is undefined behaviour and gets flagged by UBSAN on every boot on MT6366 boards: UBSAN: shift-out-of-bounds in drivers/regulator/mt6358-regulator.c:384:38 shift exponent -1 is negative Call trace: mt6358_get_buck_voltage_sel+0xc8/0x120 regulator_get_voltage_rdev+0x70/0x170 set_machine_constraints+0x504/0xc38 regulator_register+0x324/0xc68 Besides the undefined shift, the returned selector is always 0, so the actual calibration offset programmed in _ANA_CON0 is never reported. The descriptor already carries the correct vsel_reg/vsel_mask (the ANA_CON0 calibration field), matching the regulator_set_voltage_sel_regmap op already in use. Read the selector back through regulator_get_voltage_sel_regmap instead. Fixes: cf08fa74c716 ("regulator: mt6358: Add output voltage fine tuning to fixed regulators") Signed-off-by: Daniel Golle Reviewed-by: Chen-Yu Tsai Tested-by: Chen-Yu Tsai Link: https://patch.msgid.link/dcd98d81dede338c9bbb9700a9613c848b702e49.1784336005.git.daniel@makrotopia.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: ltc3676: Fix incorrect IRQSTAT bit offsets

2026-07-24T14:17:17+00:00

commit 50dce2e2f84b56d8b4b406d97a1543709e8a87f5 upstream. The LTC3676_IRQSTAT_* bit definitions do not match the IRQSTAT (Interrupt Request Status) register layout documented in Table 15 of the LTC3676/LTC3676-1 datasheet: bit 0 - Pushbutton Status Active bit 1 - Hard Reset Occurred bit 2 - PGOOD Timeout Occurred bit 3 - Undervoltage Warning bit 4 - Undervoltage Standby (Fault) Occurred bit 5 - Overtemperature Warning bit 6 - Overtemperature Standby (Fault) Occurred bit 7 - Reserved The driver instead defines these starting at bit 3, one bit higher than the datasheet specifies, which causes ltc3676_regulator_isr() to check the wrong status bits and misreport (or miss) PGOOD timeout, undervoltage and thermal warning/fault conditions. Fix the bit offsets to match the datasheet. Fixes: 37b918a034fe ("regulator: Add LTC3676 support") Cc: stable@vger.kernel.org Signed-off-by: Abhishek Ojha Link: https://patch.msgid.link/20260715170408.295552-1-Abhishek.ojha@savoirfairelinux.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

regulator: core: regulator_lock_two() should test for EDEADLK not EDEADLOCK

2026-07-24T14:16:50+00:00

[ Upstream commit d38f8bd771c4999b797d7074b348cf201414bd34 ] Compare against -EDEADLK, which is what ww_mutex_lock() actually returns and what every other deadlock check in this file already uses. Function regulator_lock_two() acquires two regulators via regulator_lock_nested() -> ww_mutex_lock(). On contention, ww_mutex_lock() returns -EDEADLK, which is the caller's signal to drop the lock it holds and retry the acquisition in the canonical order. However, regulator_lock_two() tests the return value against -EDEADLOCK rather than -EDEADLK. On most architectures, EDEADLK and EDEADLOCK are the same value, so the comparison happens to be correct and the bug is invisible. But on MIPS, SPARC, and PowerPC, those two errors have different values. The test is wrong: a genuine -EDEADLK backoff no longer matches -EDEADLOCK, so instead of unlocking and retrying, the code falls into WARN_ON(ret) and returns with only one of the two regulators locked. In practice, this is a bug only on MIPS, because the regulator core is not built or used on the other two platforms. In general, EDEADLK is preferred over EDEADLOCK for new code. Fixes: cba6cfdc7c3f ("regulator: core: Avoid lockdep reports when resolving supplies") Signed-off-by: Timur Tabi Link: https://patch.msgid.link/20260708235722.2953579-1-ttabi@nvidia.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin