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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/