> Subject: Re: [PATCH 1/3] driver core: enable drivers to use deferred probe from > init > > On Mon, Jul 28, 2014 at 03:12:11PM +0000, Yuval Mintz wrote: > > Perhaps this is a silly question, but what guarantees that the > > deferred probe list will actually be triggered, e.g., in case the > > delayed device is the last device in the system? > > The dev->init_delayed_probe is used to ensure that we'd add the device to the > deferred probe list once making this a per device thing if the driver has the field > delay_probe set to true. This technically also allows this to be a per device thing > so with some more work we could enable drivers to only enable this for specific > devices but at this point this did not seem required. Sorry for not being clear, but I didn't meant 'what guarantees that the device will be added to the deferred probe', but rather what guarantees that the deferred workqueue will be scheduled. To the best of my knowledge the deferring mechanism works only if one device is dependent upon another, e.g., for Multi-function devices where one device probe is dependent upon the others - which are soon-to-be probed. [If I'm incorrect I'd appreciate if someone could correct me] > > > [From drivers/base/dd.c - "A successful driver probe will trigger > > moving all devices from the pending to the active list so that the > > workqueue will eventually retry them]
<<attachment: winmail.dat>>
