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

regulator: of: Fix refcount leak bug in of_get_regulation_constraints()

2022-08-17T12:40:40+00:00

[ Upstream commit 66efb665cd5ad69b27dca8571bf89fc6b9c628a4 ] We should call the of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount. Fixes: 40e20d68bb3f ("regulator: of: Add support for parsing regulator_state for suspend state") Signed-off-by: Liang He Link: https://lore.kernel.org/r/20220715111027.391032-1-windhl@126.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: qcom_smd: Fix pm8916_pldo range

2022-08-17T12:40:32+00:00

[ Upstream commit e8977917e116d1571dacb8e9864474551c1c12bd ] The PM8916 device specification [1] documents a programmable range of 1.75V to 3.337V with 12.5mV steps for the PMOS LDOs in PM8916. This range is also used when controlling the regulator directly using the qcom_spmi-regulator driver ("ult_pldo" there). However, for some reason the qcom_smd-regulator driver allows a much larger range for the same hardware component. This could be simply a typo, since the start of the range is essentially just missing a '1'. In practice this does not cause any major problems, since the driver just sends the actual voltage to the RPM firmware instead of making use of the incorrect voltage selector. Still, having the wrong range there is confusing and prevents the regulator core from validating requests correctly. [1]: https://developer.qualcomm.com/download/sd410/pm8916pm8916-1-power-management-ic-device-specification.pdf Fixes: 57d6567680ed ("regulator: qcom-smd: Add PM8916 support") Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20220623094614.1410180-2-stephan.gerhold@kernkonzept.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: scmi: Fix refcount leak in scmi_regulator_probe

2022-06-09T08:30:15+00:00

[ Upstream commit 68d6c8476fd4f448e70e0ab31ff972838ac41dae ] of_find_node_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Fixes: 0fbeae70ee7c ("regulator: add SCMI driver") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220516074433.32433-1-linmq006@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: pfuze100: Fix refcount leak in pfuze_parse_regulators_dt

2022-06-09T08:30:09+00:00

[ Upstream commit afaa7b933ef00a2d3262f4d1252087613fb5c06d ] of_node_get() returns a node with refcount incremented. Calling of_node_put() to drop the reference when not needed anymore. Fixes: 3784b6d64dc5 ("regulator: pfuze100: add pfuze100 regulator driver") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220511113506.45185-1-linmq006@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: qcom_smd: Fix up PM8950 regulator configuration

2022-06-09T08:30:08+00:00

[ Upstream commit b11b3d21a94d66bc05d1142e0b210bfa316c62be ] Following changes have been made: - S5, L4, L18, L20 and L21 were removed (S5 is managed by SPMI, whereas the rest seems not to exist [or at least it's blocked by Sony Loire /MSM8956/ RPM firmware]) - Supply maps have were adjusted to reflect regulator changes. Fixes: e44adca5fa25 ("regulator: qcom_smd: Add PM8950 regulators") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20220430163753.609909-1-konrad.dybcio@somainline.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: core: Fix enable_count imbalance with EXCLUSIVE_GET

2022-06-09T08:30:07+00:00

[ Upstream commit c3e3ca05dae37f8f74bb80358efd540911cbc2c8 ] Since the introduction of regulator->enable_count, a driver that did an exclusive get on an already-enabled regulator would end up with enable_count initialized to 0 but rdev->use_count initialized to 1. With that starting point the regulator is effectively stuck enabled, because if the driver attempted to disable it it would fail the enable_count underflow check in _regulator_handle_consumer_disable(). The EXCLUSIVE_GET path in _regulator_get() now initializes enable_count along with rdev->use_count so that the regulator can be disabled without underflowing the former. Signed-off-by: Zev Weiss Fixes: 5451781dadf85 ("regulator: core: Only count load for enabled consumers") Link: https://lore.kernel.org/r/20220505043152.12933-1-zev@bewilderbeest.net Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: da9121: Fix uninit-value in da9121_assign_chip_model()

2022-06-09T08:30:00+00:00

[ Upstream commit bab76514aca36bc513224525d5598da676938218 ] KASAN report slab-out-of-bounds in __regmap_init as follows: BUG: KASAN: slab-out-of-bounds in __regmap_init drivers/base/regmap/regmap.c:841 Read of size 1 at addr ffff88803678cdf1 by task xrun/9137 CPU: 0 PID: 9137 Comm: xrun Tainted: G W 5.18.0-rc2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: dump_stack_lvl+0xe8/0x15a lib/dump_stack.c:88 print_report.cold+0xcd/0x69b mm/kasan/report.c:313 kasan_report+0x8e/0xc0 mm/kasan/report.c:491 __regmap_init+0x4540/0x4ba0 drivers/base/regmap/regmap.c:841 __devm_regmap_init+0x7a/0x100 drivers/base/regmap/regmap.c:1266 __devm_regmap_init_i2c+0x65/0x80 drivers/base/regmap/regmap-i2c.c:394 da9121_i2c_probe+0x386/0x6d1 drivers/regulator/da9121-regulator.c:1039 i2c_device_probe+0x959/0xac0 drivers/i2c/i2c-core-base.c:563 This happend when da9121 device is probe by da9121_i2c_id, but with invalid dts. Thus, chip->subvariant_id is set to -EINVAL, and later da9121_assign_chip_model() will access 'regmap' without init it. Fix it by return -EINVAL from da9121_assign_chip_model() if 'chip->subvariant_id' is invalid. Fixes: f3fbd5566f6a ("regulator: da9121: Add device variants") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Reviewed-by: Adam Ward Link: https://lore.kernel.org/r/20220421090335.1876149-1-weiyongjun1@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: atc260x: Fix missing active_discharge_on setting

2022-04-04T07:59:43+00:00

Without active_discharge_on setting, the SWITCH1 discharge enable control is always disabled. Fix it. Fixes: 3b15ccac161a ("regulator: Add regulator driver for ATC260x PMICs") Signed-off-by: Axel Lin Link: https://lore.kernel.org/r/20220403132235.123727-1-axel.lin@ingics.com Signed-off-by: Mark Brown

regulator: rtq2134: Fix missing active_discharge_on setting

2022-04-04T07:38:57+00:00

The active_discharge_on setting was missed, so output discharge resistor is always disabled. Fix it. Fixes: 0555d41497de ("regulator: rtq2134: Add support for Richtek RTQ2134 SubPMIC") Signed-off-by: Axel Lin Link: https://lore.kernel.org/r/20220404022514.449231-1-axel.lin@ingics.com Signed-off-by: Mark Brown

regulator: wm8994: Add an off-on delay for WM8994 variant

2022-04-04T07:38:56+00:00

As per Table 130 of the wm8994 datasheet at [1], there is an off-on delay for LDO1 and LDO2. In the wm8958 datasheet [2], I could not find any reference to it. I could not find a wm1811 datasheet to double-check there, but as no one has complained presumably it works without it. This solves the issue on Samsung Aries boards with a wm8994 where register writes fail when the device is powered off and back-on quickly. [1] https://statics.cirrus.com/pubs/proDatasheet/WM8994_Rev4.6.pdf [2] https://statics.cirrus.com/pubs/proDatasheet/WM8958_v3.5.pdf Signed-off-by: Jonathan Bakker Acked-by: Charles Keepax Link: https://lore.kernel.org/r/CY4PR04MB056771CFB80DC447C30D5A31CB1D9@CY4PR04MB0567.namprd04.prod.outlook.com Signed-off-by: Mark Brown