CODEWITHSUNDEEP
linux-kernelembeddeddevice-tree
Z0RrO
Z0RrO

Reputation: 83

Load kernel module prior of device tree's probing

I have developed a working driver for my custom_hardware that relies on the device tree. Because my driver may evolve, I do not want my driver to be part of the kernel (when I say 'be part of the kernel', I mean, to be compiled with the kernel during the kernel creation)

Here is a glimpse of my dts:

custom_hardware: custom_hardware@0x41006000 {
    compatible = "mfg,custom";
    reg = <0x41006000 0x1000>;
    #interrupt-cells = <0x1>;
    interrupt-controller;
};

existing_hardware: existing_hardward@41004000 {
    compatible = "mfg,existing";
    reg = <0x41004000 0x1000>;
    interrupt-parent = <&custom_hardware>;
    interrupts = <0>;
};

The existing_hardware's driver is already compiled with kernel (the existing_hardware's driver has been compiled with the kernel during the kernel creation).

What I would like to do is to append my custom_hardware's driver to the ramfs and let the kernel loads the custom_hardware's driver prior of the existing_hardware's driver.

This is important since the existing_hardware's driver requests a virq from the irq_domain of the custom_hardware's driver. In order to get the irq_domain, the custom_hardware's driver must be loaded first.

Note that the existing_hardware's driver gets loaded during the probing of the device tree which seems to happen in the early stage of the kernel booting sequence.

Upvotes: 1

Views: 3011

Answers (2)

Ray
Ray

Reputation: 5659

I had similar problem (probing order was wrong) and the only simple solution what I found is put the modules in the desired probing order into the Makefile. I've found the solution here: What is the Linux built-in driver load order?

Upvotes: 0

Alexandre Belloni
Alexandre Belloni

Reputation: 2304

That is not the way to do. The order of the module/driver loading must not matter. What you need to do is return -EPROBE_DEFER when getting the IRQ fails in existing_hardware. Then it will get probed again at a later time, hopefully after custom_hardware got probed.

Also, you can apply that patch that will ensure that request_irq() fails because the domain is not present yet and return -EPROBE_DEFER in that case https://lkml.org/lkml/2014/2/13/114

Upvotes: 2

Related Questions