On Tue, Feb 2, 2021 at 11:44 PM Saravana Kannan [off-list ref] wrote:

On Tue, Feb 2, 2021 at 1:22 PM Martin Kaiser [off-list ref] wrote:

quoted

Thus wrote Saravana Kannan (saravanak@google.com):
All of those drivers have a gpio in
their device-tree node, such as

my_driver {
   gpio_test1 = <&gpio1 0 0>;
   ...
};

with gpio1 from arch/arm/boot/dts/imx25.dtsi.

The probe function calls

of_get_named_gpio(np, "gpio_test1", 0);

to get the gpio. This fails with -EINVAL.

And you didn't see this issue with the fsl,avic patch?

The property you are using is not a standard GPIO binding (-gpios,
gpio, gpios) and I'm not surprised it's not working. The gpio1 is
probably getting probe deferred and ends up running after "my_driver".

So my_driver doesn't support deferred probe, as of_get_named_gpio()
returns -EINVAL instead of -EPROBE_DEFER?
Converting my_driver from of_get_named_gpio() to the gpiod_*() API
should at least make the driver support probe deferral, after which I
expect it to start working again on reprobe?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds