Is registration of IRQ resources dependent on nodes order?

[Alexander Sverdlin]

Hello!

In our custom MIPS64 based project we are experiencing a problem with of_platform_populate() and in
particular, how IRQ resources are added to the populated devices. In our device tree we have a chain of
cascaded interrupt-controllers. Following Linux device-driver model we are trying to pair a driver of
interrupt-controller with a platform_device that should be registered in of_platform_populate().
This works fine, but unfortunately interrupt-generating devices that have this controller as
interrupt-parent do not properly receive their IRQ resources in corresponding platform_device structures.

The unsuccessful sequence is as following:
of_platform_populate() ->
...
of_device_alloc() ->
of_irq_to_resource_table() ->
of_irq_to_resource() ->
irq_of_parse_and_map() ->
of_irq_map_one() -- this one seems to be ok, because operate only on device-tree, but the next one is
irq_create_of_mapping(), which does the following:

	domain = controller ? irq_find_host(controller) : irq_default_domain;
	if (!domain) {
		...

It might be (and in our case it is so), that there is no domain registered yet at this point, it was not
populated yet by of_platform_populate() and therefore controller driver probe() function was not called.

Both ePAPR 1.1 and "Open Firmware Recommended Practice: Interrupt Mapping" do not specify the order
how IRQ controller and those nodes that have it as interrupt-parent should follow each other.

DTB unflattening code can be changed and the order how nodes appear in the lists can change.
of_platform_populate() must not depend on this order.

Am I missing something there? Or this is really a flaw in current irq_domains - of_* coupling code?
Any ideas on the possible patch?
Should irq_of_parse_and_map() or of_irq_map_one() first check if the corresponding controller node is
already populated as platform_device and if not, do it?

Why it works for some existing code in Linux (everything abowe and below is from Linux 3.7):
- some IRQ controller drivers register their irq_domain not in the probe function of the drivers, but
in some platform init code (before device tree is populated)
- many .dts files within Linux source tree have IRQ generating devices described before the controller
thanks to some internal dtb-processing code properties, they appear in reverse order in resulting
unflattened device tree, so that controller is populated before it's users

--
Best regards,
Alexander.