Re: [PATCH 2/4] regulator: claim the enable GPIO at probe time, not in of_to_plat()

[Mehmet Fide <mehmet.fide@gmail.com>]

Hi Simon,

On 2026-09-10 Simon Glass wrote:
> The debug message is stale once the request moves to probe()

Will reword and add the missing newline.

> This quietly changes behaviour: the old of_to_plat() only
> debug()-logged a failure from gpio_request_by_name() and carried on,
> whereas probe() now aborts the device for any non-ENOENT error.

For the fixed regulator there is no change: regulator_common_of_to_plat()
already returned any error other than -ENOENT after the debug(), so a
missing controller or a busy pin failed the device before this series
too, only at a different stage. The change is real for the
gpio-regulator's voltage GPIO, which used to debug() and carry on even
though the driver cannot do anything without that GPIO. I will state
that in the commit message.

> Also the 'if (plat->gpio_dt.present)' guard duplicates the check that
> gpio_request_parsed() already does

Agreed, v2 drops the guards and tolerates -ENOENT in both places.

> Does fixed-clock ever actually carry an enable GPIO in the wild?

Not in this tree: the only regulator-fixed-clock node is the Colibri
iMX6ULL Ethernet PHY supply and it has no GPIO. The binding allows one
and Linux drives it next to the clock, but our set_enable() ignores it.
I added the request only to keep what the shared of_to_plat() did
before. Since nothing observable depends on it, v2 drops the call from
fixed-clock's probe() and says so in the commit message. Teaching
set_enable() to drive the GPIO as Linux does would be a separate patch,
if anyone needs it.

> Once the device is probed, gpio_dt is dead weight in plat

Yes. priv is not allocated when of_to_plat() runs, so plat is the only
place the parsed description can live; I will note the trade-off in the
commit message.

Regards,
Mehmet