Load kernel module prior of device tree's probing

Question

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.

You seem to be overstating the requirements. *" I do not want my driver to be part of the kernel."* *"Load kernel module prior (to) device tree probe."* Seems like the only salient requirement is that the *custom_hardware* driver needs to be installed before the *existing_hardware* driver, which can be accomplished within the existing framework. See this **[Q&A](http://stackoverflow.com/questions/15541290/what-is-the-difference-between-module-init-and-subsys-initcall-while-initializin/15542788#15542788)** — sawdust, Mar 24 '14 at 18:38

score 2 · Answer 1 · answered Mar 25 '14 at 09:03

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

score 0 · Answer 2 · edited May 23 '17 at 12:27

0

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?

edited May 23 '17 at 12:27

Community

1
1

answered Nov 12 '14 at 11:32

Ray

5,269
1
21
12

Load kernel module prior of device tree's probing

2 Answers2