Thus wrote Saravana Kannan (saravanak@xxxxxxxxxx):
> > With modules disabled, the kernel boots but probe fails for some
> > (non-mainline) drivers in my tree.
> Thanks Martin!
> > 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?
No. With the fsl,avic patch in place, all drivers are probed correctly.
> The property you are using is not a standard GPIO binding (-gpios,
> gpio, gpios) and I'm not surprised it's not working.
I know that I should be using the gpiod API as suggested by Geert.
BTW is this definition ok? Could its driver be converted to using the
gpiod api?
rtc: rtc {
compatible = "moxa,moxart-rtc";
gpio-rtc-sclk = <&gpio 5 0>;
...
> The gpio1 is probably getting probe deferred and ends up running after
> "my_driver".
I added a debug print in the probe function. It turned out that the
driver for gpio1 is probed for the first time after my_driver.
I removed the interrupt-controller property for gpio2 for testing. gpio2
was then probed much earlier.
Best regards,
Martin
