Messages in this thread | | | Date | Fri, 15 Feb 2013 00:58:23 +0800 | Subject | Re: [PATCH] driver core: add wait event for deferred probe | From | Haojian Zhuang <> |
| |
On 15 February 2013 00:50, Arnd Bergmann <arnd@arndb.de> wrote: > On Thursday 14 February 2013, Haojian Zhuang wrote: >> On 14 February 2013 23:57, Arnd Bergmann <arnd@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
It's fine to me. Since both of them are flushing workqueue.
Tested-by: <haojian.zhuang@linaro.org>
| |