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
