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). -- 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
