On 15 February 2013 00:50, Arnd Bergmann <[email protected]> wrote: > On Thursday 14 February 2013, Haojian Zhuang wrote: >> On 14 February 2013 23:57, Arnd Bergmann <[email protected]> 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
It's fine to me. Since both of them are flushing workqueue. Tested-by: <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
