Re: [PATCH] driver core: add wait event for deferred probe

[Arnd Bergmann <arnd@arndb.de>]

On Thursday 14 February 2013, anish singh wrote:
> Grant, Can you please explain me this problem?My understanding is below:
> If all the detection of devices with there respective driver is done before
> __init section is freed then we will not have the problem mentioned.
> However if the driver requests the probing to be deferred then __init section
> of the deferred driver will not be freed right?

The kernel has no idea which drivers are deferred at the time when all the
__init sections are freed.

> I am afraid but the patch description is bit cryptic for me specially
> this line "kernel has to open console failure & release __init section before
> reinvoking failure".

I would put it this way: With the introduction of deferred probing, the
rules for the use of __init sections have changed slightly for some
corner cases. While normal device drivers can, as before, not call
__init functions from their .probe() callbacks, we could do that in
drivers as long as they were built-in and did not support hotplug,
and that exception was used in console drivers. This exception has
now become more specific, and those drivers also must not use
deferred probing that depends on other loadable modules or hotpluggable
devices.

Grant's patch fixes the corner case where you have a device whose .probe()
callback gets deferred and waits for some object that is provided
by a different built-in driver for a non-hotpluggable device, by making
sure that this particular deferred probe has completed before the __init
section is freed. Unlike Haojian's patch, it allows other deferred
device probe functions that do not need to call __init functions to be
delayed until much later, when a driver module is loaded or a device
is hotplugged.

	Arnd