On Thu, Aug 09, 2012 at 09:31:30AM +0200, Takashi Iwai wrote:
At Thu, 9 Aug 2012 09:08:13 +0200, Thierry Reding wrote:
On Thu, Aug 09, 2012 at 08:57:13AM +0200, Takashi Iwai wrote:
At Thu, 9 Aug 2012 08:45:23 +0200, Thierry Reding wrote:
Recent changes to the firmware loading helpers cause drivers to stall when firmware is loaded during the module_init() call. The snd-hda-intel module requests firmware if the patch= parameter is used to load a patch file. This patch works around the problem by deferring the probe in such cases, which will cause the module to load successfully and the driver binding to the device outside the module_init() call.
Is the "recent" change meant 3.6 kernel, or in linux-next?
In anyway, I don't understand why such a change was allowed. Most drivers do call request_firmware() at the device probing time. If this really has to be resolved in the driver side, it must be a bug in the firmware loader core code.
A good explanation of the problem and subsequent discussion can be found here:
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/4997...
Yeah, but it doesn't justify this ugly module option. It's a simple bug. Papering over it with this option doesn't fix anything.
It's not an option, all it does is defer probing if and only if the patch parameter was specified to make sure the firmware load won't stall. I realize that this may not be an optimal solution, but at least it fixes the problem with no fallout.
A proper fix would require a larger rewrite because it would entail using the asynchronous firmware load operations. That in turn would require the initialization to be split into several stages.
Thierry