Hi Nate,
On Mon, 12 Sept 2022 at 14:57, Nate Drude nate.d@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 festevam@gmail.com wrote:
Hi Nate and Simon,
On Mon, Sep 12, 2022 at 2:55 PM Nate Drude nate.d@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 nate.d@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#L3...
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