linux-stable.git/drivers/regulator, branch v6.6.86 Linux kernel stable tree regulator: check that dummy regulator has been probed before using it 2025-03-28T20:59:54+00:00 Christian Eggers ceggers@arri.de 2025-03-13T10:27:39+00:00 998b1aae22dca87da392ea35f089406cbef6032d commit 2c7a50bec4958f1d1c84d19cde518d0e96a676fd upstream. 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 <ceggers@arri.de> Link: https://patch.msgid.link/20250313103051.32430-3-ceggers@arri.de Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 2c7a50bec4958f1d1c84d19cde518d0e96a676fd upstream.

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 <ceggers@arri.de>
Link: https://patch.msgid.link/20250313103051.32430-3-ceggers@arri.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
regulator: dummy: force synchronous probing 2025-03-28T20:59:54+00:00 Christian Eggers ceggers@arri.de 2025-03-11T09:18:02+00:00 e26f24ca4fb940b15e092796c5993142a2558bd9 commit 8619909b38eeebd3e60910158d7d68441fc954e9 upstream. 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 <ceggers@arri.de> Link: https://patch.msgid.link/20250311091803.31026-1-ceggers@arri.de Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 8619909b38eeebd3e60910158d7d68441fc954e9 upstream.

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 <ceggers@arri.de>
Link: https://patch.msgid.link/20250311091803.31026-1-ceggers@arri.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
regulator: core: Add missing newline character 2025-02-08T08:52:29+00:00 Alexander Stein alexander.stein@ew.tq-group.com 2025-01-22T07:20:19+00:00 c0f6111bb525d86f3a6befb1f29771684b372cad [ Upstream commit 155c569fa4c3b340fbf8571a0e42dd415c025377 ] 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 <alexander.stein@ew.tq-group.com> Link: https://patch.msgid.link/20250122072019.1926093-1-alexander.stein@ew.tq-group.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 155c569fa4c3b340fbf8571a0e42dd415c025377 ]

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 <alexander.stein@ew.tq-group.com>
Link: https://patch.msgid.link/20250122072019.1926093-1-alexander.stein@ew.tq-group.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
regulator: of: Implement the unwind path of of_regulator_match() 2025-02-08T08:51:55+00:00 Joe Hattori joe@pf.is.s.u-tokyo.ac.jp 2025-01-04T08:04:53+00:00 d54308079d0513f2a884bacae1b1a8fa4c0a1834 [ Upstream commit dddca3b2fc676113c58b04aaefe84bfb958ac83e ] of_regulator_match() does not release the OF node reference in the error path, resulting in an OF node leak. Therefore, call of_node_put() on the obtained nodes before returning the EINVAL error. Since it is possible that some drivers call this function and do not exit on failure, such as s2mps11_pmic_driver, clear the init_data and of_node in the error path. This was reported by an experimental verification tool that I am developing. As I do not have access to actual devices nor the QEMU board configuration to test drivers that call this function, no runtime test was able to be performed. Fixes: 1c8fa58f4750 ("regulator: Add generic DT parsing for regulators") Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp> Link: https://patch.msgid.link/20250104080453.2153592-1-joe@pf.is.s.u-tokyo.ac.jp Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit dddca3b2fc676113c58b04aaefe84bfb958ac83e ]

of_regulator_match() does not release the OF node reference in the error
path, resulting in an OF node leak. Therefore, call of_node_put() on the
obtained nodes before returning the EINVAL error.

Since it is possible that some drivers call this function and do not
exit on failure, such as s2mps11_pmic_driver, clear the init_data and
of_node in the error path.

This was reported by an experimental verification tool that I am
developing. As I do not have access to actual devices nor the QEMU board
configuration to test drivers that call this function, no runtime test
was able to be performed.

Fixes: 1c8fa58f4750 ("regulator: Add generic DT parsing for regulators")
Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Link: https://patch.msgid.link/20250104080453.2153592-1-joe@pf.is.s.u-tokyo.ac.jp
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
regulator: rk808: Restrict DVS GPIOs to the RK808 variant only 2024-12-09T09:31:54+00:00 Dragan Simic dsimic@manjaro.org 2024-10-14T10:43:41+00:00 52c3eb1c8ce8c1555fe923e4dda91c27deb8bf05 [ Upstream commit 0d214f27c0e3d9694284c95bac1502c2d247355b ] The rk808-regulator driver supports multiple PMIC variants from the Rockckip RK80x and RK81x series, but the DVS GPIOs are supported on the RK808 variant only, according to the DT bindings [1][2][3][4][5][6] and the datasheets for the supported PMIC variants. [7][8][9][10][11][12] Thus, change the probe path so the "dvs-gpios" property is checked for and its value possibly used only when the handled PMIC variant is RK808. There's no point in doing that on the other PMIC variants, because they don't support the DVS GPIOs, and it goes against the DT bindings to allow a possible out- of-place "dvs-gpios" property to actually be handled in the driver. This eliminates the following messages, emitted when the "dvs-gpios" property isn't found in the DT, from the kernel log on boards that actually don't use the RK808 variant, which may have provided a source of confusion: rk808-regulator rk808-regulator.2.auto: there is no dvs0 gpio rk808-regulator rk808-regulator.2.auto: there is no dvs1 gpio Furthermore, demote these kernel messages to debug messages, because they are useful during the board bringup phase only. Emitting them afterwards, on the boards that use the RK808 variant, but actually don't use the DVS0/1 GPIOs, clutters the kernel log a bit, while they provide no value and may actually cause false impression that some PMIC-related issues are present. [1] Documentation/devicetree/bindings/mfd/rockchip,rk805.yaml [2] Documentation/devicetree/bindings/mfd/rockchip,rk806.yaml [3] Documentation/devicetree/bindings/mfd/rockchip,rk808.yaml [4] Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml [5] Documentation/devicetree/bindings/mfd/rockchip,rk817.yaml [6] Documentation/devicetree/bindings/mfd/rockchip,rk818.yaml [7] https://rockchip.fr/RK805%20datasheet%20V1.2.pdf [8] https://wmsc.lcsc.com/wmsc/upload/file/pdf/v2/lcsc/2401261533_Rockchip-RK806-1_C5156483.pdf [9] https://rockchip.fr/RK808%20datasheet%20V1.4.pdf [10] https://rockchip.fr/RK816%20datasheet%20V1.3.pdf [11] https://rockchip.fr/RK817%20datasheet%20V1.01.pdf [12] https://rockchip.fr/RK818%20datasheet%20V1.0.pdf Fixes: 11375293530b ("regulator: rk808: Add regulator driver for RK818") Reported-by: Diederik de Haas <didi.debian@cknow.org> Signed-off-by: Dragan Simic <dsimic@manjaro.org> Link: https://patch.msgid.link/9a415c59699e76fc7b88a2552520a4ca2538f44e.1728902488.git.dsimic@manjaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 0d214f27c0e3d9694284c95bac1502c2d247355b ]

The rk808-regulator driver supports multiple PMIC variants from the Rockckip
RK80x and RK81x series, but the DVS GPIOs are supported on the RK808 variant
only, according to the DT bindings [1][2][3][4][5][6] and the datasheets for
the supported PMIC variants. [7][8][9][10][11][12]

Thus, change the probe path so the "dvs-gpios" property is checked for and
its value possibly used only when the handled PMIC variant is RK808.  There's
no point in doing that on the other PMIC variants, because they don't support
the DVS GPIOs, and it goes against the DT bindings to allow a possible out-
of-place "dvs-gpios" property to actually be handled in the driver.

This eliminates the following messages, emitted when the "dvs-gpios" property
isn't found in the DT, from the kernel log on boards that actually don't use
the RK808 variant, which may have provided a source of confusion:

  rk808-regulator rk808-regulator.2.auto: there is no dvs0 gpio
  rk808-regulator rk808-regulator.2.auto: there is no dvs1 gpio

Furthermore, demote these kernel messages to debug messages, because they are
useful during the board bringup phase only.  Emitting them afterwards, on the
boards that use the RK808 variant, but actually don't use the DVS0/1 GPIOs,
clutters the kernel log a bit, while they provide no value and may actually
cause false impression that some PMIC-related issues are present.

[1] Documentation/devicetree/bindings/mfd/rockchip,rk805.yaml
[2] Documentation/devicetree/bindings/mfd/rockchip,rk806.yaml
[3] Documentation/devicetree/bindings/mfd/rockchip,rk808.yaml
[4] Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml
[5] Documentation/devicetree/bindings/mfd/rockchip,rk817.yaml
[6] Documentation/devicetree/bindings/mfd/rockchip,rk818.yaml
[7] https://rockchip.fr/RK805%20datasheet%20V1.2.pdf
[8] https://wmsc.lcsc.com/wmsc/upload/file/pdf/v2/lcsc/2401261533_Rockchip-RK806-1_C5156483.pdf
[9] https://rockchip.fr/RK808%20datasheet%20V1.4.pdf
[10] https://rockchip.fr/RK816%20datasheet%20V1.3.pdf
[11] https://rockchip.fr/RK817%20datasheet%20V1.01.pdf
[12] https://rockchip.fr/RK818%20datasheet%20V1.0.pdf

Fixes: 11375293530b ("regulator: rk808: Add regulator driver for RK818")
Reported-by: Diederik de Haas <didi.debian@cknow.org>
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Link: https://patch.msgid.link/9a415c59699e76fc7b88a2552520a4ca2538f44e.1728902488.git.dsimic@manjaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
regulator: rk808: Add apply_bit for BUCK3 on RK809 2024-12-09T09:31:38+00:00 Mikhail Rudenko mike.rudenko@gmail.com 2024-10-17T18:37:28+00:00 fd782cb8f9d3aa6369b851a58f4788d6f3efbae6 [ Upstream commit 5e53e4a66bc7430dd2d11c18a86410e3a38d2940 ] Currently, RK809's BUCK3 regulator is modelled in the driver as a configurable regulator with 0.5-2.4V voltage range. But the voltage setting is not actually applied, because when bit 6 of PMIC_POWER_CONFIG register is set to 0 (default), BUCK3 output voltage is determined by the external feedback resistor. Fix this, by setting bit 6 when voltage selection is set. Existing users which do not specify voltage constraints in their device trees will not be affected by this change, since no voltage setting is applied in those cases, and bit 6 is not enabled. Signed-off-by: Mikhail Rudenko <mike.rudenko@gmail.com> Link: https://patch.msgid.link/20241017-rk809-dcdc3-v1-1-e3c3de92f39c@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 5e53e4a66bc7430dd2d11c18a86410e3a38d2940 ]

Currently, RK809's BUCK3 regulator is modelled in the driver as a
configurable regulator with 0.5-2.4V voltage range. But the voltage
setting is not actually applied, because when bit 6 of
PMIC_POWER_CONFIG register is set to 0 (default), BUCK3 output voltage
is determined by the external feedback resistor. Fix this, by setting
bit 6 when voltage selection is set. Existing users which do not
specify voltage constraints in their device trees will not be affected
by this change, since no voltage setting is applied in those cases,
and bit 6 is not enabled.

Signed-off-by: Mikhail Rudenko <mike.rudenko@gmail.com>
Link: https://patch.msgid.link/20241017-rk809-dcdc3-v1-1-e3c3de92f39c@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
regulator: rtq2208: Fix uninitialized use of regulator_config 2024-11-14T12:19:30+00:00 ChiYuan Huang cy_huang@richtek.com 2024-10-25T05:59:18+00:00 9b7c0405af667857b3ad24a7ef6723f5475a9e43 [ Upstream commit 2feb023110843acce790e9089e72e9a9503d9fa5 ] Fix rtq2208 driver uninitialized use to cause kernel error. Fixes: 85a11f55621a ("regulator: rtq2208: Add Richtek RTQ2208 SubPMIC") Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://patch.msgid.link/00d691cfcc0eae9ce80a37b62e99851e8fdcffe2.1729829243.git.cy_huang@richtek.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 2feb023110843acce790e9089e72e9a9503d9fa5 ]

Fix rtq2208 driver uninitialized use to cause kernel error.

Fixes: 85a11f55621a ("regulator: rtq2208: Add Richtek RTQ2208 SubPMIC")
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://patch.msgid.link/00d691cfcc0eae9ce80a37b62e99851e8fdcffe2.1729829243.git.cy_huang@richtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
regulator: Return actual error in of_regulator_bulk_get_all() 2024-10-04T14:29:02+00:00 Chen-Yu Tsai wenst@chromium.org 2024-08-22T07:20:45+00:00 1ccd886abf45aeb6bca5c45a0ed19cd31dceb070 [ Upstream commit 395a41a1d3e377462f3eea8a205ee72be8885ff6 ] If regulator_get() in of_regulator_bulk_get_all() returns an error, that error gets overridden and -EINVAL is always passed out. This masks probe deferral requests and likely won't work properly in all cases. Fix this by letting of_regulator_bulk_get_all() return the original error code. Fixes: 27b9ecc7a9ba ("regulator: Add of_regulator_bulk_get_all") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://patch.msgid.link/20240822072047.3097740-3-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 395a41a1d3e377462f3eea8a205ee72be8885ff6 ]

If regulator_get() in of_regulator_bulk_get_all() returns an error, that
error gets overridden and -EINVAL is always passed out. This masks probe
deferral requests and likely won't work properly in all cases.

Fix this by letting of_regulator_bulk_get_all() return the original
error code.

Fixes: 27b9ecc7a9ba ("regulator: Add of_regulator_bulk_get_all")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://patch.msgid.link/20240822072047.3097740-3-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
regulator: bd71815: fix ramp values 2024-06-27T11:49:09+00:00 Kalle Niemi kaleposti@gmail.com 2024-06-12T11:42:34+00:00 47a0fe77b6c89628499ea0978b1d302834c66b59 [ Upstream commit 4cac29b846f38d5f0654cdfff5c5bfc37305081c ] Ramp values are inverted. This caused wrong values written to register when ramp values were defined in device tree. Invert values in table to fix this. Signed-off-by: Kalle Niemi <kaleposti@gmail.com> Fixes: 1aad39001e85 ("regulator: Support ROHM BD71815 regulators") Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/ZmmJXtuVJU6RgQAH@latitude5580 Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 4cac29b846f38d5f0654cdfff5c5bfc37305081c ]

Ramp values are inverted. This caused wrong values written to register
when ramp values were defined in device tree.

Invert values in table to fix this.

Signed-off-by: Kalle Niemi <kaleposti@gmail.com>
Fixes: 1aad39001e85 ("regulator: Support ROHM BD71815 regulators")
Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://lore.kernel.org/r/ZmmJXtuVJU6RgQAH@latitude5580
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
regulator: core: Fix modpost error "regulator_get_regmap" undefined 2024-06-27T11:49:08+00:00 Biju Das biju.das.jz@bp.renesas.com 2024-06-10T19:55:32+00:00 186d77852555470933a3225e2ace467fc33243e7 [ Upstream commit 3f60497c658d2072714d097a177612d34b34aa3d ] Fix the modpost error "regulator_get_regmap" undefined by adding export symbol. Fixes: 04eca28cde52 ("regulator: Add helpers for low-level register access") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202406110117.mk5UR3VZ-lkp@intel.com Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20240610195532.175942-1-biju.das.jz@bp.renesas.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 3f60497c658d2072714d097a177612d34b34aa3d ]

Fix the modpost error "regulator_get_regmap" undefined by adding export
symbol.

Fixes: 04eca28cde52 ("regulator: Add helpers for low-level register access")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202406110117.mk5UR3VZ-lkp@intel.com
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20240610195532.175942-1-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>