On Wed, Apr 8, 2015 at 4:16 AM, Pantelis Antoniou <pantelis.antoniou@xxxxxxxxxxxx> wrote: > Hi Geert, > >> On Apr 8, 2015, at 11:42 , Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: >> >> 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. >> > > 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. As long as we need the timer interrupts before driver core starts we have to do it early. > Then we have dma controllers needing to be registered at subsys_initcall() for obvious reasons. These should be fixable with deferred probe. That requires fixing all the client drivers where as fixing the dependencies would not need driver changes. > 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. Solving the timer and timer dependencies (clocks, irq) won't really be possible within the driver model. > 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? I agree the dependency tracking structures should be in the core, but filling that in is going to be OF specific. Rob -- 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
