Unexpected behavior of of_regulator_get()?

[Luca Weiss]

Hi Mark and Liam,

My colleague Griffin is currently working on a patchset and while doing
this we discovered some seemingly unexpected behavior with the
of_regulator_get() family of functions.

In a simplified version, we have this devicetree structure:

	gpio-keys {
		compatible = "gpio-keys";

		event-hall-sensor {
			label = "Hall Effect Sensor";
			vdd-supply = <&vreg_l10b>;
		};
		key-volume-up {
			label = "Volume Up";
		};
		switch {
			label = "Switch";
		};
	};

Then on each subnode ("child") we call this function:

	devm_of_regulator_get_optional(dev, to_of_node(child), "vdd");

The expected behavior would be that for event-hall-sensor it sucessfully
gets the vdd-supply, and for key-volume-up and switch it does not, and
return -ENODEV.

However we see that for every one of the 3 nodes it successfully gets
the vdd-supply.

Looking through the code this seems to be caused by of_get_regulator()
first doing of_parse_phandle(node, prop_name, 0) which is checking on
the node itself.

But then if this does not succeed, it calls
of_get_child_regulator(dev->of_node, prop_name) which goes through every
child node of the top-level device (gpio-keys) until it finds a
regulator. So this will find the vdd-supply of event-hall-sensor even
for key-volume-up and switch.

Going through the git history shows this commit from 2018 [0] which
definitely has a different use-case in mind given the commit message so
that very much seems like an unintentional side effect (not that I fully
understand the addressed problem in the first place).

[0] fe06051dbf8a ("regulator/of_get_regulator: add child path to find the regulator supplier")

A workaround from the driver side would be to check for the presence of
vdd-supply on the child (fwnode_property_present(child, "vdd-supply"))
before trying to get a regulator but I feel like resolving this in the
regulator core would be the better solution?

Let me know your thoughts.

Regards
Luca