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
--
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/
