linux/drivers/regulator, branch v5.10

regulator: ti-abb: Fix array out of bound read access on the first transition

2020-11-18T17:59:24Z

At the start of driver initialization, we do not know what bias setting the bootloader has configured the system for and we only know for certain the very first time we do a transition. However, since the initial value of the comparison index is -EINVAL, this negative value results in an array out of bound access on the very first transition. Since we don't know what the setting is, we just set the bias configuration as there is nothing to compare against. This prevents the array out of bound access. NOTE: Even though we could use a more relaxed check of "< 0" the only valid values(ignoring cosmic ray induced bitflips) are -EINVAL, 0+. Fixes: 40b1936efebd ("regulator: Introduce TI Adaptive Body Bias(ABB) on-chip LDO driver") Link: https://lore.kernel.org/linux-mm/CA+G9fYuk4imvhyCN7D7T6PMDH6oNp6HDCRiTUKMQ6QXXjBa4ag@mail.gmail.com/ Reported-by: Naresh Kamboju Reviewed-by: Arnd Bergmann Signed-off-by: Nishanth Menon Link: https://lore.kernel.org/r/20201118145009.10492-1-nm@ti.com Signed-off-by: Mark Brown

regulator: workaround self-referent regulators

2020-11-13T14:21:26Z

Workaround regulators whose supply name happens to be the same as its own name. This fixes boards that used to work before the early supply resolving was removed. The error message is left in place so that offending drivers can be detected. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable@vger.kernel.org Reported-by: Ahmad Fatoum Signed-off-by: Michał Mirosław Tested-by: Ahmad Fatoum # stpmic1 Link: https://lore.kernel.org/r/d703acde2a93100c3c7a81059d716c50ad1b1f52.1605226675.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown

regulator: avoid resolve_supply() infinite recursion

2020-11-13T14:21:25Z

When a regulator's name equals its supply's name the regulator_resolve_supply() recurses indefinitely. Add a check so that debugging the problem is easier. The "fixed" commit just exposed the problem. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable@vger.kernel.org Reported-by: Ahmad Fatoum Signed-off-by: Michał Mirosław Tested-by: Ahmad Fatoum # stpmic1 Link: https://lore.kernel.org/r/c6171057cfc0896f950c4d8cb82df0f9f1b89ad9.1605226675.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown

regulator: fix memory leak with repeated set_machine_constraints()

2020-11-13T14:21:24Z

Fixed commit introduced a possible second call to set_machine_constraints() and that allocates memory for rdev->constraints. Move the allocation to the caller so it's easier to manage and done once. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable@vger.kernel.org Signed-off-by: Michał Mirosław Tested-by: Ahmad Fatoum # stpmic1 Link: https://lore.kernel.org/r/78c3d4016cebc08d441aad18cb924b4e4d9cf9df.1605226675.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown

regulator: pfuze100: limit pfuze-support-disable-sw to pfuze{100,200}

2020-11-11T12:34:27Z

Limit the fsl,pfuze-support-disable-sw to the pfuze100 and pfuze200 variants. When enabling fsl,pfuze-support-disable-sw and using a pfuze3000 or pfuze3001, the driver would choose pfuze100_sw_disable_regulator_ops instead of the newly introduced and correct pfuze3000_sw_regulator_ops. Signed-off-by: Sean Nyekjaer Fixes: 6f1cf5257acc ("regualtor: pfuze100: correct sw1a/sw2 on pfuze3000") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20201110174113.2066534-1-sean@geanix.com Signed-off-by: Mark Brown

regulator: core: don't disable regulator if is_enabled return error.

2020-11-10T17:27:42Z

In regulator_late_cleanup when is_enabled failed, don't try to disable the regulator since it would likely to fail too and causing confusing error messages. Signed-off-by: Pi-Hsun Shih Link: https://lore.kernel.org/r/20201106064817.3290927-1-pihsun@chromium.org Signed-off-by: Mark Brown

regulator: defer probe when trying to get voltage from unresolved supply

2020-11-03T13:19:01Z

regulator_get_voltage_rdev() is called in regulator probe() when applying machine constraints. The "fixed" commit exposed the problem that non-bypassed regulators can forward the request to its parent (like bypassed ones) supply. Return -EPROBE_DEFER when the supply is expected but not resolved yet. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable@vger.kernel.org Signed-off-by: Michał Mirosław Reported-by: Ondřej Jirman Reported-by: Corentin Labbe Tested-by: Ondřej Jirman Link: https://lore.kernel.org/r/a9041d68b4d35e4a2dd71629c8a6422662acb5ee.1604351936.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown

Merge remote-tracking branch 'regulator/for-5.10' into regulator-next

2020-10-05T15:54:56Z

regulator: bd9576: Fix print

2020-10-05T15:18:40Z

The print in probe is done using pr_info. Correct print call would be dev_dbg because: - Severity should really be dbg - The dev pointer is given as first argument Signed-off-by: Matti Vaittinen Link: https://lore.kernel.org/r/c4f55add237455555df0597c72052022f7a669f6.1601885841.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown

regulator: qcom_smd: add pm8953 regulators

2020-10-05T15:18:37Z

The PM8953 is commonly used on board with MSM8953 SoCs or its variants: APQ8053, SDM(SDA)450 and SDM(SDA)632. It provides 7 SMPS and 23 LDO regulators. Signed-off-by: Vladimir Lypak Link: https://lore.kernel.org/r/20201004083413.324351-1-junak.pub@gmail.com Signed-off-by: Mark Brown