On 7 February 2013 00:38, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Wed, Feb 06, 2013 at 05:31:24PM +0100, Linus Walleij wrote: >> On Wed, Feb 6, 2013 at 1:31 PM, Haojian Zhuang >> <haojian.zhuang@xxxxxxxxxx> wrote: >> >> CC Grant on this issue... >> >> > On 6 February 2013 19:52, Russell King - ARM Linux >> > <linux@xxxxxxxxxxxxxxxx> wrote: >> >> On Wed, Feb 06, 2013 at 07:47:14PM +0800, Haojian Zhuang wrote: >> >>> If uart driver is probed defer, console_setup will be called later >> >>> after __init && __initdata sections destroyed. And amba_console isn't >> >>> defined in __init or __initdata section. So we needn't define >> >>> pl011_console_setup() && pl011_console_get_options() in __init section. >> >> >> >> It sounds like there's a deeper problem here - if this driver being >> >> deferred, why isn't it being retried after the pinctrl stuff gets >> >> its driver registered? >> >> >> >> We've had bugs in this deferred probing before, I wouldn't be surprised >> >> if there's more... and we should not be "fixing" drivers because of bugs >> >> elsewhere. >> > >> > It retried if driver is being deferred. But those console setup >> > functions are released >> > since they're declared in __init section. >> > >> > rest_init() >> > --> creates kernel_init thread that could free __init section memory >> > >> > deferred_probe_initicall() creates a workqueue that is used to retry >> > deferred probe >> > function. >> > >> > I think that these two threads are competing. >> >> Now that is the *real* problem. The __init sections surely should >> not be discarded until *after* all deferred probes are complete >> and the deferral workqueue terminates. >> >> How about writing a patch to fix that instead? (If possible...) > > Well, we have the facilities to flush workqueues, so it should be possible. > > However, I'm just wondering if this shows that we _do_ need to get rid > of a pile of __init marked functions as well as fixing this, thanks to > the deferred probing we now have (maybe the whole __init thing becomes > useless with deferred probing?) There's nothing really to guarantee > that the pinctrl stuff will be available by the time the init sections > are discarded (it could be in a loadable module?) or indeed any other > resources that might be necessary. > > I think in this regard, deferred probing has opened a similar can of > worms which hotplug devices created (which eventually ended up with > killing the __dev* marking). At first, I considered to remove those __init functions. But it may seem unreasonable. Now I'm trying to reuse wait_for_device_probe() after do_initcalls(). Please help to review. Thanks Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
