[RFC PATCH 0/5] driver core: driver probe asynchronously

[Ming Lei <ming.lei@canonical.com>]

Hi,

This patchset implements asynchronous driver probe for driver_register,
and try to address the below problems about driver init during
kernel boot:
	- help to solve some dependency problem during kernel boot
	(such as, request_firmware is called inside probe when driver
	is built in kernel[1])

The idea behind the patch is very simple:

	- seperate driver probe from driver_register and run this part
	in one standalone kernel thread context

	- so driver_register will become two parts: register the driver
	on the bus, and trigger to schedule a kernel thread to do the
	driver probe if autoprobe is set

Fortunately, my OMAP4 based Pandaboard boots fine with the patchset, and
looks it may work well.

More or less, some problems might be triggered by these patchset, but
it should be helpful and not a big deal:
	- the dependency problem may be found, and it either exposes
	the driver's probelm or help to improve the asynchronous probe
	approach

	- can use driver_register_sync to work around it

In summary, there are at least two advantages about asynchronous driver
probe:
	- speedup kernel boot when many drivers are built in kernel
	- make driver's probe() not need to consider running something
	asynchronously(such as, scsi scan, request_firmware_no_wait, ...),
	so easier to write drivers

It should a very simple way to help to solve the problem[1], without
any changes on current drivers which call request_firmware() in its
probe(). BTW, the patchset doesn't solve the problem completely, and
still some work is needed.


[1], http://marc.info/?t=134676416100002&r=1&w=2