On Tue, Feb 2, 2021 at 11:44 PM Saravana Kannan <sarava...@google.com> wrote:
> On Tue, Feb 2, 2021 at 1:22 PM Martin Kaiser <mar...@kaiser.cx> wrote:
> > Thus wrote Saravana Kannan (sarava...@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 -- ge...@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
