Re: [PATCH 1/2] dm: core: read the device tree into plat data after pinctrl

Hi Mehmet,

On Wed, 19 Aug 2026 at 08:35, Mehmet Fide <[email protected]> wrote:
>
> From: Mehmet Fide <[email protected]>
>
> device_probe() calls device_of_to_plat() before it applies the "default"
> pinctrl state of the device, so a driver that acquires resources there
> sees them undone by the pinctrl state that follows.
>
> It has not always been that way. When the pinctrl uclass arrived in
> commit d90a5a30dec1 ("pinctrl: add pin control uclass support") the
> state was selected before ->ofdata_to_platdata() was called, and it
> stayed that way for four years. Commit 29f7d05a347a ("dm: core: Move
> ofdata_to_platdata() call earlier") then moved the call up so that the
> platform data would be read before the device is probed, which is
> reasonable in itself, but it also moved it above the pinctrl state,
> which nothing asked for.
>
> GPIOs are where this hurts. On most SoCs the direction of a pin lives in
> the GPIO block, so a pinctrl state cannot disturb it, but on Vybrid the
> output buffer enable is a bit of the pad register that pinctrl writes as
> well. A fixed regulator asks for its enable GPIO in of_to_plat(), so the
> pin is configured as an output and the pinctrl state of the same device
> then turns it back into an input. The USB host VBUS regulator of a
> Colibri VF50 is one of those: its pad reads 0x22ed once the regulator
> has been probed, the value from the device tree, output buffer disabled,
> and no USB device is ever powered.
>
> Move the call back below the pinctrl step. That is also the order Linux
> uses, and the order the board code of these boards used before the
> driver model: set the pin muxing up first, then take the pin. The
> pinctrl step itself cannot move up instead, because it relies on
> DM_FLAG_ACTIVATED having been set to break the recursion described above
> it.
>
> Nothing between the two positions needs plat data: the parent probe, the
> power domain and the pinctrl call all work off the device tree.
>
> Tested with test/py on sandbox, before and after: 11 failed, 414 passed,
> 210 skipped, 1 xfailed, 20 errors, the same failures both times, all of
> them from tools and images missing in my environment.
>
> Tested on a Colibri VF50 V1.2A on an Iris carrier, U-Boot 2026.07 from
> NAND: the pad of the VBUS pin reads 0x22ef after "usb start" instead of
> 0x22ed, a USB stick in the host port enumerates, and Linux still boots
> with Ethernet, SD card and USB working.
>
> Fixes: 29f7d05a347a ("dm: core: Move ofdata_to_platdata() call earlier")
> Signed-off-by: Mehmet Fide <[email protected]>
> ---
>  drivers/core/device.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/core/device.c b/drivers/core/device.c
> index 6024534ff93..ccdf0ab9220 100644
> --- a/drivers/core/device.c
> +++ b/drivers/core/device.c
> @@ -500,10 +500,6 @@ int device_probe(struct udevice *dev)
>         drv = dev->driver;
>         assert(drv);
>
> -       ret = device_of_to_plat(dev);
> -       if (ret)
> -               goto fail;
> -
>         /* Ensure all parents are probed */
>         if (dev->parent) {
>                 ret = device_probe(dev->parent);
> @@ -552,6 +548,10 @@ int device_probe(struct udevice *dev)
>                                   dev->name, ret, errno_str(ret));
>         }
>
> +       ret = device_of_to_plat(dev);
> +       if (ret)
> +               goto fail;
> +
>         if (CONFIG_IS_ENABLED(IOMMU) && dev->parent &&
>             (device_get_uclass_id(dev) != UCLASS_IOMMU)) {
>                 ret = dev_iommu_enable(dev);
> --
> 2.54.0
>

Firstly, we are going to need a sandbox test for this, preferably one
that gets a GPIO in the regulator, as you mention here (i.e. calls
regulator_common_of_to_plat()).

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.

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.

Regards,
Simon

[1] https://docs.u-boot-project.org/en/latest/develop/driver-model/design.html#reading-ofdata