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

On Tue, Aug 25, 2026 at 12:16:18PM -0600, Simon Glass wrote:
> Hi Mehmet,
> 
> On 2026-08-20T10:25:21, Mehmet Fide <[email protected]> wrote:
> > dm: core: read the device tree into plat data after pinctrl
> >
> > 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.
> > [...]
> >
> > drivers/core/device.c | 8 ++++----
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> Please check my comments on v1 when patchwork is back up:
> 
> https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/

As mentioned on the call, lore is up to date:
https://lore.kernel.org/r/[email protected]/

-- 
Tom

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQTzzqh0PWDgGS+bTHor4qD1Cr/kCgUCao3fdAAKCRAr4qD1Cr/k
ChjPAP4s1+MjSM8qFDhc0XeYZ8njqzhU5qT3ZknwZZEhpR3U+gD+JCSX/N4Qm01F
crIUM+7Y+Vtt6bwlFIanj7mZqRxv+ww=
=JftB
-----END PGP SIGNATURE-----