Hi Simon,
On 25/08/2026 at 14:56, Simon Glass wrote:
> The problem is the grey area of what is supposed to be done in
> of_to_plat(). The doc section is at [1] and perhaps it should be more
> explicit. We really should not be probing devices in of_to_plat(). The
> idea is to read from the device tree and store that information in the
> plat data. Then it gets used during probe().
>
> As to substance, I believe the 2019 change is correct - of_plat is a
> phase separate to and before probe. There should be no need to probe a
> parent in order to read a child's platdata.
That is a fair point, and it explains why the reorder felt too big a
hammer: the real offender is regulator_common_of_to_plat() calling
gpio_request_by_name(), which probes the GPIO controller and claims the
pin during the of_to_plat phase. I withdraw this patch.
> So perhaps what is needed here is clearly documentation about what
> should and should not be done in of_to_plat() and in particular a
> function to read the GPIO info without actually requesting the GPIO,
> so generic functions like regulator_common_of_to_plat() can do the
> right thing.
For the next version I would do it as you describe:
1. a helper that only parses the gpios property into a gpio_desc
(no controller probe, no claiming), for use in of_to_plat();
2. a matching call that requests the previously parsed descriptor,
for use in probe(); regulator_common_of_to_plat() moves to the
pair, so the pin is claimed at probe time, after pinctrl;
3. a paragraph in the driver-model docs stating that of_to_plat()
must not probe or claim resources;
4. a sandbox test with a fixed regulator whose enable GPIO goes
through regulator_common_of_to_plat(), asserting the pin state
survives the device's pinctrl.
The ehci-vf VBUS patch that depended on this will be rebased on top of
that instead. Does that split look right to you?
Thanks,
Mehmet
