kernel/linux.git/drivers/regulator/arizona-ldo1.c, branch v6.12.81

regulator: arizona-ldo1: Convert to platform remove callback returning void

2023-12-11T12:54:25+00:00

The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König Link: https://msgid.link/r/76c7af01e2c8b3ab6585a04bc3f0d163fbb7fdf7.1701778038.git.u.kleine-koenig@pengutronix.de Acked-by: Charles Keepax Signed-off-by: Mark Brown

regulator: arizona-ldo1: Use PROBE_FORCE_SYNCHRONOUS

2023-03-23T13:50:58+00:00

Restore synchronous probing for Arizona regulators because otherwise the main MFD driver will not find its core supplies. As these regulators are built into the CODEC and typically have no DT representation the regulator framework is unaware of their existence until the driver probes. These means the probing of the driver needs to be synchronous to ensure the regulators are not substitued for the dummy later when the users request them. Fixes: 259b93b21a9f ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14") Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20230323132047.833737-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown

regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 4.19 and 5.4

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

This follows on the change ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14") but changes regulators didn't exist in Linux 4.19 but did exist in Linux 5.4. Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20230316125351.3.I45bf925ca9537da5f647e2acb0ad207c0c98af81@changeid Signed-off-by: Mark Brown

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: use linear_ranges helper

2020-05-08T17:18:13+00:00

Change the regulator helpers to use common linear_ranges code. Signed-off-by: Matti Vaittinen Reviewed-by: Mark Brown Acked-by: Charles Keepax Acked-by: Adam Thomson Link: https://lore.kernel.org/r/64f01d5e381b8631a271616b7790f9d5640974fb.1588944082.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown

regulator: arizona-ldo1: Add support for Cirrus Logic Madera codecs

2019-05-21T20:23:24+00:00

This adds a new driver identity "madera-ldo1" and probe function so that this driver can be used to control the LDO1 regulator on some Cirrus Logic Madera codecs. Signed-off-by: Richard Fitzgerald Signed-off-by: Charles Keepax Signed-off-by: Mark Brown

regulator: arizona: Switch to SPDX identifier

2019-04-17T16:40:14+00:00

Signed-off-by: Axel Lin Acked-by: Richard Fitzgerald Signed-off-by: Mark Brown

regulator: arizona_ldo1: Simplify arizona_ldo1_hc_set/get_voltage_sel

2019-02-26T11:48:34+00:00

Setup .vsel_reg and .vsel_mask then we can use the standard set/get_voltage_sel_regmap helpers to simplify the code. Signed-off-by: Axel Lin Acked-by: Charles Keepax Signed-off-by: Mark Brown

regulator: arizona-ldo1: Convert to use regulator_linear_range for ldo1_hc

2019-01-22T17:24:22+00:00

Signed-off-by: Axel Lin Acked-by: Charles Keepax Signed-off-by: Mark Brown

regulator: arizona-ldo1: Rely on core to handle GPIO descriptor

2018-12-12T16:49:36+00:00

After making sure that the regulator core always take over handling of the GPIO descriptors, the gpiod_put() on the errorpath of the Arizona LDO1 driver becomes redundant. Reported-by: Charles Keepax Signed-off-by: Linus Walleij Acked-by: Charles Keepax Signed-off-by: Mark Brown