Hi Geert,
> On Apr 8, 2015, at 11:42 , Geert Uytterhoeven <ge...@linux-m68k.org> wrote:
>
> Hi Grant,
>
> On Thu, Apr 2, 2015 at 4:38 AM, Grant Likely <grant.lik...@secretlab.ca>
> wrote:
>> On Mon, 30 Mar 2015 15:27:27 +0200
>> , Geert Uytterhoeven <ge...@linux-m68k.org>
>> wrote:
>>> On Tue, Mar 24, 2015 at 6:56 PM, Pantelis Antoniou
>>> <pantelis.anton...@konsulko.com> wrote:
>>>>> On Mar 24, 2015, at 07:50 , Geert Uytterhoeven <ge...@linux-m68k.org>
>>>>> 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.
>
FWIW I’ve been digging deeper in the rabbit hole…
We do have some ugly warts in our core code. For instance the mess with the
interrupt
controllers being not created normally but by a special linker section magic.
Then we have dma controllers needing to be registered at subsys_initcall() for
obvious reasons.
I suspect things are similar for all subsystem services drivers.
The good thing about dependency tracking is that all of this is solved
automatically.
Since the devices will have references to the interrupt controller node it will
be shoved in front
of the dependency list. Same thing with dma, iommu etc.
I will have something that works shortly, but I would prefer to start some kind
of discussion
about what to do about device dependencies in the core, and not hack something
for just the OF
case.
What do you guys think?
> Gr{oetje,eeting}s,
>
> Geert
>
Regards
— Pantelis
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
