linux-stable.git/drivers/regulator, branch v7.1.6 Linux kernel stable tree regulator: mt6358: use regmap helper to read fixed LDO calibration 2026-08-03T09:25:30+00:00 Daniel Golle daniel@makrotopia.org 2026-07-18T01:05:59+00:00 4f95592e1a90dc19beaa4a171fe04a7eb81d6e56 [ 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 <reg>_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 <daniel@makrotopia.org> Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Chen-Yu Tsai <wens@kernel.org> Link: https://patch.msgid.link/dcd98d81dede338c9bbb9700a9613c848b702e49.1784336005.git.daniel@makrotopia.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ 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 <reg>_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 <daniel@makrotopia.org>
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
Tested-by: Chen-Yu Tsai <wens@kernel.org>
Link: https://patch.msgid.link/dcd98d81dede338c9bbb9700a9613c848b702e49.1784336005.git.daniel@makrotopia.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
regulator: ltc3676: Fix incorrect IRQSTAT bit offsets 2026-07-24T14:21:21+00:00 Abhishek Ojha Abhishek.ojha@savoirfairelinux.com 2026-07-15T17:04:08+00:00 b7f5bd59ed1c3a950a41130e7e1709d11db5e150 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 <Abhishek.ojha@savoirfairelinux.com> Link: https://patch.msgid.link/20260715170408.295552-1-Abhishek.ojha@savoirfairelinux.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <Abhishek.ojha@savoirfairelinux.com>
Link: https://patch.msgid.link/20260715170408.295552-1-Abhishek.ojha@savoirfairelinux.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
regulator: core: regulator_lock_two() should test for EDEADLK not EDEADLOCK 2026-07-24T14:20:46+00:00 Timur Tabi ttabi@nvidia.com 2026-07-08T23:57:22+00:00 153d1b8b5bc30847eb70ad535f62f289aa9217e6 [ 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 <ttabi@nvidia.com> Link: https://patch.msgid.link/20260708235722.2953579-1-ttabi@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ 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 <ttabi@nvidia.com>
Link: https://patch.msgid.link/20260708235722.2953579-1-ttabi@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
regulator: scmi: fix of_node refcount leak in scmi_regulator_probe() 2026-07-18T14:55:43+00:00 Wentao Liang vulab@iscas.ac.cn 2026-05-27T10:48:50+00:00 a935b64548fcfe1d5b4dbdd31dddfb0d7019367f commit fa11039d6cdff84584a3ef8cc1f5e1b56e045da2 upstream. scmi_regulator_probe() calls of_find_node_by_name() which takes a reference on the returned device node. On the error path where process_scmi_regulator_of_node() fails, the function returns without calling of_node_put() on the child node, leaking the reference. Add of_node_put(np) on the error path to properly release the reference. Cc: stable@vger.kernel.org Fixes: 0fbeae70ee7c ("regulator: add SCMI driver") Signed-off-by: Wentao Liang <vulab@iscas.ac.cn> Link: https://patch.msgid.link/20260527104850.872415-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit fa11039d6cdff84584a3ef8cc1f5e1b56e045da2 upstream.

scmi_regulator_probe() calls of_find_node_by_name() which takes a
reference on the returned device node. On the error path where
process_scmi_regulator_of_node() fails, the function returns without
calling of_node_put() on the child node, leaking the reference.

Add of_node_put(np) on the error path to properly release the
reference.

Cc: stable@vger.kernel.org
Fixes: 0fbeae70ee7c ("regulator: add SCMI driver")
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20260527104850.872415-1-vulab@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
regulator: mt6363: select CONFIG_IRQ_DOMAIN 2026-05-26T14:17:16+00:00 Arnd Bergmann arnd@arndb.de 2026-05-26T10:19:37+00:00 29d87434cb91b7689de2917830ca82acfd2770f5 When build-testing this driver without CONFIG_IRQ_DOMAIN causes a compile-time error: drivers/regulator/mt6363-regulator.c: In function 'mt6363_regulator_probe': drivers/regulator/mt6363-regulator.c:884:18: error: implicit declaration of function 'irq_find_host' [-Wimplicit-function-declaration] 884 | domain = irq_find_host(interrupt_parent); | ^~~~~~~~~~~~~ drivers/regulator/mt6363-regulator.c:884:16: error: assignment to 'struct irq_domain *' from 'int' makes pointer from integer without a cast [-Wint-conversion] 884 | domain = irq_find_host(interrupt_parent); | ^ drivers/regulator/mt6363-regulator.c:896:30: error: implicit declaration of function 'irq_create_fwspec_mapping'; did you mean 'irq_create_of_mapping'? [-Wimplicit-function-declaration] 896 | info->virq = irq_create_fwspec_mapping(&fwspec); | ^~~~~~~~~~~~~~~~~~~~~~~~~ | irq_create_of_mapping This is rather hard to trigger because so many other drivers enable IRQ_DOMAIN already, but I ran into this on an s390 randconfig build. Ensure this is always enabled using a Kconfig 'select IRQ_DOMAIN' entry, as we do for all other users of this. Fixes: 3c36965df808 ("regulator: Add support for MediaTek MT6363 SPMI PMIC Regulators") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20260526102003.2527570-1-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> 
When build-testing this driver without CONFIG_IRQ_DOMAIN causes
a compile-time error:

drivers/regulator/mt6363-regulator.c: In function 'mt6363_regulator_probe':
drivers/regulator/mt6363-regulator.c:884:18: error: implicit declaration of function 'irq_find_host' [-Wimplicit-function-declaration]
  884 |         domain = irq_find_host(interrupt_parent);
      |                  ^~~~~~~~~~~~~
drivers/regulator/mt6363-regulator.c:884:16: error: assignment to 'struct irq_domain *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
  884 |         domain = irq_find_host(interrupt_parent);
      |                ^
drivers/regulator/mt6363-regulator.c:896:30: error: implicit declaration of function 'irq_create_fwspec_mapping'; did you mean 'irq_create_of_mapping'? [-Wimplicit-function-declaration]
  896 |                 info->virq = irq_create_fwspec_mapping(&fwspec);
      |                              ^~~~~~~~~~~~~~~~~~~~~~~~~
      |                              irq_create_of_mapping

This is rather hard to trigger because so many other drivers
enable IRQ_DOMAIN already, but I ran into this on an s390
randconfig build.

Ensure this is always enabled using a Kconfig 'select IRQ_DOMAIN'
entry, as we do for all other users of this.

Fixes: 3c36965df808 ("regulator: Add support for MediaTek MT6363 SPMI PMIC Regulators")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20260526102003.2527570-1-arnd@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: tps65219: fix irq_data.rdev not being assigned 2026-05-18T09:52:24+00:00 Alexander Sverdlin alexander.sverdlin@siemens.com 2026-05-18T08:31:11+00:00 f9b2d3b703d13df50c630997dfdc25648e96db0d Commit 64a6b577490c ("regulator: tps65219: Remove debugging helper function") removed the tps65219_get_rdev_by_name() helper along with the irq_data.rdev assignment that depended on it. This left irq_data.rdev uninitialized for all IRQs, causing undefined behavior when regulator_notifier_call_chain() is called from the IRQ handler: Internal error: Oops: 0000000096000004 pc : regulator_notifier_call_chain lr : tps65219_regulator_irq_handler Call trace: regulator_notifier_call_chain tps65219_regulator_irq_handler handle_nested_irq regmap_irq_thread irq_thread_fn irq_thread kthread ret_from_fork Instead of restoring a dedicated lookup array, restructure the probe function to combine regulator registration with IRQ registration in the same loop. This way the rdev returned by devm_regulator_register() is naturally available for assigning to irq_data.rdev without any auxiliary data structure. Non-regulator IRQs (SENSOR, TIMEOUT) that don't correspond to any registered regulator are registered with rdev=NULL, and the IRQ handler is protected with a NULL check to avoid crashing. Cc: stable@vger.kernel.org Closes: https://lore.kernel.org/all/aBDSTxALaOc-PD7X@gaggiata.pivistrello.it/ Reported-by: Francesco Dolcini <francesco@dolcini.it> Fixes: 64a6b577490c ("regulator: tps65219: Remove debugging helper function") Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Link: https://patch.msgid.link/20260518083113.2063368-1-alexander.sverdlin@siemens.com Signed-off-by: Mark Brown <broonie@kernel.org> 
Commit 64a6b577490c ("regulator: tps65219: Remove debugging helper
function") removed the tps65219_get_rdev_by_name() helper along with
the irq_data.rdev assignment that depended on it. This left
irq_data.rdev uninitialized for all IRQs, causing undefined behavior
when regulator_notifier_call_chain() is called from the IRQ handler:

  Internal error: Oops: 0000000096000004
  pc : regulator_notifier_call_chain
  lr : tps65219_regulator_irq_handler
  Call trace:
   regulator_notifier_call_chain
   tps65219_regulator_irq_handler
   handle_nested_irq
   regmap_irq_thread
   irq_thread_fn
   irq_thread
   kthread
   ret_from_fork

Instead of restoring a dedicated lookup array, restructure the probe
function to combine regulator registration with IRQ registration in
the same loop. This way the rdev returned by devm_regulator_register()
is naturally available for assigning to irq_data.rdev without any
auxiliary data structure.

Non-regulator IRQs (SENSOR, TIMEOUT) that don't correspond to any
registered regulator are registered with rdev=NULL, and the IRQ handler
is protected with a NULL check to avoid crashing.

Cc: stable@vger.kernel.org
Closes: https://lore.kernel.org/all/aBDSTxALaOc-PD7X@gaggiata.pivistrello.it/
Reported-by: Francesco Dolcini <francesco@dolcini.it>
Fixes: 64a6b577490c ("regulator: tps65219: Remove debugging helper function")
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Link: https://patch.msgid.link/20260518083113.2063368-1-alexander.sverdlin@siemens.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: Kconfig: fix a typo in help 2026-05-11T00:44:58+00:00 Ihor Matushchak ihor.matushchak@foobox.net 2026-05-08T08:49:33+00:00 cbdbfba9e8907bea923874d05d6a35ff429a5544 Fixes a typo in Kconfig, 'protectorvia' -> 'protector via'. Signed-off-by: Ihor Matushchak <ihor.matushchak@foobox.net> Link: https://patch.msgid.link/20260508084933.4076-1-ihor.matushchak@foobox.net Signed-off-by: Mark Brown <broonie@kernel.org> 
Fixes a typo in Kconfig, 'protectorvia' -> 'protector via'.

Signed-off-by: Ihor Matushchak <ihor.matushchak@foobox.net>
Link: https://patch.msgid.link/20260508084933.4076-1-ihor.matushchak@foobox.net
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: qcom-rpmh: Fix index for pmh0101 ldo16 2026-05-06T12:26:30+00:00 Fenglin Wu fenglin.wu@oss.qualcomm.com 2026-05-06T09:28:51+00:00 628497e6d925d43efb56e3ffecef0a9d217926b3 The wrong index is assigned to pmh0101 ldo16, which results incorrect rpmh resource being used when the regulator device is voted. Fix it. Fixes: 65efe5404d15 ("regulator: rpmh-regulator: Add RPMH regulator support for Glymur") Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/20260506-fix_pmh0101_ldo16_index-v1-1-cdc8708b01f4@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org> 
The wrong index is assigned to pmh0101 ldo16, which results incorrect
rpmh resource being used when the regulator device is voted. Fix it.

Fixes: 65efe5404d15 ("regulator: rpmh-regulator: Add RPMH regulator support for Glymur")
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://patch.msgid.link/20260506-fix_pmh0101_ldo16_index-v1-1-cdc8708b01f4@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: rpi-panel-attiny: add back GPIOLIB dependency 2026-04-30T04:12:29+00:00 Arnd Bergmann arnd@arndb.de 2026-04-29T13:57:34+00:00 7dfc0063022078a80fe5774815723c185e4b7b57 This driver provides a gpio chip, which is only possible when GPIOLIB is enabled, which was previously guaranteed by the CONFIG_OF_GPIO dependency that is now gone: ERROR: modpost: "gpiochip_get_data" [drivers/regulator/rpi-panel-attiny-regulator.ko] undefined! ERROR: modpost: "devm_gpiochip_add_data_with_key" [drivers/regulator/rpi-panel-attiny-regulator.ko] undefined! Add an explicit GPIOLIB dependency instead. Fixes: bf017304fce1 ("regulator: drop unneeded dependencies on OF_GPIO") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260429135812.112514-1-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> 
This driver provides a gpio chip, which is only possible when GPIOLIB
is enabled, which was previously guaranteed by the CONFIG_OF_GPIO
dependency that is now gone:

ERROR: modpost: "gpiochip_get_data" [drivers/regulator/rpi-panel-attiny-regulator.ko] undefined!
ERROR: modpost: "devm_gpiochip_add_data_with_key" [drivers/regulator/rpi-panel-attiny-regulator.ko] undefined!

Add an explicit GPIOLIB dependency instead.

Fixes: bf017304fce1 ("regulator: drop unneeded dependencies on OF_GPIO")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20260429135812.112514-1-arnd@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge tag 'regulator-fix-v7.1-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator 2026-04-24T20:06:25+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-04-24T20:06:25+00:00 f64399836125c8512f8a3fe72c1719795a9c5812 Pull regulator fix from Mark Brown: "Just one trivial cleanup of the user visible prompts in Kconfig here, standardising how we describe Qualcomm" * tag 'regulator-fix-v7.1-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: qcom: Unify user-visible "Qualcomm" name 
Pull regulator fix from Mark Brown:
 "Just one trivial cleanup of the user visible prompts in Kconfig here,
  standardising how we describe Qualcomm"

* tag 'regulator-fix-v7.1-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
  regulator: qcom: Unify user-visible "Qualcomm" name