Re: Kernel Firmware Loading

["Alexander E. Patrakov" <patrakov@ums.usu.ru>]

Patrick Mansfield wrote:

>So the proposed (or current?) hotplug firmware interface can block other
>PCI (or other) devices from binding?
>  
>
I am not sure what exactly you mean. Attempting to answer anyway for the 
current firmware implementation.

For an experiment, I created a simple "driver" for a PCI device, that 
only calls request_firmware() in its probe() function and does nothing 
else. I built this driver as a non-module and booted the resulting kernel.

The boot process was indeed delayed by 10 seconds while this driver 
waited for its "firmware". After that delay, the kernel proceeded as 
usual. If I provide the "firmware" in initramfs, no delay occurs.

Looks like this problem (calling request_firmware() from probe() and the 
associated useless delay) does exist in the current 
drivers/char/isicom.c file. This problem can be "solved" by not calling 
request_firmware() in the probe() function of a PCI driver. E.g., 
drivers for wireless cards call request_firmware() only when they 
actually want to reset the card.

Note that all of the above is for PCI drivers. USB may be different.

The preferred solution for the future seems to be the conversion to 
request_firmware_nowait() which doesn't sleep. However, the only driver 
in 2.6.14-mm1 actually using this function is drivers/firmware/dell_rbu.c.

-- 
Alexander E. Patrakov


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel