Hi Grant, On Thu, Apr 2, 2015 at 4:38 AM, Grant Likely <grant.likely@xxxxxxxxxxxx> wrote: > On Mon, 30 Mar 2015 15:27:27 +0200 > , Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> > wrote: >> On Tue, Mar 24, 2015 at 6:56 PM, Pantelis Antoniou >> <pantelis.antoniou@xxxxxxxxxxxx> wrote: >> >> On Mar 24, 2015, at 07:50 , Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: >> >> IIUC, this would fix the issue I worked around in "ARM: shmobile: r8a73a4: >> >> Move pfc node to work around probe ordering bug"? >> >> https://git.kernel.org/cgit/linux/kernel/git/horms/renesas.git/commit/?h=r8a73a4-ccf-and-multiplatform-for-v4.1&id=e4ba0a9bddff3ba52cec100414d2f178440efc91 > There are two ways to fix this so that .dtb order doesn't matter. The > dirty hack is to change the pfc driver to use subsys_initcall (level 4) > or later so that it happens after the devices are registered. The second I've just tried that, and it doesn't work. > solution is to make the pfc drivers able to return -EPROBE_DEFER, but > that also requires fixing deferred probe to start retrying devices > before late_initcall time. Right now there is a holdoff flag that All the pfc driver can detect is that some platform_device.resource[i] are empty (resource_type zero). Returning -EPROBE_DEFER won't help, as the resource won't change later. The problem is not the initialization order of the device drivers, but the creation order of the platform devices. of_device_alloc() silently (except for the pr_debug() message) ignores any failures to setup IRQ resources. Hence platform devices for interrupt providers must be created before platform devices for interrupt consumers, which is what the reordering in DT fixes. See also the information in the commit message linked at the top. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
