6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jerome Brunet jbrunet@baylibre.com
[ Upstream commit 35e21de48e693af1dcfdbf2dc3d73dcfa3c8f2d9 ]
This reverts commit cd7a38c40b231350a3cd0fd774f4e6bb68c4b411.
When submitting the change above, it was thought that the origin of the init_data should be a clear choice, from the driver or from DT but not both.
It turns out some devices, such as qcom-msm8974-lge-nexus5-hammerhead, relied on the old behaviour to override the init_data provided by the driver, making it some kind of default if none is provided by the platform.
Using the init_data provided by the driver when it is present broke these devices so revert the change to fixup the situation and add a comment to make things a bit more clear
Reported-by: Luca Weiss luca@lucaweiss.eu Closes: https://lore.kernel.org/lkml/5857103.DvuYhMxLoT@lucaweiss.eu Fixes: cd7a38c40b23 ("regulator: core: do not silently ignore provided init_data") Signed-off-by: Jerome Brunet jbrunet@baylibre.com Link: https://patch.msgid.link/20250211-regulator-init-data-fixup-v1-1-5ce1c6cff99... Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/regulator/core.c | 61 ++++++++++++++++++---------------------- 1 file changed, 27 insertions(+), 34 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 13d9c3e349682..8524018e89914 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -5643,43 +5643,36 @@ regulator_register(struct device *dev, goto clean; }
- if (config->init_data) { - /* - * Providing of_match means the framework is expected to parse - * DT to get the init_data. This would conflict with provided - * init_data, if set. Warn if it happens. - */ - if (regulator_desc->of_match) - dev_warn(dev, "Using provided init data - OF match ignored\n"); + /* + * DT may override the config->init_data provided if the platform + * needs to do so. If so, config->init_data is completely ignored. + */ + init_data = regulator_of_get_init_data(dev, regulator_desc, config, + &rdev->dev.of_node);
+ /* + * Sometimes not all resources are probed already so we need to take + * that into account. This happens most the time if the ena_gpiod comes + * from a gpio extender or something else. + */ + if (PTR_ERR(init_data) == -EPROBE_DEFER) { + ret = -EPROBE_DEFER; + goto clean; + } + + /* + * We need to keep track of any GPIO descriptor coming from the + * device tree until we have handled it over to the core. If the + * config that was passed in to this function DOES NOT contain + * a descriptor, and the config after this call DOES contain + * a descriptor, we definitely got one from parsing the device + * tree. + */ + if (!cfg->ena_gpiod && config->ena_gpiod) + dangling_of_gpiod = true; + if (!init_data) { init_data = config->init_data; rdev->dev.of_node = of_node_get(config->of_node); - - } else { - init_data = regulator_of_get_init_data(dev, regulator_desc, - config, - &rdev->dev.of_node); - - /* - * Sometimes not all resources are probed already so we need to - * take that into account. This happens most the time if the - * ena_gpiod comes from a gpio extender or something else. - */ - if (PTR_ERR(init_data) == -EPROBE_DEFER) { - ret = -EPROBE_DEFER; - goto clean; - } - - /* - * We need to keep track of any GPIO descriptor coming from the - * device tree until we have handled it over to the core. If the - * config that was passed in to this function DOES NOT contain a - * descriptor, and the config after this call DOES contain a - * descriptor, we definitely got one from parsing the device - * tree. - */ - if (!cfg->ena_gpiod && config->ena_gpiod) - dangling_of_gpiod = true; }
ww_mutex_init(&rdev->mutex, ®ulator_ww_class);