Re: [PATCH v2 0/3] Make fw_devlink=on more forgiving

On Wed, Feb 3, 2021 at 1:58 PM Martin Kaiser [off-list ref] wrote:

Thus wrote Saravana Kannan (saravanak@google.com):

quoted

quoted

With modules disabled, the kernel boots but probe fails for some
(non-mainline) drivers in my tree.

quoted

Thanks Martin!

quoted

quoted

All of those drivers have a gpio in
their device-tree node, such as

quoted

quoted

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

quoted

quoted

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

quoted

quoted

The probe function calls

quoted

quoted

of_get_named_gpio(np, "gpio_test1", 0);

quoted

quoted

to get the gpio. This fails with -EINVAL.

quoted

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.

quoted

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 correct non-deprecated binding AFAIK is something-gpios. Not
gpio-something. And then you can use different APIs to get the GPIO (I
forget what it's called).

-Saravana

quoted

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.