Unverified Commit cd7a38c4 authored by Jerome Brunet's avatar Jerome Brunet Committed by Mark Brown
Browse files

regulator: core: do not silently ignore provided init_data 



On DT platforms, if a regulator init_data is provided in config, it is
silently ignored in favor of the DT parsing done by the framework, if
of_match is set.

of_match is an indication that init_data is expected to be set based on DT
and the parsing should be done by the regulator framework.

If the regulator provider passed init_data it must be because it is useful
somehow, in such case of_match should be clear.

If the driver expects the framework to initialize this data on its
own, it should leave init_data clear.

Warn if both init_data and of_match are set, then default to the provided
init_data.

Signed-off-by: default avatarJerome Brunet <jbrunet@baylibre.com>
Link: https://patch.msgid.link/20241008-regulator-ignored-data-v2-1-d1251e0ee507@baylibre.com


Signed-off-by: default avatarMark Brown <broonie@kernel.org>
parent 42f7652d

drivers/regulator/core.c

+34 −23
Original line number Diff line number Diff line
@@ -5681,13 +5681,27 @@ regulator_register(struct device *dev, 
		goto clean;

	}



	init_data = regulator_of_get_init_data(dev, regulator_desc, config,

	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");



		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.

		 * 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;
@@ -5697,16 +5711,13 @@ regulator_register(struct device *dev, 
		/*

		 * 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

		 * 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);

	}



	ww_mutex_init(&rdev->mutex, &regulator_ww_class);