Hi Nate, On Mon, 12 Sept 2022 at 14:57, Nate Drude <nat...@variscite.com> wrote: > > Hi Simon and Fabio, > > On 9/12/22 3:16 PM, Simon Glass wrote: > > Hi, > > > > On Mon, 12 Sept 2022 at 12:48, Fabio Estevam <feste...@gmail.com> wrote: > >> > >> Hi Nate and Simon, > >> > >> On Mon, Sep 12, 2022 at 2:55 PM Nate Drude <nat...@variscite.com> wrote: > >>> > >>> gpio_hog_probe_all is invoked by init_sequence_r in board_r.c. > >>> If device_probe fails for any gpio-hog, boot hangs with the following > >>> error: > >>> > >>>> initcall sequence 00000000fffc8e18 failed at call 000000004023b320 > >>>> (err=-121) > >>>> ### ERROR ### Please RESET the board ### > >>> > >>> gpio-hog-optional allows the boot sequence to continue if device_probe > >>> fails for optional gpio-hog(s). > >>> > >>> Signed-off-by: Nate Drude <nat...@variscite.com> > >>> --- > >>> doc/device-tree-bindings/gpio/gpio.txt | 1 + > >>> drivers/gpio/gpio-uclass.c | 4 +++- > >>> 2 files changed, 4 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/doc/device-tree-bindings/gpio/gpio.txt > >>> b/doc/device-tree-bindings/gpio/gpio.txt > >>> index 1481ed607d..02d296316b 100644 > >>> --- a/doc/device-tree-bindings/gpio/gpio.txt > >>> +++ b/doc/device-tree-bindings/gpio/gpio.txt > >>> @@ -189,6 +189,7 @@ gpio-controller's driver probe function. > >>> Each GPIO hog definition is represented as a child node of the GPIO > >>> controller. > >>> Required properties: > >>> - gpio-hog: A property specifying that this child node represents a > >>> GPIO hog. > >>> +- gpio-hog-optional: A property specifying to continue boot when > >>> device_probe fails in gpio_hog_probe_all > >> > >> gpio-hog-optional property does not exist in Linux. > >> > >> If this property is introduced then U-Boot and Linux devicetrees will > >> not be in sync. > >> > >> Can this be fixed differently? > > > > Nate, can you send a patch to Linux with the binding update? > > > > Regards, > > Simon > > Thanks for your responses and feedback. > > I don't think gpio-hog-optional is relevant to Linux.
Sure, but Linux is (for better or worse) the main repo for the device tree bindings. > > The problem is if gpio_hog_probe_all returns an error, board_init_r will > hang() > > See: > - https://github.com/u-boot/u-boot/blob/v2022.07/common/board_r.c#L824-L825 > - https://github.com/u-boot/u-boot/blob/v2022.07/common/board_r.c#L763 > - > https://github.com/u-boot/u-boot/blob/v2022.07/drivers/gpio/gpio-uclass.c#L330-L332 > > A practical example of how this may occur is when an i2c gpio expander > (e.g. nxp,pca9534) uses gpio-hog, but the gpio expander is depopulated. > > Arguably, the best solution is to use a different device tree when the > gpio expander is not populated. This patch allows the gpio-hog to fail > gracefully and continue booting if gpio-hog-optional is used. > > Do you have any suggestions for a better approach? Does it make sense > for gpio_hog_probe_all to cause a fatal error when the gpio hog probe > fails (most devices, including the gpio-expander, will not cause a hang > if they fail to probe)? I think your approach is fine as is. Regards, Simon