Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: [PATCH] driver core: add wait event for deferred probe | Date | Thu, 14 Feb 2013 16:50:20 +0000 |
| |
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
| |