Re: [PATCH] ALSA: hda - Defer probe when loading patch firmware

[Takashi Iwai]

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.


thanks,

Takashi

> 
> Signed-off-by: Thierry Reding <thierry.reding@xxxxxxxxxxxxxxxxx>
> ---
>  sound/pci/hda/hda_intel.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index c8aced1..296616e 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -69,6 +69,7 @@ static int probe_only[SNDRV_CARDS];
>  static bool single_cmd;
>  static int enable_msi = -1;
>  #ifdef CONFIG_SND_HDA_PATCH_LOADER
> +static bool deferred[SNDRV_CARDS];
>  static char *patch[SNDRV_CARDS];
>  #endif
>  #ifdef CONFIG_SND_HDA_INPUT_BEEP
> @@ -3156,6 +3157,16 @@ static int __devinit azx_probe(struct pci_dev *pci,
>  
>  	if (dev >= SNDRV_CARDS)
>  		return -ENODEV;
> +
> +#ifdef CONFIG_SND_HDA_PATCH_LOADER
> +	if (patch[dev] && *patch[dev] && !deferred[dev]) {
> +		snd_printk(KERN_ERR SFX "deferring probe for patch %s\n",
> +			   patch[dev]);
> +		deferred[dev] = true;
> +		return -EPROBE_DEFER;
> +	}
> +#endif
> +
>  	if (!enable[dev]) {
>  		dev++;
>  		return -ENOENT;
> -- 
> 1.7.11.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/