Re: Problems loading firmware using built-in drivers with kernels that use initramfs.

[yalin wang]

> On Aug 26, 2015, at 04:26, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> On Tue, Aug 25, 2015 at 12:58 PM, Dmitry Torokhov
> <dmitry.torokhov@xxxxxxxxx> wrote:
>> 
>> Either build firmware in the kernel or ramdisk (so it is always
>> available), or make sure request_firmware() calls are not in driver's
>> probe() paths.
> 
> The correct answer is almost always that second one.
> 
> Drivers that load firmware in their probe parts are generally doign
> things wrong.
> 
> It's very occasionally the right thing to do - there are a few pieces
> of hardware where just about _everything_ about the device is in the
> firmware, and you simply can't even problem them before that, because
> you don't know what they *are* before the firmware has been loaded.
> The extreme case of that might be something like the base hardware
> being an FPGA that has a USB interface, but before the FPGA has been
> loaded, it basically has no identity. So there are probably valid
> cases in theory for loading firmware at probe time, but pretty much
> every single case I've ever actually seen, the probe knows what the
> actual hardware is from some identifiable piece, and the actual
> firmware loading should be delayed until the piece of hardware is
> actually opened.
> 
> So the "load firmware in probe routine" happens, and we shouldn't
> disallow it, but it should be considered a "last resort" kind of
> thing.
> 
> In general, things like sound drivers should *not* need to have their
> firmware in the initrd, even if you build them into the kernel. A disk
> driver? Yes. Maybe the root filesystem is on that disk, and you need
> the firmware for the disk driver to load it. But a sound device?
> Please just make sure that you load the firmware as late as possible.
> 
i remember lots of drivers load their firmware when some user space process
open the device node, that is to say, they load the firmware in 
->open() function, at this time , you can make sure the real filesystem is ready in
most time.  

i think your dsp firmware can also do like this.
you can refer to msm gnu driver:

static void load_gpu(struct drm_device *dev)
{
	static DEFINE_MUTEX(init_lock);
	struct msm_drm_private *priv = dev->dev_private;

	mutex_lock(&init_lock);

	if (!priv->gpu)
		priv->gpu = adreno_load_gpu(dev);

	mutex_unlock(&init_lock);
}

static int msm_open(struct drm_device *dev, struct drm_file *file)
{
	struct msm_file_private *ctx;

	/* For now, load gpu on open.. to avoid the requirement of having
	 * firmware in the initrd.
	 */
	load_gpu(dev);

	ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
	if (!ctx)
		return -ENOMEM;

	file->driver_priv = ctx;

	return 0;
}
it load the firmware in open() function.

Thanks











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