Messages in this thread | | | Date | Tue, 30 Sep 2014 09:15:55 +0200 | From | "Luis R. Rodriguez" <> | Subject | Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support |
| |
On Sun, Sep 28, 2014 at 12:22:47PM -0700, Dmitry Torokhov wrote: > Hi Luis, > > On Fri, Sep 26, 2014 at 02:57:17PM -0700, Luis R. Rodriguez wrote: > > +static bool drv_enable_async_probe(struct device_driver *drv, > > + struct bus_type *bus) > > +{ > > + struct module *mod; > > + > > + if (!drv->owner || drv->sync_probe) > > + return false; > > This bit is one of the biggest issues I have with the patch set. Why async > probing is limited to modules only?
Because Tejun wanted to address this separately, so its not that we will restrict this but we should have non-module solution added as an evolution on top of this, as a secondary step.
> I mentioned several times that we need > async probing for built-in drivers and the way you are structuring the flags > (async by default for modules, possibly opt-out of async for modules, forcibly > sync for built-in) it is hard to extend the infrastructure for built-in case.
I confess I haven't tried enabling built-in as a secondary step but its just due to lack of time right now but I don't think impossible and think actually think it should be fairly trivial. Are there real blockers to do this that you see as an evolutionary step?
> Also, as far as I can see, you are only considering the case where driver is > being bound to already registered devices. If you have a module that creates a > device for a driver that is already loaded and takes long time to probe you > would still be probing synchronously even if driver/module requested async > behavior.
Can you provide an example code path hit here? I'll certainly like to address that as well.
Luis
| |