On Wed, Apr 8, 2015 at 3:42 AM, Geert Uytterhoeven <[email protected]> wrote: > Hi Grant, > > On Thu, Apr 2, 2015 at 4:38 AM, Grant Likely <[email protected]> > wrote: >> On Mon, 30 Mar 2015 15:27:27 +0200 >> , Geert Uytterhoeven <[email protected]> >> wrote: >>> On Tue, Mar 24, 2015 at 6:56 PM, Pantelis Antoniou >>> <[email protected]> wrote: >>> >> On Mar 24, 2015, at 07:50 , Geert Uytterhoeven <[email protected]> >>> >> 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. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
