On Thursday 14 February 2013, Haojian Zhuang wrote: > On 14 February 2013 23:57, Arnd Bergmann <a...@arndb.de> wrote: > > On Thursday 14 February 2013, Haojian Zhuang wrote: > >> If you can change it into code in below, it could work. Otherwise, it > >> always fails. > >> driver_deferred_probe_enable = true; > >> driver_deferred_probe_trigger(); > >> + deferred_probe_work_func(NULL); > >> return 0; > >> > >> Because deferred_probe_work_func() depends on that deferred_probe is added > >> into deferred_probe_active_list. If driver_deferred_probe_trigger() isn't > >> called > >> first, the deferred uart probe can't be added into active list. So even > >> you call > >> work_func at here, it doesn't help. > >> > > > > Would that not cause two instances of the work function to run at the same > > time? > > That sounds like a source for a lot of problems. > > > > Arnd > > Two instances of the work function? I'm sorry that I don't > understanding your meaning. > Could you help explain your question?
I mean you end up calling the work function directly, while it gets run as part of the work queue on a different CPU at the same time. I just noticed that there is actually locking in place in deferred_probe_work_func that prevents any actual bugs, but you are still adding extra overhead here. Maybe just add flush_workqueue(deferred_wq); here? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/