kernel/linux.git/drivers/regulator/ab8500.c, branch v6.6

regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14

2023-03-20T13:11:25+00:00

Probing of regulators can be a slow operation and can contribute to slower boot times. This is especially true if a regulator is turned on at probe time (with regulator-boot-on or regulator-always-on) and the regulator requires delays (off-on-time, ramp time, etc). While the overall kernel is not ready to switch to async probe by default, as per the discussion on the mailing lists [1] it is believed that the regulator subsystem is in good shape and we can move regulator drivers over wholesale. There is no way to just magically opt in all regulators (regulators are just normal drivers like platform_driver), so we set PROBE_PREFER_ASYNCHRONOUS for all regulators found in 'drivers/regulator' individually. Given the number of drivers touched and the impossibility to test this ahead of time, it wouldn't be shocking at all if this caused a regression for someone. If there is a regression caused by this patch, it's likely to be one of the cases talked about in [1]. As a "quick fix", drivers involved in the regression could be fixed by changing them to PROBE_FORCE_SYNCHRONOUS. That being said, the correct fix would be to directly fix the problem that caused the issue with async probe. The approach here follows a similar approach that was used for the mmc subsystem several years ago [2]. In fact, I ran nearly the same python script to auto-generate the changes. The only thing I changed was to search for "i2c_driver", "spmi_driver", and "spi_driver" in addition to "platform_driver". [1] https://lore.kernel.org/r/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk [2] https://lore.kernel.org/r/20200903232441.2694866-1-dianders@chromium.org/ Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20230316125351.1.I2a4677392a38db5758dee0788b2cea5872562a82@changeid Signed-off-by: Mark Brown

regulator: ab8500: Decomission platform data header

2021-01-13T11:36:19+00:00

The platform data header was only used to pass platform data from board files. We now populate the regulators exclusively from device tree, so the header contents can be moved into the regulator drivers. Cc: Lee Jones Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20201205004057.1712753-2-linus.walleij@linaro.org Signed-off-by: Mark Brown

regulator: ab8500: Remove unused embedded struct expand_register

2020-06-25T19:11:13+00:00

Used primarily for the AB8540 which lost support in early 2018. It is now deemed safe to remove this legacy data structure. Also fixes W=1 issue: drivers/regulator/ab8500.c:88: warning: Function parameter or member 'expand_register' not described in 'ab8500_regulator_info' Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20200625163614.4001403-6-lee.jones@linaro.org Signed-off-by: Mark Brown

regulator: ab8500: remove some defined but not used variables

2020-04-14T15:57:43+00:00

Fix the following gcc warning: drivers/regulator/ab8500.c:195:27: warning: ‘ldo_vdmic_voltages’ defined but not used [-Wunused-const-variable=] static const unsigned int ldo_vdmic_voltages[] = { ^~~~~~~~~~~~~~~~~~ drivers/regulator/ab8500.c:169:27: warning: ‘fixed_3300000_voltage’ defined but not used [-Wunused-const-variable=] static const unsigned int fixed_3300000_voltage[] = { ^~~~~~~~~~~~~~~~~~~~~ drivers/regulator/ab8500.c:142:27: warning: ‘ldo_sdio_voltages’ defined but not used [-Wunused-const-variable=] static const unsigned int ldo_sdio_voltages[] = { ^~~~~~~~~~~~~~~~~ Reported-by: Hulk Robot Signed-off-by: Jason Yan Link: https://lore.kernel.org/r/20200410073343.39031-1-yanaijie@huawei.com Signed-off-by: Mark Brown

regulator: ab8500: Remove AB8505 USB regulator

2019-11-07T13:09:58+00:00

The USB regulator was removed for AB8500 in commit 41a06aa738ad ("regulator: ab8500: Remove USB regulator"). It was then added for AB8505 in commit 547f384f33db ("regulator: ab8500: add support for ab8505"). However, there was never an entry added for it in ab8505_regulator_match. This causes all regulators after it to be initialized with the wrong device tree data, eventually leading to an out-of-bounds array read. Given that it is not used anywhere in the kernel, it seems likely that similar arguments against supporting it exist for AB8505 (it is controlled by hardware). Therefore, simply remove it like for AB8500 instead of adding an entry in ab8505_regulator_match. Fixes: 547f384f33db ("regulator: ab8500: add support for ab8505") Cc: Linus Walleij Signed-off-by: Stephan Gerhold Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20191106173125.14496-1-stephan@gerhold.net Signed-off-by: Mark Brown

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 197

2019-05-30T18:29:22+00:00

Based on 1 normalized pattern(s): license terms gnu general public license v2 extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 37 file(s). Signed-off-by: Thomas Gleixner Reviewed-by: Steve Winslow Reviewed-by: Alexios Zavras Reviewed-by: Richard Fontana Reviewed-by: Allison Randal Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190528170027.724130665@linutronix.de Signed-off-by: Greg Kroah-Hartman

regulator: ab8500: Remove *regulator from struct ab8500_regulator_info

2019-04-15T08:43:58+00:00

Current code is using devm_regulator_register() so we don't need to save *regulator for clean up, use a local variable instead. Signed-off-by: Axel Lin Signed-off-by: Mark Brown

regulator: ab8500: Constify regulator_ops

2019-04-15T08:43:47+00:00

These regulator_ops variables never need to be modified, make them const so compiler can put them to .rodata. Signed-off-by: Axel Lin Signed-off-by: Mark Brown

regulator: ab8500: Drop AB8540/9540 support

2018-04-16T12:08:59+00:00

The AB8540 was an evolved version of the AB8500, but it was never mass produced or put into products, only reference designs exist. The upstream support was never completed and it is unlikely that this will happen so drop the support for now to simplify maintenance of the AB8500. Cc: Loic Pallardy Signed-off-by: Linus Walleij Signed-off-by: Mark Brown

regulator: drop owner assignment from platform_drivers

2014-10-20T14:21:29+00:00

A platform_driver does not need to set an owner, it will be populated by the driver core. Signed-off-by: Wolfram Sang