Hi Rob, On Wed, Apr 8, 2015 at 3:40 PM, Rob Herring <robherring2@xxxxxxxxx> wrote: > On Wed, Apr 8, 2015 at 3:42 AM, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: >> 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. > > This doesn't sound right. It ignores failures because platform_get_irq > will parse the interrupts when called rather than just using the > resource struct and will return EPROBE_DEFER if the irq resource is > not ready. We left the of_device_alloc code in to be safe, but we > should be able to remove it. Thanks, using platform_get_irq() (and propagating EPROBE_DEFER) instead of accessing the platform_device's resources directly indeed does work, but will require some rework in the sh-pfc driver. One more thing to consider for a "porting your driver to DT" tutorial ;-) One side effect is that almost all drivers now end up being probe-deferred, as the pinctrl configuration can't be done until the pfc driver is active. 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
